iseage network specification and report...
TRANSCRIPT
ISEAGE Network Specification and Report System
Design Report
Client
ISU Information Assurance Center
Faculty Adviser
Dr. Douglas W. Jacobson
Team May 05_25
David C. N. Rodgers ComS, CprE Lijin Varghese CprE Derek J. Light CprE Justin Magnini CprE
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
Submission Date
May 20, 2023
Table of Contents
1. INTRODUCTORY MATERIALS .......................................................................................... 1
1.1. EXECUTIVE SUMMARY...........................................................................................................11.2. ACKNOWLEDGEMENT............................................................................................................21.3. PROBLEM STATEMENT..........................................................................................................21.3.1. GENERAL PROBLEM STATEMENT.....................................................................................21.3.2. GENERAL SOLUTION APPROACH......................................................................................21.4. OPERATING ENVIRONMENT..................................................................................................21.5. INTENDED USERS AND INTENDED USES..............................................................................21.6. ASSUMPTIONS AND LIMITATIONS.........................................................................................31.6.1. INITIAL ASSUMPTIONS LIST...............................................................................................31.6.2. INITIAL LIMITATIONS LIST..................................................................................................31.7. EXPECTED END PRODUCT AND OTHER DELIVERABLES....................................................4
2. APPROACH AND PRODUCT DESIGN RESULTS ......................................................... 5
2.1. APPROACH USED..................................................................................................................52.1.1. DESIGN OBJECTIVES.........................................................................................................52.1.2. FUNCTIONAL REQUIREMENTS...........................................................................................62.1.4. TECHNOLOGY CONSIDERATIONS......................................................................................72.1.5. TESTING............................................................................................................................162.1.6. PROJECT CONTINUATION................................................................................................192.2. DETAILED DESIGN...............................................................................................................19
3. ESTIMATED RESOURCES AND SCHEDULE .............................................................. 30
3.1. ESTIMATED RESOURCE REQUIREMENTS...........................................................................303.1.1. PERSONNEL EFFORT.......................................................................................................303.1.2. OTHER RESOURCES........................................................................................................313.1.3. FINANCIAL REQUIREMENTS.............................................................................................323.2. SCHEDULES.........................................................................................................................34
4. CLOSURE MATERIALS ..................................................................................................... 36
4.1 PROJECT TEAM INFORMATION............................................................................................364.1.1 CLIENT INFORMATION.......................................................................................................364.1.2 FACULTY ADVISOR...........................................................................................................364.1.3 TEAM MEMBERS...............................................................................................................364.2. CLOSING SUMMARY............................................................................................................374.3 References..........................................................................................................................37
i
List of Figures
Figure 1 - ArcGIS Map With Roads, Streets, Rivers, etc...........................................................................9Figure 2 - Standard for Bracket Usage.......................................................................................................14Figure 3 - Standard for Variable Declarations..........................................................................................14Figure 4 - Standard for Function Declarations.........................................................................................15Figure 5 - Standard for Line length............................................................................................................15Figure 6 - Standard for Loop Usage...........................................................................................................15Figure 7 - Monkey Testing Example 1........................................................................................................17Figure 8 - Monkey Testing Example 2........................................................................................................17Figure 9 - Inter-Group Testing Procedure.................................................................................................18Figure 10 - Database Format for Custom Network..................................................................................21Figure 11 - Flowchart for GUI Functionality............................................................................................23Figure 12 - Screenshot of Newly-Loaded GUI...........................................................................................24Figure 13 - Edit Menu..................................................................................................................................27Figure 14 - Delete Item by Right-Clicking Mouse.....................................................................................28Figure 15 - Tracking Simulation Results........................................................................................................29
ii
List of Tables
Table 1 - Personnel Effort in Hours............................................................................................................31Table 2 - Other Resource Items and Costs.................................................................................................32Table 3 - Financial Requirements...............................................................................................................33Table 4 – Projected Total Cost....................................................................................................................34Table 5 - Labor Costs at $11.00/hour.............................................................................................................34
iii
List of Definitions
Allegro – A cross-platform GUI library with many features.
Classes – Basic construct in object-oriented methods that categorizes elements of the problem.
CVS – Acronym for Concurrent Versioning System, a tool to manage code development.
FLTK – A cross-platform C++ GUI toolkit for UNIX, Linux, Microsoft Windows, and MacOS X.
FOX – A C++ based toolkit for developing GUI’s easily and effectively across a range of platforms.
FreeBSD – A variant of the Berkeley Software Distribution (BSD) which implements the UNIX operating system and its utilities.
GIS – Acronym for Geographical Information Systems, a database used to spatially locate any location on the Earth.
GML – Acronym for Geographical Markup Language, a specialized type of XML used to specify GIS data.
GNU – Acronym for GNU’s Not Unix and refers to software that is free for use.
GPL – Acronym for General Public License, a standard published for freely distributed software.
GTK – A multi-platform toolkit for creating GUIs.
Internet2 – A project aiming to facilitate research and education through advanced network applications using the Internet.
IPv4, IPv6 – Internet protocol versions 4 and 6 used by the Internet and other networks.
ISEAGE – Acronym for Internet-Scale Event and Attack Generation Environment, the system of which the end product is a component.
Java Swing – A set of Java class libraries that support building GUIs and graphics functionality for client applications that will run on multiple platforms.
Kylix – A rapid application development tool that provides components for quick development of GUIs, database connectivity, and internet content.
iv
Landspeed Record – An open competition to achieve the highest bandwidth over the greatest distance on the Internet.
Linux – A popular version of UNIX that is open source software and freely available over the Internet.
Mac OS X – An operating system for the Apple Macintosh, built on Unix.
MFC – A framework on which applications can be developed for Windows.
Mozilla framework – A comprehensive multi-platform framework used, among other things, to develop GUIs.
NetBSD – Secure, multi-platform UNIX-like open source operating system.
Notus – A multi-platform GUI library.
OpenBSD – A free variant of the Berkeley Software Distribution (BSD) which implements the UNIX operating system and its utilities.
Open source – Software that is free for use and modification.
OS – Operating System.
QT – A complete C++ application development framework which includes a class library and tools for cross-platform development and internationalization.
SDL – A library written in C++ for displaying and GUIs.
UNIX – A computer operating system designed to be used by many people at the same time.
wxWidgets - A single, easy-to-use application program interface for writing GUI applications on multiple platforms.
X11 – A recent version of X Windows.
XML – Acronym for eXtensible Markup Language, a flexible way to define formats for data, and make both the format and the data available on the Internet.
Xorg – Another version of X Windows.
X Windows – The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines.
v
1. Introductory MaterialsThis section is intended to give an overview of the project. Some of the
questions answered in this section include what the project is about, what problems it will address, what solutions it will implement to resolve those problems, and who the intended users are.
1.1. Executive SummaryThis report presents the design for the network specification and report
system that will be part of ISEAGE. ISEAGE allows attacks to be played out on networks to find vulnerabilities in the network and devices. The system will allow users to build networks with the option of using GIS to layout the network on a map. The report system will involve the capability to view results in pseudo-real time and post simulation.
For laying out the network a GUI will be used allowing the users to place graphical symbols representing different network devices and computers. To build the network the user can place wires to connect the different components. The network will be stored in a database until the simulation is started. At this time the data will be exported to ISEAGE using XML The user will be able to monitor the traffic through the use of an XML document which holds the data in a logical manner.
The system will run on Windows machines built with the Windows NT family in mind but also capable of running on the Windows 95 family operating systems. One of the goals of this software is to allow any user to quickly and easily build networks, large and small. The users of this software can range from students working on projects to businesses wanting to test networks or network devices.
Many technologies were considered for use in this software. There were a number of GIS technologies, graphics toolkits, databases, database languages, and programming languages reviewed for possible user. The team has decided to use ArcGIS software for the GIS side as well as the graphics toolkit because it allows plug-ins to be used to modify the capabilities of the program. The databases will be a combination of Geodatabase and GML with XQuery being used to search the databases. All other code will be written in C++.
A set of coding standards are defined in order to make all of the code be symmetrical as if one person did all of the development. This also allows a team member to more easily debug another team member’s code as it has been established in the testing plan. The testing plan involves each team member being responsible for the white box and black box testing of another member’s code in order to fix the majority of bugs.
1
1.2. AcknowledgementThe following people and/or groups have and will continue to provide
support whether in the form of technical advice, equipment, or software:
Professor Jacobson has not only offered detailed descriptions of technologies involved in the project, but will also provide financial support for necessary equipment and software within budget limits.
The GIS facility in Durham has and will continue to be consulted to aid the team in getting acquainted with the GIS software necessary to meet project specifications.
1.3. Problem StatementThe problem statement is broken into two sections: a general problem
statement and a general solution approach. The general problem statement will define in general what some of the problems this project will attempt to solve.
1.3.1. General Problem StatementA functionality this project aims to add to the ISEAGE system will
allow users to specify custom computer networks through the use of objects like routers, computers, etc. Another functionality needed is to enable the monitoring of traffic both in pseudo-real time and post-simulation. ISEAGE also requires functionality to allow users to specify the objects mentioned above spatially. For example, a user should be able to specify an individual network that actually exists in Cedar Rapids.
1.3.2. General Solution ApproachSince these functionalities would be extremely difficult for a user
without significant programming experience, this project will design an intuitive GUI that provides graphical symbols representing routers, computers, wires, etc. Additionally, the user will be able to monitor traffic through an XML document which will format data in a logical and comprehendible manner. To enable users to map physical networks, the team will use GIS software which will display on the GUI an easily configurable topology of computer networks.
1.4. Operating EnvironmentThe end product will function under the Microsoft Windows NT family
(including Windows NT, 2000, XP) with no modifications to the code and the Microsoft Windows 95 family (95, 98, ME).
1.5. Intended Users and Intended UsesThe following section defines the intended end users and intended uses of
2
the project.
1.5.1. Intended UsersThe intended users include any individual or group desiring to
simulate a computer network to evaluate the security of the network or a device connected to the network. Creators of small networks include small business owners and student projects. The largest network will be created by Iowa’s Department of Homeland Security to simulate the entire state of Iowa.
1.5.2. Intended Uses The users will create simulated networks via the software and view
the results of the simulations. Some users will require the use of GIS when specifying the network. Others will only want to create a network in conceptual space. The networks created with the software can range from very small to very large, the largest being the entire State of Iowa. A very simple simulation can easily create one computer at a time, while a very complex simulation (especially with GIS information included) must be able to create many computers in their exact locations quickly and easily. Different users will desire different information in the network results. Some users will want information about all routers and other will only want detailed information from a couple of nodes on the network. Users will want to be able to save and load both topologies and results.
1.6. Assumptions and LimitationsThe end product will only support one user at a time; a second copy must
be run to create a different network. Therefore, two users will not be able to modify the same network simultaneously.
1.6.1. Initial Assumptions List
Following are the assumptions made by the team:
The end product will be used by only one user per simulation. If a user would like to configure different computer networks on
the same computer, he or she would have to start another copy of the software.
Functions licensed under the GPL license may be used. In such case, the end product may also be licensed under the GPL license.
1.6.2. Initial Limitations ListListed below are client-specified limitations:
The software must run on the Windows NT (NT, 2000, XP).
3
The software must be GIS-based, i.e., it must be able to configure computer networks that exist spatially.
A GUI interface must be provided for ease in configuring the virtual computer network.
The software must be able to specify IPv4 networks since this is currently the protocol in use by most networks.
The simulation must output results into an XML file for comprehensibility.
1.7. Expected End Product and Other DeliverablesThis project expects to develop a fully functional program in the stated
operating environment. This program shall be able to specify an IPv4 network with attachment points and output an XML file; attachment points are nodes specified on the network which connect to real hardware external to ISEAGE. Documentation will be made to assist in maintaining and extending the project. A project report and presentation will be completed to demonstrate the state and functionality of the end product. Anything less shall be considered a failed project.
4
2. Approach and Product Design ResultsThe approach that will be implemented by the team and the step-by-step
process of the design of the software end-product are described in this section. Some of the major project aspects include the various requirements defined by the team for this project’s successful completion and the detailed explanation of the different project execution phases.
2.1. Approach Used
The proposed approach section describes some of the constraints the team will work with in order to ensure the successful completion of the project. Included are the functions that the software will or will not provide, the security measures taken to safeguard the project while it is being developed, and the safety impacts of the end product. In addition, criteria have been defined in order to evaluate the success of the project at the end of the two-semester period.
2.1.1. Design Objectives
Included in this section are some objectives of the team for the end product.
Ease of use – The user should be able to construct a network specification quickly and easily. The GUI should provide functionality for all the user’s needs through an intuitive interface.
Must allow mapping of existing networks – Current networks should be able to be modeled into ISEAGE for network simulation. Tools should be provided which will allow easy specification for an already existing network.
Physical location may be GIS-based – The location over which a user may at the user’s option include features like railroad tracks, power lines, etc. that are representative of the existing location. To allow this, the end product should be GIS-based.
Allow easy reporting – In addition to designing network specifications, the GUI should be able to show the simulation output of the network either in pseudo-real time or post mortem. This can be shown indicating traffic levels through routers, wires, etc. The output must also be stored in an XML file.
5
2.1.2. Functional Requirements The following defines exactly what the proposed software should and
should not do:
2.1.2.1. The software shall allow the configuration of virtual computer networks whether large or small.
2.1.2.2. The network specification may include different types of computers (IBM, Macintosh), routing devices (switches, bridges), etc.
2.1.2.3. The software shall allow network specification through the use of a GUI which provides graphical symbols representing computers, routers, wires, etc., all of which will be available in a toolbar.
2.1.2.4. The software shall allow the user to specify a network using GIS software, i.e., to specify a network that is representative of a spatially-existent network.
2.1.2.5. The software shall allow network specification in XML format.
2.1.2.6. The software shall be able to read simulation data from the ISEAGE system.
2.1.2.7. The software shall allow the user to view the ISEAGE simulation in pseudo-real time or in post-simulation playback.
2.1.2.8. The software shall allow the user to track packet routes.
2.1.2.9. The software shall allow the user to view areas of high traffic in the configured network.
2.1.3. Design ConstraintsThis section outlines the design constraints of the software.
2.1.3.1. The software must be Windows-compatible.
2.1.3.2. The software may be cross-platform compatible.
2.1.3.3. The software shall provide a GUI for network specification.
2.1.3.4. The software shall be GIS-based.
2.1.3.5. The software shall produce XML output.
2.1.3.6. The software must not allow more than one user to simulate an individual network.
2.1.3.7. The software shall allow the user to specify different networks on the same computer by allowing the opening of different copies of the software.
6
2.1.3.8. The software must be able to specify IPv4 networks.
2.1.3.9. The software may be customizable for IPv6 networks.
2.1.4. Technology Considerations
This section discusses the various software technologies and the technical approaches that the team has researched in the process of deciding which tools and methods to adopt prior to the implementation phase.
2.1.4.1. Considered GIS Software
Since the end product must support GIS functionality, several GIS applications were investigated. Discussed below are ArcGIS Server and MapServer.
ArcGIS Server
ArcGIS Server is a ISU site-licensed software for the development of custom GIS applications. Compared to its open source competitors, ArcGIS Server has the advantage of not only having support materials like free tutorials and documentation, but there is also a GIS lab facility in Durham with a full-time GIS staff that can provide help. In addition, it is certain that ArcGIS Server provides the various functionalities that the GUI application will need.
MapServer
MapServer is the open source equivalent of ArcGIS Server. Although it is certain after talking to some of the GIS staff that it supports some of the needed functionality, it is not at all certain that it has all the required functionality. On the other hand, MapServer has the advantage of being cross-platform whereas ArcGIS Server is only Windows-compatible. However, the client specifications state that the end product be Windows-compatible leaving anything beyond that up to the team.
Selected GIS Software
The team has decided to use ArcGIS Server to provide the needed GIS functionality.
7
Reason for Selection
Considering the lack of support available for MapServer, not to mention the uncertainty about its features, the team has decided to work with ArcGIS Server.
2.1.4.2. Considered Graphical Packages
This section considers the graphical packages the team has researched in order to decide which will best support client specifications. The packages discussed are wxWidgets and the GIS plug-ins built into ArcGIS Server.
wxWidgets
wxWidgets is an open source C++ GUI framework that can be run on multiple platforms including Windows, UNIX, and Mac OS. The advantage of wxWidgets over other GUI frameworks is that the appearance of the windows is dependent on the platform. This is helpful because the end user will get the same “look and feel” of windows that they are used to in their operating system. The advantage of wxWidgets over the GIS plug-ins is its ability to shape the interface. Using GIS plug-ins one is restricted to a GUI similar to the GIS software. With wxWidgets, windows can be built in almost any form to meet the projects needs. The group does not have any experience with either GIS plug-ins or wxWidgets so there is no experiential advantage with either technology.
The major disadvantage that comes with wxWidgets is that it requires much work by the user to configure a location, for example the state of Iowa, realistically inside the GUI while representing the desired features like power lines, railroad tracks, etc.
GIS Plug-ins in ArcGIS Server
The major advantage of the ArcGIS plug-in is that it can directly import into the GUI a physical map with the desired features like railroad tracks, power lines, roads, etc. with minimal interaction required by the user. The physical map with the existing features will additionally be based on the latest geographical information available for that location (see Figure 1). This process would require the user to follow very few steps as compared to a more complicated procedure using wxWidgets.
8
Figure 1 - ArcGIS Map With Roads, Streets, Rivers, etc
The disadvantage involved with ArcGIS plug-ins is that it is not cross-platform like wxWidgets. However, the client has required only that the end product be Windows compatible. Anything beyond that is optional.
Selected Graphical Package
The team has decided to work with the ArcGIS plug-ins.
Reason for Selection
The ArcGIS plug-ins were selected because of the significantly lesser work involved in configuring the physical aspects of a location over which the network simulation was being run. Although the team would prefer to have the end product be cross-platform, the fact that it’s not a requirement also aids in the selection of the ArcGIS plug-ins.
9
2.1.4.3. Considered Databases
This section considers software that provides extra database functionality required for the end product. Also considered are the databases to store the user-defined computer networks.
Geodatabase
In addition to the database functionality that ArcGIS Server provides, the end product will need a GIS component called Geodatabase for further database capabilities. Like ArcGIS Server, Geodatabase comes in both commercial and open source packages. ISU has a supported site-licensed version of Geodatabase that provides the required functionality. The open source version, however, runs the risk again of a lack of documentation.
GML
GML is an extension of XML specifically designed for geographic data. Unlike XML, GML is supported by GIS software like ArcGIS Server. Additionally, GML is specifically designed for graphical representation. Some of its default objects include polygons, lines, points, etc. all of which are customizable. In addition, GML lets the user import image files to represent different computer network components like routers, firewalls, etc. The disadvantage that GML comes with, however, is that none of the team members have worked with it before. However, since GML is an extension of XML, something the team is somewhat familiar with, it is estimated that getting acquainted with GML will not involve significant effort.
XML
The program must output XML, but the option exists to have only XML documents read from and written into. This reduces the amount of file interface code to be written, which in turn reduces the amount of testing and debugging. The primary disadvantage is that algorithms must be implemented within the program to select subsections of the network; however, this becomes less of a problem with the use of a XML querying language like Kweelt or XQuery (see Considered Database Languages).
Allowing the user to work with icons for various computer network objects is one functionality that the team will potentially implement. XML has the ability to import image files for these icons. However, this has to be hard-coded.
10
Selected Database
The site-licensed version of Geodatabase and GML were chosen.
Reason for Selection
The site-licensed version of Geodatabase was chosen due to the support available for it as well as the certainty that it will provide the needed features. GML was chosen over XML since it has the ability to store computer network objects both by using imported image files and also through an object which can represent network objects using polygons, points, lines, etc.
2.1.4.4. Considered Database Languages
This section discusses the database querying languages investigated for searching through the user-defined database.
C++
It is possible to parse through the GML database using C++. However, this would involve significantly more work than if the team used XQuery or Kweelt.
Kweelt
Kweelt is a database querying language for XML databases similar to what SQL is for SQL Server. While this is more convenient than hard-coding queries in C++, its syntax is slightly more tedious than that of XQuery.XQuery
XQuery is another language used to query XML databases. Since the project will work with GML databases, an extension of XML databases, XQuery will be a powerful querying tool. Also, XQuery’s syntax is more intuitive than that of Kweelt.
Selected Database Language
XQuery has been chosen as the database querying language.
11
Reason for Selection
The reason for this selection is that XQuery greatly simplifies the process of parsing through the database compared to C++ while having more intuitive syntax than Kweelt.
2.1.4.5. Considered Programming Languages
This section discusses the various languages that the team considered in deciding on a primary language to use in the coding phase. Among the ones considered are C, C++, C#, and Java.
C
C is compiled code, instead of interpreted code, and if all else is equal, compiled code is at least as fast as interpreted code. This makes C preferable to an equivalent interpreted language. It is also a nearly universal language; at this level, almost anyone who would see the program's code will have used C at some point.
ISEAGE creates a simulation of a computer network which has discrete components connected to one another. This makes an object-oriented language preferable to a non-object oriented language. C, however, is non-object-oriented, and its advantages are shared by the similar, object-oriented languages C++ and C#, making C++ and C# preferable to C.
C++
The primary advantage of C++ is that the entire group has used it before. It is also object-oriented making it well-suited to create many simulation objects with customized behavior since these objects can be represented by instances of virtual objects. All else being equal, being compiled code, C++ will be at least as fast as interpreted languages. Properly constructed C++ code is portable as long as the libraries used are available on the platform to which it is being ported.
The main disadvantage of C++ is that it has few built-in functions compared to C# and Java. Instead, it provides substantial low-level functionality which implies that the team must either locate the appropriate libraries or write the equivalent code from the ground up. A strong example of this is the lack of graphical libraries. However, this can be overcome by the use of software that either provides these libraries or the means to accomplish with ease what the libraries can.
12
Both of these options are discussed in the Considered Graphical Packages section.
C#
C# is more user-friendly than C++ or C because it has many built-in functions which do not require the manual inclusion of libraries. However, C# is not cross-platform. More importantly, however, since only one team member is comfortable with C#, other team members will not be able to help debug or test the C# code.
Java
Java, like C#, has a lot of built-in functions that do not need the manual inclusion of libraries. Unfortunately, like C#, only two of the team members are comfortable with Java leading to the same problem of all members not being able to debug or test Java code.
Selected Language
The team has decided to use C++ as its primary programming language.
Reason for Selection
The main reason is that the team members are all comfortable with C++. This cannot be said for C# or Java. The team members do all have some experience with C, but as was stated before, C is not an object-oriented language making it considerably more difficult than C++. C++ also provides the team the opportunity to debug and test other members’ code. Finally, the lack of graphical libraries in C++ will be overcome by the use of other software (see Considered Graphical Packages). Due to these factors, the team has decided to use C++.
2.1.4.6. Considered Technical Approaches
This section discusses various approaches that the team has considered for the coding phase of the project.
Coding Standards
In order to improve the readability of the code, each member is expected to use the same style of format.
13
Brackets
Brackets shall always have a line which only they appear. Opening brackets shall be at the same tab level as the preceding line, and all following lines will have one more tab preceding the line (see Figure 2).
Figure 2 - Standard for Bracket Usage
Creation of Variables
The creation of variables shall be done at the start of the function and only at the start of the function. The declaration of type shall be followed by exactly one type. Variables shall be declared in order of type, with exactly zero spaces between a variable and the following comma and exactly one space between a variable and the preceding comma (see Figure 3). Variables of the same type shall be declared on the same line unless this exceeds 80 characters, in which case a carriage return and tab will replace the last space on the line that would otherwise exceed 80 characters. The variables of the same type shall be declared in alphabetical order. Variables should be initialized at their creation, or as soon as possible afterwards, but may be initialized to any suitable value; by default, this value is 0 for any variable storing integer-like data.
Figure 3 - Standard for Variable Declarations
Function Declarations
The return type of the function shall be followed by exactly one space, followed by the function name, beginning with a
for(i=0; i<5; i++){
for(j=0; j<5; j++){
functionTabbedIn();}
}
int a, b, c, d, e, f, g, h, i, j, k, l;a=b=c=d=e=f=g=h=i=j=k
14
lowercase letter and with capital letters occurring at the start of any new word (instead of underscores, and without spaces), followed immediately by an opening parenthesis (see Figure 4). The type of and the variables sent into the function shall then follow, in that order, with exactly one space between the return value and the variable. The order of these variables shall be alphabetic by type, then alphabetic by variable name. The variables shall also begin with a lowercase letter, with no spaces, and capital letters beginning subsequent words. After the last variable, a closing parenthesis and semicolon shall appear without any spaces.
Figure 4 - Standard for Function Declarations
Line Length
Line length will be kept at or below 80 characters in order to facilitate printing of source code (see Figure 5).
Figure 5 - Standard for Line length
Loops
Loops will have zero spaces immediately before and after the parentheses. “for” loops will have exactly zero spaces before the semicolons and exactly one space following them (see Figure 6). If multiple comparisons are done at once, with && or ||, then the individual comparisons shall be enclosed in parenthesis, with exactly one space between the parenthesis and the && or ||.
Figure 6 - Standard for Loop Usage
Operations
Both comparison and assignment will be done with zero
int garbageFunction(char firstVariable, char secondVariable,
12345678911234567892123456789312345678941234567895123456789612345678971234567898
for(i=1; (i<5) && (i%3); i++)
15
spaces before and after the operator (see example below). Other operators shall have exactly one space to either side, unless this would cause the line to exceed 80 characters.
Example: x=2 + 2;
16
Semicolons
Semicolons shall never be immediately preceded by white space.
Example: function();
Testing
Two months have been reserved for testing. Because the program is split into two large modules, there are two large modules of testing to be done: Graphical and non-graphical.
The graphical code may be imported from another source (see “Considered Graphical Packages”) and can therefore be expected to be relatively bug-free. If graphical testing must be done, the team shall attempt to explore each aspect of the GUI.
The non-graphical code will almost certainly need to be written by the team. Fortunately, automated testing is much easier to do with non-graphical code than graphical code and this is what will be utilized.
2.1.5. TestingTesting is separated into two major types: Unit and integration. Unit
testing is used to determine that a single component is functioning correctly while integration testing is used to determine that a newly-added component is functioning correctly within the context of the rest of the program.
Within these two types, there are three methods of testing which will be applied: Monkey, pre-selected, and user. Monkey and pre-selected apply primarily to unit tests, while user applies almost exclusively to integration testing.
Monkey Testing
Monkey tests are created by generating random or a large set of sequential inputs to independent functions. Ideally, every possible combination of inputs will be sent to a given function. If two implementations of the same function are available, then the two will be compared to each other, with any anomalies reported. In order to accomplish this, a loop equivalent to Figure 7 will be used:
17
Figure 7 - Monkey Testing Example 1
For functions with multiple arguments, a loop equivalent to Figure 8 will be used:
Figure 8 - Monkey Testing Example 2
Functions with additional arguments will have additional nested loops, as appropriate. The code segment in Figure 8 above iterates through every possible integer, positive and negative, for all inputs, guaranteeing that any error which can occur from an independent input does happen. This will not successfully test for cases where the output of a function depends on previous inputs to a function. The function outOfBounds() is intended to represent a method of checking for whether a function's return value exceeds its limitations. If it does, the function is implemented incorrectly. Error messages are acceptable for the result of outOfBounds().
In order to test functions with string inputs, or any arbitrary sequence of input, a function must be created where the first sequence of the input begins at the lowest possible value of that data type (in the case of strings, this data type is a single character), then increments to its maximum. When it would otherwise exceed its maximum, it is reset to zero, with a second item in the sequence. This continues to a reasonable point, defined in the limitations; in the case of routers, it would be at least 300. These tests ignore PRE conditions, so it must rely on bounds checking for correct output (or errors) to result.
Pre-selected Testing
Pre-selected tests are inputs which will be sent to a given function with
for(i=0; i<0xFFFFFFFF; i++){
if(outOfBounds(function(i));}
for(i=0; i<0xFFFFFFFF; i++){
for(j=0; j<0xFFFFFFFF; j++){
outOfBounds(function(i, j));
}}
18
anticipated output, created by the black box tester. The resulting output of the function will be compared to the anticipated output. If this is identical, that instance of the test will have passed. If not, the entire test will have failed and returned to the original author for debugging. If the original author can not locate the source of the problem, the code will be forwarded to the white box tester for fixing.
User Testing
User testing will be done last and is done by all of the team members by attempting to use the program as a regular user would. If any anomalies are found, then the original author will attempt to locate the source of the problem. If unsuccessful, the code will be forwarded to the white box tester. Ideally, someone unrelated to the project can be located to perform the same type of tests, also identifying user interface problems in addition to technical problems.
Testers
Each team member is responsible for being the primary black box tester of a given member's code. Black box testers are to test code without examining the code itself in order to avoid having any assumptions outside of those specified by the conditions of the code (see Figure 9).
Figure 9 - Inter-Group Testing Procedure
A second tester will be the white box tester and primary debugger. This tester will perform tests for a given member's code by examining the code and attempting to find errors, then creating tests which exploit those errors. In simple cases, the white box tester will fix the code and return it to the primary author for evaluation, noting the changes. The original author will then use his discretion to determine if these changes fix the
19
problem without causing new problems and alter the code further if additional problems do occur.
The fourth member (outside of the original author and the two testers) will act as a secondary debugger. In cases where the original author and the white box tester are unable to identify the source of the problem, the code will be forwarded to the secondary debugger. Only if all three fail to locate the source of a problem should the fourth member (the black box tester) attempt to identify the source of the problem within the code.
To date, Derek and Lijin have been assigned to work on the graphical components while David and Justin have been assigned to the non-graphical components. For testing, Justin will be the black box tester for Derek's code, Lijin for David's code, Derek for Justin's code, and David for Lijin's code. Lijin and Derek will be the white box tester for the other's code, while David and Justin will also be mutual white box testers. Derek is the secondary debugger for David, David for Justin, Justin for Lijin, and Lijin for David. After a bug appears to have been fixed, the original tester will re-check it.
2.1.6. Project ContinuationThe team recommends that the project alter its direction before
continuing. Based on new information gathered from research on various GIS software, the end product will not be implemented as a cross-platform solution. Although cross-platform GIS software was available, due to a lack of documentation and support, this option will not be used. On the other hand, the selected GIS software is well supported at ISU, not to mention the presence of a full-time GIS staff. In addition, it was decided that it would be easier to implement a GIS network layer in ArcGIS Server than to design a GUI from scratch that would have GIS functionality. Using ArcGIS Server makes the users’ task of simulating a computer network over a physical location like the state of Iowa much easier. The same could be done using other graphics packages like wxWidgets but with much more work needed to be done by the user.
2.2. Detailed Design
This section discusses the features of the end product GUI in depth. The discussion is based on the screenshots provided throughout the following pages.
STORAGE
20
Within the context of the program, the elements of the network must be stored. Because speed is not a critical issue, and the maximum number of elements is expected to be 300, a linked list is used to store all of the elements in the network. The attributes of each element is also stored in a linked list, with one element corresponding to each item in the GML specification which follows. Future iterations of this program may improve this aspect by changing to a more efficient structure, such as a binary tree.
GML DATABASE FORMAT
ISEAGE requires the import of an XML document describing the structure of the network. The format of this document is as follows, with only the tags (enclosed in brackets and in all-caps) being required to match exactly (see Figure 10 on the next page). Other text is intended to give the idea of the sort of text that should be in that tag. Additional tags specified by GML 2.0 may also be included. The GIS coordinates provided here are for the display within the program itself.
21
Figure 10 - Database Format for Custom Network
TYPE
The type field is one of the general classes of computers for a given object. In the initial iteration, this is one of firewall, router, server, switch, wireless access point, or workstation.
NAME
This is an exact name of a given object. For example, there are hundreds of routers on the market, but this particular one is a Cisco X100.
<complexContent>
<OBJECT>
<PKEY>A primary key, integer, beginning at 0</PKEY>
<TYPE>Firewall, router, workstation, et cetera</TYPE>
<NAME>Name of Exact Router (e.g., Cisco X100)</NAME>
<REFNAME>Name allowing user to differentiate between similar
instances</REFNAME>
<IP><V4>some.ip.ad.dr0</V4></IP>
<GIS>
<X><METER>X-coordinate with units in tag, in this case,
meters</METER></X>
<Y><METER>Y-coordinate with units in tag, in this case,
meters</METER></Y>
</GIS>
<APPEARANCE>Polygon or image file</APPEARANCE>
<CONNECTION>
<IP><V4>some.ip.ad.dr1</V4></IP>
<IP><V4>some.ip.ad.dr2</V4></IP>
<IP><V4>some.ip.ad.drN</V4></IP>
</CONNECTION>
<OS>Optional, typically one of BSD, Linux, Windows, et cetera</OS>
</OBJECT>
</complexContent>
22
REFNAME
This is the name of an object which is similar to other objects, but must be differentiated from them. This is a user-specified field and may be left blank and is only for the user to tell the difference between several objects of similar type, so it does not need to appear in the XML document submitted to ISEAGE at all. Any string may occur in this field.
IP
This is an IPv4 or IPv6 address, specified by enclosing the IP itself in either <V4> or <V6> tags. Other similar protocols can be added through the addition of new tags. The one contained only within the OBJECT tag is the IP address of the device being described by that OBJECT tag, while the IP addresses inside of CONNECTIONS are the IP addresses to which that computer can connect directly.
GIS and APPEARANCE
The GIS and appearance information are stored solely for the use of the specification and report system; ISEAGE does not need them at this time. In future iterations, ISEAGE may make use of the GIS information to determine the transit time of a packet.
CONNECTION
This is a list of IP addresses that the computer can access directly. For a computer to access other IP addresses, the packet must be routed through whatever IP addresses are accessible. Again, the IP addresses listed under the CONNECTION tag are different from the <IP> <V4> IP address(es). The former lists all IP addresses that the source computer can directly connect to while the latter is the source computer’s IP address.
OS
This is the operating system of the device being described in the OBJECT tag. It is included in order to allow universal operating system vulnerabilities to be assumed.
The user may also add additional tags which will be saved with an all-caps version of the name given in the "Placing an Object" interface.
END PRODUCT GUI
This section discusses in detail the GUI and its various functionalities. A flowchart of the various GUI functionalities is shown below in Figure 11.
23
Figure 11 - Flowchart for GUI Functionality
24
Load Screen
When a user loads the GUI, the initial screen consists of a standard Windows style GUI with a menu bar near the top right including “File”, “Edit”, “View”, and “Help” menus (see Figure 12). There is a blank area where the map is to be loaded.
Figure 12 - Screenshot of Newly-Loaded GUI
A toolbar is also displayed that allows the addition of different computer network components like wired and wireless access points, firewalls, routers, etc. A “Properties” box is also displayed which will list the various attributes for each network component added into the simulation. Additionally, text boxes are also displayed to allow user input of longitude (X) and latitude (Y) coordinates to load a GIS map of the desired specific physical location.
The program will load an empty linked list at this point. Loading a file will populate the list with objects corresponding to those given in the GML document. This function will be of the type:
void loadDocument(char* fileName, struct linkedList* theList);
Add New Item
The user can select from several different types of items within the toolbar
25
(see Figure 12). The standard types of objects are: Access Point, Client, Connection, Custom Object, Filter, Outside Connection, and Server. All objects except for Connection will have an associated Primary Key value, Connection(s) value, GIS Coordinates value, and IP Address value. In case only topology matters, the GIS Coordinates are only used for determining where to display a given object.
New objects will be created through a function of one of the following types:void addNewIPv4(char* name, char ip[], char* type, float x, float y, struct
linkedList* theList); // where ip has 4 slots, with the most significant firstvoid addNewIPv6(char* name, char* type, float x, float y, short ip[], struct
linkedList* theList); // where ip has 12 slots, with the most significant firstAdditional protocols may be implemented at a different time.
Access Point
These include both wireless and wired access points (see Components toolbar in Figure 12) and are intended to route packets between two or more potential sources. Access Points may be connected to other Access Points. These will have the default associated values for Primary Key, Connections, GIS coordinates, and IP address.
Access Points are expected to connect to other nodes, so it is necessary to make it easy to connect an Access Point to other nodes. In order to do this, when an Access Point is selected and another object is CTRL-Clicked, a connection will be created between the two.
Client
These are intended to model single terminating points with a higher number of received packets than sent packets, such as workstations, sending and receiving packets to one other object in the network. They have the default associated properties Primary Key, Connection, GIS coordinates, IP address, and Operating System.
Connection
Connections connect two nodes; they are added either by selecting the Connection button within the Components menu (see Figure 12) and clicking two non-Connection objects in the main window, which will add the IP addresses of the two Connections to the properties of the two objects clicked on. When created, the connection will be displayed as a white line between the two objects.
Filter
Filters are intended to simulate things such as firewalls. Because of the large
26
quantity of firewalls available, by default, the filters will be stateless with a Dropped Ports property. Anything arriving through these ports will not be sent. The other default properties are Primary Key, Connections, GIS Coordinates, and IP Address.
Filters are expected to connect to other nodes, so it is necessary to make it easy to connect a Filter to other nodes. In order to do this, when a Filter is selected and another object is CTRL-Clicked, a connection will be created between the two.
Outside Connection
This connects to something on the outside of ISEAGE. What is connected does not matter within the context of the specification system; the outside connection functions as a black box. The default properties are Primary Key, Connection (since the ports have a one to one relationship), GIS Coordinates, and IP Address.
Server
Servers are intended to model computers with a higher number of sent packets than received packets, such as web servers. These may connect to a large number of clients.
Servers are expected to connect to other nodes, so it is necessary to make it easy to connect a Server to other nodes. In order to do this, when a Server is selected (see Figure 13) and another object CTRL-Clicked, a connection will be created between the two.
Edit Item
After items are created, it is possible that the user may want to edit the properties of that item. The Edit menu is specifically designed for this purpose (see Figure 13). In order to edit created item(s), the user selects an object, uses the menu option Edit->Properties. Alternately, the user may double click on the property in the left list box, bringing up a text box with the value of that property, which can then be directly edited. The user may also right-click on an object in the main window and select Edit->Property from the drop-down menu.
27
Figure 13 - Edit Menu
Both the Edit->Properties and Edit Property methods bring up a dialog box with a list box in the left side with all current properties, identical to the list box which would be displayed in the left side of the program's main window. To the right of this list box will be a text box with the value of the current selection. This may be edited by the user and will be saved to the properties if the user clicks “Ok”, which will be present at the bottom right of the window pane to the left of the Cancel button. The Cancel button will result in closing the window without saving the modifications.
For cases where the list box should have many properties of the same type, these properties will be displayed with a unique integer following them, always in the same sequence.
When the Ok button is clicked, a function of the following type will alter the data at the location of the primary key by traversing the linked list:
void editObject(char* editType, char* newValue, int primaryKey, struct linkedList *theList);
This function may be executed multiple times for one click of the Ok button. The primaryKey will be used to determine exactly which item to edit within the linked list.
28
Delete Item
There are several ways that a user can delete an item. One of the ways is by selecting a created item and then clicking on Edit->Cut. Another way for the user to delete an item is to select the item and use the keyboard “Delete” or “Backspace” buttons to remove that item. Yet another way is for the user to right-click the mouse on the unwanted item and to choose “Delete” from the menu (see Figure 14).
A function of the following type will delete the data at the location of the primary key, found by traversing the linked list:
void deleteObject(int primaryKey, struct linkedList *theList);
Figure 14 - Delete Item by Right-Clicking Mouse
Track Simulation
While the traffic is running over the network the simulation results can be shown in pseudo real-time. For example, Figure 15 shows the lines connecting the network objects in a darker shade with simulated traffic. After the simulation is complete the user will be able to return to the specification screen or replay the simulation.
29
Figure 15 - Tracking Simulation Results
View Traffic Report
The user will be able to access the traffic report after running traffic on the network. The report can be viewed by either accessing the item under “View” in the menu bar or selecting the corresponding icon in the toolbar. Either of these actions will bring up a window with the traffic report in a table format. General information can be viewed for the entire network and detailed information can be viewed for individual devices.
The exact mechanism of this has not yet been determined due to the group’s inexperience with ArcGIS.
30
3. Estimated Resources and ScheduleThis section includes an estimate of the resources required for the project.
Resources defined include the number of hours team members will spend on different project areas, any equipment that will be necessary for the project, and the total dollar amount that the team will need for successful project completion.
3.1. Estimated Resource Requirements
Three separate components, as shown in Table 26-9, make up the estimated resource requirements. There are two parts to each of these components: the original estimate, and a combination of results to date and revised future estimate. In each case, the original case shall be compared to the revised case and the reason(s) for the difference shall be explained. Consider using percentages in your explanations.
3.1.1. Personnel Effort
Following is an update to the material presented in the same section of the Project Plan. The problem definition and technology considerations are complete, so the times reflected will not change. End product design is virtually done at point, so is a much more realistic estimate. Table 1 shows the estimated number of hours that each team member was originally projected, the number of hours actually used, and the number of hours projected for each member to contribute to the different project areas. The hours have been distributed based on the amount of time already spent, all downwards. The team has spent approximately half as much time as originally projected on every task, so the amount of time anticipated in the future has been reduced similarly. David Rodgers, for example, as the team leader is estimated to spend the most hours on researching and selecting the applications the team will work with and is expected to attend any meeting with the faculty adviser or others where no other member is able to make it, regardless of other scheduled activities. As predicted, Lijin Varghese, the communications coordinator, is estimated to spend the most hours on project documentation. Derek Light and Justin Magnini are quite similar in their level of technical expertise and thus it is estimated that they will be involved significantly in the end-product implementation and testing phases.
31
Table 1 - Personnel Effort in Hours
Prob
lem
Def
initi
on
Tech
nolo
gy
Con
side
ratio
n an
d Se
lect
ion
End-
Prod
uct
Des
ign
End-
Prod
uct
Impl
emen
tatio
n
End-
Prod
uct
Test
ing
End-
Prod
uct
Doc
umen
tatio
n
End-
Prod
uct
Dem
onst
ratio
n
Proj
ect R
epor
ting
Total
Original Projected EffortDavid Rodgers 8 14 25 55 25 24 14 15 180
Lijin Varghese 10 10 30 41 20 30 14 20 175
Derek Light 7 12 26 58 25 21 14 7 170
Justin Magnini 7 9 30 60 22 20 14 10 172
Total 32 45 111 214 92 95 56 52 697Previous Effort
David Rodgers 3 14 20 0 0 0 0 0 37
Lijin Varghese 5 30 18 0 0 0 0 0 53
Derek Light 2 12 23 0 0 0 0 0 37
Justin Magnini 2 9 17 0 0 0 0 0 28
Total 12 65 78 0 0 0 0 0 153Projected Total Effort
David Rodgers 3 14 22 28 12 12 9 10 110
Lijin Varghese 5 30 20 20 10 15 9 20 129
Derek Light 2 12 25 27 13 11 9 9 108
Justin Magnini 2 9 19 30 11 10 9 9 99
Total 12 65 86 105 46 48 36 48 446
Note that the end-product demonstration is equally distributed among the members since this will be a team effort for both the preparation and the actual presentation.
3.1.2. Other Resources
The ISEAGE Specification system's entire budget to date has been spent on printing. Table 2 indicates the originally predicted budget, the
32
budget spent to date, and the revised budget estimates. The primary change is that a large proportion of the miscellaneous cost has been divided into binding and printing. This is a software project, so expenses outside of binding and printing are unlikely.
Table 2 - Other Resource Items and Costs
Item CostOriginal Projected Costs
Printing Expenses Including Poster $75.00
Miscellaneous Parts $45.00Previous Costs
Binding $2.40
Non-Poster Printing $1.50
Poster $72.00Projected Total Costs
Binding $16.00
Non-Poster Printing $10.00
Miscellaneous $15.00
Poster $72.00
Note that since the end product is software, and since the team is attempting to use as much open source software as possible to develop the end product, no costs have been listed for applications. Although the client already has in his possession most equipment that the team may need, it is very likely that no such equipment will be needed. Hence, no compensation has been included for such equipment.
3.1.3. Financial Requirements
This section discusses the expected costs of the project, both revised, current, and total projected. Tables 3, 4 and 5 below represent the approximate estimates for the project with and without labor costs of the team members. The items have been separated into two sections: parts and materials expenses, and labor costs. Poster costs, printing costs, binding costs and an item for miscellaneous expenses are included in the first section.
Labor costs include the amount each team member would have earned
33
based on their hours and an $11/hour wage. The wage was selected to be about twice the minimum wage for the sake of convenience. As the table shows, the amount earned is proportional to the total individual hours spent on the project.
Table 3 - Financial Requirements
Item Without Labor With LaborOriginal Projection
Parts and Materialsa. Project Poster $50.00 $50.00b. Other Printing $5.00 $5.00c. Binding $20.00 $20.00d. Miscellaneous $45.00 $45.00
Subtotal $120.00 $120.00
Labor (at $11.00/hr)David Rodgers $1,890.00Lijin Varghese $1,837.00Derek Light $1,785.00Justin Magnini $1,806.00
Subtotal $7,318.00Total $120.00 $7,438.00
Previous CostParts and Materialsa. Project Poster $72.00 $72.00b. Other Printing $1.50 $1.50c. Binding $2.40 $2.40d. Miscellaneous $0.00 $0.00
Subtotal $75.90 $75.90
Labor (at $11.00/hr)David Rodgers $385.00Lijin Varghese $583.00Derek Light $407.00Justin Magnini $308.00
Subtotal $1,683.00Total $113.00 $1,758.90
34
Table 4 – Projected Total Cost
Projected Total CostParts and Materialsa. Project Poster $72.00 $72.00b. Other Printing $10.00 $10.00c. Binding $16.00 $16.00d. Miscellaneous $15.00 $15.00
Subtotal $113.00 $113.00
Labor (at $11.00/hr)David Rodgers $1,188.00Lijin Varghese $1,419.00Derek Light $1,188.00Justin Magnini $1,089.00
Subtotal $4,484.00Total $113.00 $4,597.00
Expenses with and without labor are also listed. The items under “Parts and Materials,” are assumed to cost as much by themselves as much as the total wages paid for accomplishing the tasks associated with those materials.
Below, the labor costs alone are provided; these are identical to those in the previous table.
Table 5 - Labor Costs at $11.00/hour
Item With LaborOriginal Estimate
David Rodgers $1,890.00Lijin Varghese $1,837.00Derek Light $1,785.00Justin Magnini $1,806.00
Total (Labor Only) $7,318.00Current Cost
David Rodgers $385.00Lijin Varghese $583.00Derek Light $407.00Justin Magnini $308.00
Total (Labor Only) $1,683.00Projected Total Cost
David Rodgers $1,188.00Lijin Varghese $1,419.00Derek Light $1,188.00Justin Magnini $1,089.00
Total (Labor Only) $4,484.00
35
3.2. Schedules
To date, the team has managed to stay remarkably on schedule. Therefore, the revised Gantt chart (Figures 16 and 17) has not been changed very much from that which was originally projected. The primary change is that the implementation is now scheduled to begin on the first day of the following semester, instead of at the end of the current semester. Thick bars and dotted bars indicate original schedules, while crosshatches indicate the actual schedule. Single hatches are the revised projected value.
36
4. Closure Materials
This concluding section includes contact information for all significant parties involved in the project. Also included are a closing summary intended to give the reader a final perspective on the whole project and a list of references the team will be using during the course of the project.
4.1 Project Team Information
This section includes contact information for the client, the faculty adviser, and the team members. Team positions and major(s) of study are also listed.
4.1.1 Client Information
ISU Information Assurance CenterDr. Douglas W. Jacobson2419 Coover HallAmes, IA 50011515-294-8307 [email protected]
4.1.2 Faculty Advisor
Dr. Douglas W. Jacobson2419 Coover HallAmes, IA [email protected]
4.1.3 Team Members
David C. N. Rodgers (Team Leader)Computer Engineering, Computer Science210 Campus Ave., #6Ames, IA 50014563-333-3008 (cell)[email protected]
Lijin Varghese (Communications Coordinator)Computer Engineering410 Welch Ave., #8Ames, IA 50014847-910-1178 (cell)[email protected]
37
Derek J. LightComputer Engineering3115 Frederiksen CourtAmes, IA 50010515-572-8044 (phone)515-450-0099 (cell)[email protected]
Justin Magnini Computer Engineering217 S 5th, #6Ames, IA 50010515-233-4600 (phone)515-708-1102 (cell)[email protected]
4.2. Closing Summary
In the wake of recent terrorist attacks, government agencies are urgently seeking to protect critical internet-based infrastructure from the threat of cyber attacks. To prepare for the potential onslaught, the ISEAGE Network Specification and Report System will enable individuals to configure a virtual network on actual hardware. This hardware will then face actual attacks which will be logged along with other traffic in order to evaluate which operating environments provide optimal security. The software will enable ISEAGE to potentially prevent large-scale infrastructure attacks.
4.3 References
GML Specification. Last Accessed: Nov 12, 2004. http://www.opengeospatial.org/docs/01-029.pdf
38