FTI OPERATIONal IP User Guide

![](media/image1.png){width="4.63125in" height="1.707638888888889in"}

Telecommunications services GROUP (TSG), ATO-W

Federal Aviation Administration

Version 3.3

February 2008

**Approvals:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

TSG Engineering and Implementation Group Manager, ATO-W Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\< Team Lead, ATO-W Date

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\< Program Lead, \< Date

Table of Contents

[1 Introduction 5](#introduction)

[1.1 Purpose 5](#purpose)

[1.2 Scope 5](#scope)

[1.3 Document Outline 5](#document-outline)

[2 FTI Operational IP Service Overview
6](#fti-operational-ip-service-overview)

[2.1 Service Specification 6](#service-specification)

[2.1.1 Service Connections 6](#service-connections)

[2.1.2 External User Access 7](#external-user-access)

[2.2 Ops IP Service Ordering Process
8](#ops-ip-service-ordering-process)

[2.2.1 Service Initiation 9](#service-initiation)

[2.2.2 Specification of Ops IP Service Needs and Parameters
9](#specification-of-ops-ip-service-needs-and-parameters)

[2.2.3 Cost Estimation and Funding Transfers
9](#cost-estimation-and-funding-transfers)

[2.2.4 Joint Interoperability Testing
9](#joint-interoperability-testing)

[2.2.5 Service Order Authorization 10](#service-order-authorization)

[2.2.6 Service Delivery 10](#service-delivery)

[2.2.7 Service Acceptance 10](#service-acceptance)

[2.2.8 Service Cutover 10](#service-cutover)

[3 Operational IP Service Options 11](#operational-ip-service-options)

[3.1 Supported Interface Types and User Connection Options
11](#supported-interface-types-and-user-connection-options)

[3.1.1 End System Connections 12](#end-system-connections)

[3.1.2 Intermediate System Connections 12](#__RefHeading___Toc159304842)

[3.1.3 Switch Connections 14](#switch-connections)

[3.2 Ops IP Port Data Rate and Throughput
15](#ops-ip-port-data-rate-and-throughput)

[3.3 Service Quality 16](#service-quality)

[3.3.1 RMA 16](#rma)

[3.3.2 Latency 17](#latency)

[3.4 Multicast 17](#multicast)

[4 Basic IP Service Operations 18](#basic-ip-service-operations)

[4.1 IP Addressing 18](#ip-addressing)

[4.2 Service Connection Protocols 18](#service-connection-protocols)

[4.2.1 Physical Layer 19](#physical-layer)

[4.2.2 Data Link Layer 19](#data-link-layer)

[4.2.3 Network Layer 20](#network-layer)

[4.2.4 Upper Layer Protocols 20](#upper-layer-protocols)

[4.3 Basic and Enhanced Security Services
21](#basic-and-enhanced-security-services)

[4.3.1 Basic Data (BD1) Security for IP Services
21](#basic-data-bd1-security-for-ip-services)

[4.3.2 Basic Data with IPSec AH (BD2) 21](#basic-data-with-ipsec-ah-bd2)

[5 Enhanced IP Security Services 23](#enhanced-ip-security-services)

[5.1 Packet Filtering Firewall (ED6) 23](#packet-filtering-firewall-ed6)

[5.2 Enhanced Access Control Lists (ED11)
23](#enhanced-access-control-lists-ed11)

[5.3 Virtual Private Network, VPN (ED3)
24](#virtual-private-network-vpn-ed3)

[5.4 Extranet Gateway Services (ED8) 24](#extranet-gateway-ed8)

[5.4.1 Extranet Gateway for External (non-NAS) Users (ED8)
25](#extranet-gateway-for-external-non-nas-users-ed8)

[5.4.1.1 ED8 Service Segments 25](#ed8-service-segments)

[5.4.1.2 Provisioning Extranet Gateway (Ops IP ED-8) Services
27](#provisioning-extranet-gateway-ops-ip-ed-8-services)

[5.4.2 Extranet Gateway for Partially Trusted Users (ED9) **Error!
Bookmark not defined.**](#__RefHeading___Toc159304867)

[5.4.3 Extranet Gateway for Trusted Users (ED10)
28](#extranet-gateway-for-trusted-users-ed10)

[5.4.4 Extranet Connectivity Authorization
28](#extranet-connectivity-authorization)

[6 Management and Monitoring 30](#management-and-monitoring)

[7 Future Capabilities 31](#future-capabilities)

[7.1 Quality of Service (QoS) 31](#quality-of-service-qos)

[7.2 IPv6 31](#ipv6)

[8 FAQ (TBD) 32](#faq-tbd)

[Appendix A: FTI Program Points of Contact
33](#appendix-a-fti-program-points-of-contact)

[Appendix B: FTI Service Classes 34](#appendix-b-fti-service-classes)

[Appendix C: Diversity and Avoidance
36](#appendix-c-diversity-and-avoidance)

[C.1 Path Diversity for FTI Services
36](#path-diversity-for-fti-services)

[C.2 Ops IP Service Avoidance 37](#ops-ip-service-avoidance)

[Appendix D: References and Terminology
38](#appendix-d-references-and-terminology)

[References 38](#references)

[Terminology 39](#terminology)

[Appendix E: Protocol and Interface Standards
41](#appendix-e-protocol-and-interface-standards)

[Appendix F: Sample IP Service Description (ISD)
41](#appendix-e-protocol-and-interface-standards)

[Appendix G: Acronyms 45](#appendix-g-acronyms)

[Appendix H: Ops IP External User Service Connection Guidelines
48](#appendix-e-protocol-and-interface-standards)

List of Figures

[Figure 1-1: FTI Operational IP Service Connection
5](#__RefHeading___Toc162244594)

[Figure 2‑1: Example NAS End-to-End Connection Implemented via Two Ops
IP Services 6](#__RefHeading___Toc162244595)

[Figure 2‑2. FTI External User Service Connections
7](#__RefHeading___Toc162244596)

[Figure 2‑3. Operational IP Service Provisioning Process
8](#__RefHeading___Toc162244597)

[Figure 3‑1. User System Connectivity Options
12](#__RefHeading___Toc162244598)

[Figure 3‑2. Router/Firewall Connectivity Options
13](#__RefHeading___Toc162244599)

[Figure 3‑3. Ethernet Switch Connectivity Options
14](#__RefHeading___Toc162244600)

[Figure 4‑1. Protocol Stack 20](#__RefHeading___Toc162244601)

[Figure 4‑2. Implementation of Ops IP Service Connection
20](#__RefHeading___Toc162244602)

[Figure 5-1. Extranet Gateway Data Flows and Security Controls
26](#__RefHeading___Toc162244603)

[Table B-1. Service Class Parameters 34](#__RefHeading___Toc162244604)

[Figure C-1: FTI Backbone 36](#__RefHeading___Toc162244605)

[Figure C-2: Ops IP Network Backbone 37](#__RefHeading___Toc162244606)

[Figure H-1. Ops IP Extranet Connection
49](#__RefHeading___Toc162244607)

List of Tables

[Table 3‑1. RMA Categories for IP Operational Services
16](#__RefHeading___Toc159304887)

# Introduction

## Purpose

This document provides reference material for prospective National
Airspace System (NAS) programs that require Internet Protocol (IP)
network connections via the Federal Aviation Administration (FAA)
Telecommunications Infrastructure (FTI) Operational IP network. It is
not intended to be a technical specification for system interface
development and does not replace the need for engineering interactions.
Objectives of this document include:

-   Describe Operational IP service options and connection alternatives
    in sufficient detail for a user Program Office (PO) to become a
    knowledgeable consumer of IP services.

-   Describe processes and procedures for obtaining FTI Operational IP
    services.

## Scope

This document addresses the provisioning of inter-facility
communications services via the FTI Operational IP Network, including
both NAS and non-NAS users. The scope includes service connections
between a user system access device and a network edge device as
depicted in Figure 1-1. Unless indicated otherwise, any reference to FTI
IP, Operational IP, Ops IP or simply IP services refers to FTI
Operational IP Network services. Administrative IP services are
provisioned via the FTI Mission Support network and are not within the
scope of this document. An Ops IP Service Delivery Point (SDP) is
defined as the point of demarcation between a User System and the Ops IP
Network. \[An SDP is typically implemented as a patch panel with
terminals for user and FTI wiring.\] Interface characteristics are
referenced to either the User-side or Network-side of the SDP. The
attachment of a User System to the SDP is referred to as an Ops IP
Service connection. A user system's access device can be implemented as
either an end system (e.g. an application processor) or intermediate
system (e.g. a router). The network-side of the SDP provides
network-layer forwarding and relay functions.

![](media/image2.wmf){width="5.993055555555555in" height="1.93125in"}

[]{#__RefHeading___Toc162244594 .anchor}Figure 1-1: FTI Operational IP
Service Connection

## Document Outline

Section 1 provides a general introduction. Section 2 provides an
overview of FTI Operational IP Services and associated service
provisioning procedures. Section 3 describes FTI service class
parameters and service connection options. Sections 4 and 5 provide an
overview of basic and enhanced security features. Section 6 introduces
network management and monitoring operational concepts. Section 7
addresses future capabilities.

# FTI Operational IP Service Overview 

FTI objectives include the provisioning of a robust, highly protected,
state-of-the-art infrastructure capable of supplying a complete set of
telecommunications services as defined in the FTI Service Description
Document (FTSD). This document specifically focuses on new, emerging,
Ops IP service requirements, but also applies to services being
transitioned to the FTI Operational IP network from legacy systems, such
as the FAA Internet Protocol Routed Multi-user Network (FIRMNet).

## Service Specification 

FTI services are ordered from a set of predefined service classes that
enumerate various combinations of service options. Service classes are
composed of specific combinations of service parameters such as
availability, latency, restoral time and interface type. The description
and specifications of Ops IP service classes and associated Reliability,
Maintainability and Availability (RMA) characteristics are discussed in
Section 3. The FTI program is capable of providing Ops IP services at
any NAS facility. Ops IP services also include perimeter security
devices and an extranet gateway which provide a secure method for NAS
systems to communicate with non-NAS entities in a controlled manner.

### Service Connections 

Ops IP services are connection-less (sometimes referred to as
Point-to-Cloud) services with the exception of Virtual Private Network
(VPN) connections, which are described later in Section 2.1.2. Ops IP
services have a single SDP, which provides connectivity to the NAS Ops
IP network. Ops IP network routing and relay functions allow a user
system connected to one SDP to communicate and exchange data with a
second user system connected to a different SDP. Figure 2-1 illustrates
a typical NAS service data flow provisioned via two Ops IP network
services. NAS application data flows, including connections via the Ops
IP Network, are defined in application level Interface Control Documents
(ICDs) between communicating systems.

![](media/image3.wmf){width="5.995138888888889in"
height="2.692361111111111in"}

[]{#__RefHeading___Toc162244595 .anchor}Figure 2‑1: Example NAS
End-to-End Connection Implemented via Two Ops IP Services

Specification and provisioning of required FTI Operational IP network
interconnection services exemplified in Figure 2-1 include four basic
elements: user interface parameters, service connection alternatives,
service access, and backbone relay and routing services.

**[User Interface Parameters]{.underline}**: Ops IP services are ordered
on a per port (location) basis. Service characteristics such as data
rate and service availability (further described in Section 3) are
ordered for each port (IP service) individually and will determine
required characteristics of the Ops IP edge device and associated
telecommunications access to the Ops IP network backbone. An Ops IP
service can support multiple application data flows for the connected
user system.

**[Service Connection Alternatives]{.underline}**: Configuration of
physical connections to Ops IP network edge devices can vary depending
on the type of service needed by user programs and the type of user
access equipment. Examples of user access equipments include end systems
(hosts), routers and switches. Allowable connection methods and routing
protocols are discussed in Section 3.

**[Service Access]{.underline}**: User access equipment is connected to
an FTI edge device (typically a router). Edge devices support Ops IP
SDPs and provide access to Ops IP network routing and relay functions.
Telecommunications access provides connectivity between the FTI Ops IP
edge device and the Ops IP network backbone. Depending on locality,
facility type, and service requirements, FTI will utilize available
access as necessary in the design of the access element (connection of
FTI edge device to Ops IP backbone) to satisfy service performance
requirements.

**[Ops IP Backbone Services]{.underline}**: The Ops IP backbone provides
Wide Area Network (WAN) transmission system connections, backbone
switching, and network layer routing, relay and forwarding functions are
used to transfer user data packets between SDPs.

### External User Access

Additional remote access connectivity is available for external users as
depicted in Figure 2-2. FTI service connections to external users are
implemented via an Extranet Gateway. All FTI external IP users must
connect to an SDP within an approved Extranet Gateway. External
(non-NAS) users communicate to the Extranet Gateway via non-Ops IP
services (e.g. VPN sessions over the Internet or via dedicated
telecommunications services (DTS)). Once connected, external user
systems are capable of communicating to a defined set of NAS systems via
a restricted Ops IP Subnet established for a particular NAS program.
Internal restricted subnets are specifically defined within an Ops IP
Supplementary Form for those services. Extranet Ops IP access and
network relay services are controlled via security mechanisms as
described in Sections 4 and 5.4. Additional external user service
connection guidelines are provided in Appendix H.

![](media/image4.wmf){width="5.998611111111111in"
height="1.395138888888889in"}

[]{#__RefHeading___Toc162244596 .anchor}Figure 2‑2. External User
Service Connections to the Ops IP Network

## Ops IP Service Ordering Process 

The service provisioning process for FTI Operational IP network services
is shown in Figure 2-3. The FAA Telecommunications Services Group (TSG)
is responsible for administering service orders for the agency and
coordinating with the FTI Program Office for provisioning of FTI Ops IP
network resources. Potential users should contact TSG engineers for
provisioning Ops IP services. Appendix A lists TSG Points of Contact
(POCs). After initial contact with TSG, service parameters are selected
based on user requirements, followed by cost estimation,
interoperability testing, service ordering, provisioning and delivery,
and finally service acceptance and cutover.

![](media/image5.wmf){width="5.997222222222222in"
height="6.365972222222222in"}

[]{#__RefHeading___Toc162244597 .anchor}Figure 2‑3. Operational IP
Service Provisioning Process

### Service Initiation

National Airspace System (NAS) users initiate the process for
provisioning telecommunications services by contacting a TSG
representative (See Appendix A for TSG POCs) and requesting service.
External users (users not in the NAS administrative domain) are required
to have a sponsoring NAS system PO. External users initiate the
provisioning of Ops IP services by contacting the PO of the NAS system
with which they need to communicate. Service lead time for new service
requests is six months before the service needs date for the remainder
of FTI transition. It is goal to reduce the required lead time after
transition is completed.

### Specification of Ops IP Service Needs and Parameters

User needs and attributes for FTI services are collected via
interactions between the User PO and TSG engineering. Telecommunications
service needs for a program are defined as to type, location, data rate,
performance, number/type of physical connections, security, and any
other required features. Defined service needs are then translated into
Ops IP service classes and associated parameters. Each service
requirement is associated with a service need date. User service
requirements are documented in a Telecommunications Program Plan (TPP)
and associated IP Service Description (ISD) data. ISD data includes the
specific service orders, associated IP supplemental forms and
documentation pertaining to anticipated user system interactions and
associated data flows. The TPP and ISD are recognized as formal
requirements for the user program; these documents and associated data
are developed by TSG engineers and validated with the user PO. Example
ISD information is listed in Appendix F.

### Cost Estimation and Funding Transfers 

Once agreement is reached on user requirements, TSG engineering will
provide a service cost estimate to the user PO. Trade-offs may be
performed to study the effect of changes to service parameters in
support of system architecture cost/benefit trades. Performance
parameters for trade-off configurations are defined in terms of Ops IP
network service definition parameters. Cost estimates of service
interoperability testing (IT) are also provided. TSG works with the User
PO to ensure all service definitions and costs are understood.
Interoperability test funding and agreement on end-state service cost
estimates is required before IT testing is authorized.

### Joint Interoperability Testing

Service requirements and attributes contained in the TPP and ISD are
reviewed, and coordinated with the FTI Interoperability Test (IT) team,
which oversees joint (user PO and FTI) IT testing to validate new user
service operational concepts parameters. IT testing evaluates user
program interfaces and operational concepts to verify that the
identified systems communicate properly via the Ops IP network; IT
testing is also used to verify that the new services do not impact other
existing systems and services. POCs for IT testing are provided in
Appendix A. IT testing is performed at the WHJTC FTI National Test Bed
(FNTB). Objectives of IT testing include:

-   Verification of operational compatibility between user system access
    devices and Ops IP edge devices

-   Verification of end-to-end data flows and operational
    interoperability between user systems when communicating via the Ops
    IP network

Operational compatibility testing with the Ops IP network is the
responsibility of the FTI IT Team. Aside from non-NAS extranet gateway
users, generally the NAS IP user equipment that is to be tested must be
located at the WJHTC. End-to-end application interoperability testing is
typically the responsibility of the user system PO. The FTI IT Team can
support end-to-end application testing, as required and requested by a
user system PO.

### Service Order Authorization

Once verified, user service agreements between TSG and the user PO are
finalized by signing the system TPP to baseline requirements and cost
estimates. The user PO is typically required to provide funding before
TSG authorizes service orders for installation by the FTI vendor.

### Service Delivery

The FTI vendor provisions the services. Ops IP service provisioning
includes establishment of required IP SDPs at the defined locations with
required access to the Ops IP backbone. Additional infrastructure
equipment and access is installed as required. Service provisioning also
includes configuration of the SDPs to be consistent with ordered
performance parameters.

### Service Acceptance

Service Acceptance (SA) includes the formal verification and acceptance
of ordered Ops IP services. The FTI vendor conducts SA testing in
conjunction with the FAA and verifies connectivity and functionality
between the site SDP location and the FTI Operational IP Network
(point-to-cloud). SA testing is conducted on the network-side of the SDP
(as defined in Figure 1-1). Operational systems are not typically
connected during SA. The Acceptance Report documents the results of the
formal FTI acceptance activity and should be signed off by the FAA, or
an authorized representative, indicating successful SA completion. SA
results are provided to the FAA for inclusion in the Facility Data
Reference File. TSG engineering monitors status of service SA activities
and has the responsibility to keep the user PO informed of all schedule
changes; TSG notifies the user PO of completed SA activities.

### Service Cutover

Service cutover is defined as the connection of end user equipment to
the user-side of a service demarc. It is the responsibility of the user
PO to ensure all site preparation (on the user-side of SDP) has been
completed. It is also the user PO responsibility to coordinate with the
Technical Operations Control Center (TOCC) (e.g., a Service Operational
Center (SOC) or an Operational Control Center (OCC)) as necessary to
ensure new/emerging NAS services are appropriately defined and
documented before they are activated. For extranet gateway users this is
the responsibility of the sponsoring NAS system PO. Coordination
includes notifying TSG engineering of service cutover schedules and
providing status of any changes to that projected schedule as activities
progress. Once notified of a desired cutover date by the user PO, TSG
engineering supports coordination between the user PO and the FTI vendor
for service cutovers. TSG coordination includes site readiness review
and notification of the FTI Primary Network Operations Control Center
(PNOCC) of pending cutover activities. FAA preparations for service
cutover may include end-to-end testing by the User PO (such testing
should be coordinated between the user PO and the local ANI support as
required). FTI support to user testing, if required, should be
coordinated through TSG engineering. At the completion of service
cutover, the user program may begin to use the new FTI Operational IP
service operationally.

# Operational IP Service Options

FTI Operational IP service options are selectable in various
combinations. Combinations of service options and characteristics are
referred to as "service classes". An Ops IP service class is made up of
elements and parameters that characterize specific FTI Service features.
FTI Operational IP service classes are associated with specific levels
of:

-   Reliability

-   Maintainability

-   Availability (the combination of these three terms is typically
    referred to as RMA)

The following sections contain a high level overview of key Ops IP
service features, including: supported connection and interface
alternatives; WAN data rate determination (i.e. bandwidth and
throughput); and service quality features such as latency. Enhanced
security options are discussed in Sections 4.3 and 5. Refer to Appendix
B for a more detailed discussion of the Service Classes pertaining to
Ops IP Services.

## Supported Interface Types and User Connection Options

The attachment of a NAS system access device to an Ops IP Network edge
device is referred to as a user connection. The most prevalent interface
type for a Ops IP user connection is full or half duplex 10/100 Ethernet
over a Category 5e Unshielded Twisted Pair (UTP) cable. While this is
not the only interface standard supported by FTI, the majority of
services connect via Ethernet ports. User side serial interfaces for
connecting to FTI edge devices are generally discouraged. Appendix E
lists physical and data link standards supported by FTI.

The use of straight-through vs. cross-over cabling for implementing an
Ethernet user connection is dependent upon both the user system access
device and the FTI edge device at that location. These types of cabling
issues are typically resolved during technical discussions between the
user program and TSG engineering during service specification
interactions.

User program connectivity to an Ops IP network edge device can vary.
Alternatives include:

i.  [End System Connections]{.underline} -- Programs connecting
    end-systems to FTI without an intermediate network device, e.g.
    router, switch or firewall (See Section 3.1.1).

ii. [Intermediate System Connections]{.underline} -- Programs that make
    use of a local area network and connect to FTI via a NAS user system
    access device, such as a router or firewall (See Section 3.1.2).

-   Intermediate system (routers and firewalls) connections can be
    ordered as a single or dual port based on program requirements for
    RMA and diversity

iii. [Switch Connections]{.underline} -- Programs that make use of a
     local area network and connect to FTI via an Ethernet switch (See
     Section 3.1.3).

-   Switch connections can also be ordered as a single or dual
    connection based on program requirements for RMA and diversity

Figure 3-1 depicts the generic connection scenarios discussed above.
Also noted in the figure is the domain space of the IP addresses used on
each end of the Ops IP connection. Each of these will be discussed in
more detail in the following paragraphs, including connection
alternatives at larger sites where the network side of the SDP can have
multiple edge devices.

![](media/image6.wmf){width="5.986111111111111in"
height="3.0479166666666666in"}

[]{#__RefHeading___Toc162244598 .anchor}Figure 3‑2. User System
Connectivity Options

User programs are responsible for cabling between their access equipment
and the Ops IP SDP. Potential distance limitations should be accounted
for when implementing an Ethernet interface. If the total distance from
the user system access equipment to Ops IP edge device exceeds the
maximum-allowable Category 5e distance of 100 meters (including the
length of the FTI cable on network side of demarc), then an alternative
such as fiber optic cabling or symmetric digital subscriber line (SDSL)
equipment, is required. Extended service (distances above 100 meters)
can be provisioned via the FTI contract if required.

###  End System Connections

A NAS system can connect an end system (host processor) directly to an
Ops IP edge device. In this type of connection (see connection option
(i) in Figure 3-1) there is typically one SDP to the user end system and
the user program provides the IP address at both ends of the connection.
The user program thus provides an IP address for the Ops IP edge device
on the network side of the SDP (NAS compliant IP addresses are obtained
from the NAIMES program and associated engineering staff).

End system connections typically use static routing. Required IP
addresses are obtained and defined as part of the requirements
coordination process with FAA/TSG engineering. The user IP addresses and
associated subnets to be used by the Ops IP edge device are documented
in the IP Service Description (ISD) data. If the customer network
topology does NOT use their own router, the Ops IP edge device
essentially acts as a default gateway for the customer IP hosts.
[]{#__RefHeading___Toc159304842 .anchor}

### Intermediate System Connections

As depicted in connection option (ii) in Figure 3-1, routing
coordination can be controlled via either static routing or dynamic
routing (using the Border Gateway Protocol (BGP) routing protocol) when
a NAS system connection is implemented with a router or firewall on the
user side of the SDP. But in either case the IP address on the user
system access device is within the Ops IP network domain and is provided
to the user program by TSG engineering.

[Routing Protocols]{.underline}: FTI Ops IP network edge devices require
knowledge of subnetworks and associated IP addresses on the user side of
the SDP to control the forwarding of IP packets. Such knowledge can be
obtained via either static route coordination or dynamically via a
routing protocol, such as the BGP.

a.  If the user system has a single router Ethernet connection to a FTI
    Ops IP edge device, it is typical to implement routing control via
    static routing.

b.  If the user system network topology includes multiple subnetwork
    domains, BGP is often the more preferred method. User systems
    connecting to the Ops IP network with a single connection can be
    configured with either static or dynamic routing depending on the
    complexity of the user subnet domain on the user side of the access
    device.

c.  If the user system has multiple router links to the Ops IP network
    edge device, a dynamic routing protocol such as BGP is recommended.

Figure 3-2 depicts various intermediate system connection scenarios as
discussed above. In all scenarios the Ops IP network address domain is
used on both sides of the SDP and user domain addresses are used on the
user side of their access device.

![](media/image7.wmf){width="5.997916666666667in"
height="4.329861111111111in"}

[]{#__RefHeading___Toc162244599 .anchor}Figure 3‑2. Router/Firewall
Connectivity Options

### Switch Connections

If the customer network topology does NOT use their own intermediate
system (i.e. router or firewall) the Ops IP edge device can act as the
default gateway for customer IP hosts as was described in Section 3.1.1.
User system configurations can also include LANs connected via an
Ethernet switch as depicted in Figure 3-3, connection type (iii-a). When
connecting to user Ethernet switches, FTI Ops IP edge devices use an IP
address assignment from the user program address space (as obtained via
interactions with the NAIMES engineering staff).

![](media/image8.wmf){width="5.992361111111111in"
height="3.7416666666666667in"}

[]{#__RefHeading___Toc162244600 .anchor}Figure 3‑3. Ethernet Switch
Connectivity Options

If redundant FTI service connectivity is required, a second Ethernet
link can be established from the customer switch (es) to another OPS IP
edge device, as depicted in connection type (iii-b) of Figure 3-3. The
OPS IP edge devices will typically use the Hot Standby Routing Protocol
(HSRP) to ensure gateway redundancy. In this case the user system
provides three IP addresses. Each of the two Ops IP edge device
interfaces uses an IP address. A third IP address is used for the
virtual HSRP address. This implementation scenario is typically ordered
as two RMA-4 Ops IP service connections with avoidance.

A variation of the switch connection (as depicted in Connection Type
(iii-c)) includes the case where a user switch connects to an Ops IP
edge device on one side and to multiple user routers on the local user
side. In this case the HSRP protocol is employed on the user side of
switch. The virtual HSRP IP address will be provided to the Ops IP edge
device for forwarding interactions.

## Ops IP Port Data Rate and Throughput

User programs are expected to understand their anticipated traffic
characteristics and the traffic load they expect to offer to the Ops IP
network in order to sustain their inter-facility operations. Offered
traffic load projections (inbound and outbound of specific Ops IP SDPs)
are coordinated with TSG engineering during service specification
interactions. Projected data flows are used to identify the required Ops
IP WAN service data rate.

User programs must account for the difference between the local
connection transfer speed and the WAN transfer rate expected for a
particular FTI service port. The local connection speed is determined by
the type of local interface established between a user access device and
the Ops IP edge device at SDP. As an example, an Ethernet connection
provides a 10 Mbps local transfer speed while a fast Ethernet connection
provides a 100 Mbps local transfer speed. Local transfer speed does not
directly relate to the allocated WAN access speed, i.e., the rate at
which the user traffic will be offered to the Ops IP network. During the
service ordering process, the user program and TSG will jointly develop
projections for the offered traffic load and associated characteristics,
such as traffic peaking factors and required response time. These
characteristics will be used to determine the required WAN transfer rate
of the service port to be ordered.

**[Rate Limiting]{.underline}**: Rate limiting is an operational control
mechanism that limits bursts of users' packets across the WAN. FTI
employs rate limiting to ensure that no SDP consumes more network
resources than expected and impacting other users.. This can happen
either inadvertently or deliberately. Rate limiting is thus used as one
of the defense layers to protect the network and network users against
denial of service attacks.

The Ops IP network allocates the WAN data rate for a site (FAA facility)
based on the sum of requested user SDP data rates at that facility.
Should a user SDP transfer rate to the WAN exceed the subscribed data
rate (for that SDP for a sufficient period) excess packets may be
queued, delayed and eventually dropped. User programs should consider
the requested WAN data rate as the peak transfer rate that will be
required to sustain their application data flows. So while the local
transfer rate is determined by the interface type, the allowable
sustained WAN data rate is determined by the data rate ordered for the
SDP. If a user program's operational concept is to spread peak transfer
rates over a defined period (i.e. for bulk file transfers) the
associated buffering and end-to-end control is the responsibility of the
user program. In such circumstances the use of reliable upper layer
protocols to guard against adverse impacts to their applications is
recommended.

Rate limiting mechanisms and their effect on users and on the Ops IP
network are still undergoing review. At present, the network limits user
packet data flows from a specific user interface (SDP) when the transfer
rate exceeds a predetermined threshold; this threshold is currently 120
% of the ordered port speed. Plans are being implemented to allow higher
short-term bursts of user traffic (on a lower priority basis) as long as
the sum of offered traffic at the facility does not increase over the
access speed ordered for that facility. Technically inclined readers
interested in policing and other rate limiting mechanisms are referred
to the *Policing and Shaping Review* on Cisco's web site: see reference
\[3\] in Appendix D. []{.mark}

## Service Quality

In FTI, the main requirements that characterize Operational IP service
quality are RMA, diversity (referred to as avoidance if between
different services), and latency. These service characteristics are
described in the following sections. Additional detail is available in
the FTI Telecommunications Service Description Document (FTSD).

### RMA

RMA consists of multiple sub-parameters including availability, restoral
time, mean time between outages (MTBO) and maximum number of outages.
Each sub-parameter has specified levels. The three categories, RMA2
through RMA4, applicable to FTI Operational IP Services are shown in
Table 3-1. However, the FTI service configurations for RMA2 services are
still under review and no Ops IP RMA-2 services have been implemented to
date.

[]{#__RefHeading___Toc159304887 .anchor}

Table 3‑1. RMA Categories for IP Operational Services

  -----------------------------------------------------------------------------
  **Parameter**                             **RMA2**    **RMA3**    **RMA4**
  ----------------------------------------- ----------- ----------- -----------
  Minimum Availability (over a 12-month     0.9999719   0.9998478   0.9979452
  period)                                                           

  Maximum Restoration Time (minutes)        0.98        8.00        180

  Maximum Diversity/Redundancy Restoration  180         180         180
  Time (minutes)                                                    

  Maximum Preventive Maintenance Service    4           4           8
  Interruption Time (hours per year)                                

  Minimum Interval (hours) between          2190        2190        2190
  Service-Interrupting Preventive                                   
  Maintenance                                                       
  -----------------------------------------------------------------------------

Various forms of diversity and redundancy, including but not limited to
electrical, physical and equipment are used to meet the required service
restoration time for these RMA categories. The proper operation of the
Ops IP network and the ability to provide IP services are dependent upon
timely restoration when one of the elements that provides that diversity
and redundancy fails. Service Restoration includes both automated (e.g.,
alternate path switching) and manual (e.g., remote reconfiguration by
Network Management and Operations (NMO)) actions taken to restore a
service infrastructure outage. Note that in many IP networking cases,
initial restoration bypasses the failed path/element and reduces
diversity or redundancy of the service until the failed path/element is
repaired or replaced.

Diversity and avoidance refer to the separation between
telecommunications paths such that the cause of a disruption or failure
in one of the paths will not likely cause a failure in the other path,
and therefore a service can continue in spite of the failure. Appendix C
provides definitions and more information on diversity and avoidance for
Ops IP services.

For Operational IP services, diversity is implemented between the SDP
and the backbone, i.e., access diversity. An Ops IP RMA2/3 service is
implemented with access diversity; the user has a single interface (SDP)
to the Ops IP network edge device and the Ops IP network will provide
any elements necessary for switching between the primary and the backup
access path from the edge device to the Ops IP backbone. Associated
switching is transparent to the IP user.

Another option is for the user to order two RMA-4 SDPs with avoidance;
in this case the user has two interfaces to the Ops IP network and the
network infrastructure will provide avoided paths from the two SDPs to
the Ops IP backbone. The end user is responsible for providing
switching/routing elements (hardware and software) capable of switching
between the primary and the backup access path as required.

Depending on the type of interface connections used (see Section 3.1)
switching may or may not be transparent to the IP user. Dual interfaces
to FTI are often implemented with automatic routing protocols such as
the Border Gateway Protocol (BGP) to ensure that service disruption is
minimal.

### Latency

Latency or packet delay for an end-to-end transfer service is defined
from an origination SDP to a destination SDP. The specified latency
limit is the 99^th^ percentile latency over a rolling period of 24
hours. The latency limit for the current FTI operational IP services is
225 milliseconds, measured form a source SDP to a destination SDP. It
should be noted that latency is a characteristic of an end-to-end NAS
service data flow and encompasses two Ops IP services, as described
earlier in Section 2.1.1. Latency is thus a FTI Ops IP network operating
characteristic as opposed to an orderable characteristic of an
individual IP service.

## Multicast

In networking environments, data can be unicast, multicast, or
broadcast. Data is said to be unicast when transmitted from a source
entity to a single destination entity connected to the network. Data is
said to be multicast when transmitted from a source entity to many (but
not all) receive entities in an associated subnetwork. Data is said to
be broadcast when transmitted from a source entity to all receive
entities connected to the network.

A multicast message is one that is transmitted to select multiple
recipients who have joined the appropriate multicast group. The sender
has to generate only a single data stream. A multicast-enabled router
will forward a multicast datagram to a particular network domain only if
there are multicast receivers in that domain. Other stations filter out
multicast packets at the hardware level (e.g., Ethernet or Token Ring).

The Ops IP network has the capability to support multicasting technology
for users with specialized requirements. The FTI Program office is
exploring ways to extend this service more generally to the FAA
community at large. Multicast technology offers the capability to reduce
WAN traffic when intended recipients of data are clustered at
destinations in close proximity. Multicast technology was developed to
support video streaming and is currently supported by User Datagram
Protocol (UDP) which does not offer guaranteed delivery of user data.

# Basic IP Service Operations

This section provides information on basic operations of Ops IP network
services, such as:

-   How a user can obtain a NAS-compliant IP address space

-   Protocols supported at the different internetworking layers

-   Description of FTI basic access control paradigms

## IP Addressing

A NAS IP Addressing Plan (see reference \[4\] in Appendix D) was
developed as a joint effort between ATO-R (System Operations Services)
and ATO-W (Technical Operations Services). This addressing plan supports
a hierarchical network structure and route aggregation. It also provides
reserved address space to support growth in the number of facilities,
the number of systems, and the number of IP addresses required per
system.

All NAS Operational IP and Mission Support IP network users are required
to obtain address allocations from the NAS IP Address Assignment
authority. IP Address assignments for the NAS are processed by the NAS
Aeronautical Information Management Enterprise System (NAIMES). Contact
information for the NAS IP address assignment authority (NAIMES) is
given in Appendix A. Additional processes and procedures for requesting
new IPv4 address space will be provided upon a formal request to NAIMES
Technical Support.

**[Addresses for Ops IP Peering]{.underline}**: The only instance where
IP addresses are obtained from the FTI PO is where peering is involved
between a user access device and an Ops IP edge device. The IP address
provided by the FTI PO is part of the Ops IP network address space and
is used for user router ports facing the Ops IP edge device. These
scenarios are described in Section 3.1. Note that this address (or pair
of addresses for diverse connections) is assigned to the user network
access device port facing FTI. Addressing for Ops IP Peering will be via
the Border Gateway Protocol (BGP)

**[Private IP Sub-networks]{.underline}**: Programs that provision
services via the Ops IP network, but intend to operate a private IP
sub-network (implemented with private IP addressing schemes that do not
conform to the NAS IP addressing standards) are required to tunnel all
traffic in a restricted access Virtual Private Network (VPN). These
services will not be able to communicate with services outside the
program VPN subnet. The program access devices used to access the Ops IP
network are required to perform any Network Address Translation (NAT)
necessary to support the tunneling; the services are also required to be
ordered with the Enhanced Data-3 (ED-3) VPN security option. In summary,
the Ops IP network operates in full compliance with the NAS IP
addressing scheme. If legacy programs exercising private IP addressing
schemes require Ops IP access, it is the program's responsibility to
perform whatever translations are required to access the NAS compliant
Ops IP network. **Use of private IP addressing does not conform to FAA
policy or the FTI Ops IP guidance and is strongly discouraged**.

## Service Connection Protocols

The information flow through the FTI operational IP network is shown in
Figure 4-1 using the OSI protocol stack as a reference. In general the
FTI operational IP network provides services in layers 1 through 3 of
the OSI protocol stack. Higher layer protocols and associated packets
are encapsulated as transparent data in network layer IP packets relayed
via the Ops IP Network.

### Physical Layer

The primary physical interface used for FTI Operational IP network
connectivity is the physical layer specification of the full-duplex
Ethernet (10 Mbps) as specified in IEEE 802.3, including Fast Ethernet
(100 Mbps) and Gigabit Ethernet (1,000) Mbps. The physical layer
interface (marked by label "User System Connection Point" in Figure 4-1,
below) is a local interface and is defined independently for each user
interface. The connection is typically implemented via a Category 5e UTP
cable with RJ-45 connectors (pin-outs should be compliant with EIA-568a
or EIA-568b).

SDP connections are shown in Figure 4-1 (also see Figures 1-1 and 2-1).
Note that as stated in Section 3.1, depending on distance requirements,
other media types can be used (e.g. fiber cable for distance over 100
meters). Depending on the RMA requirements of the user (see Section
3.3.1) multiple physical media connections may be used to connect a user
system's access device to the Ops IP edge device. Appendix E provides
examples of additional physical interfaces supported by the Ops IP edge
devices.

### Data Link Layer

The most generally used data link layer interface for FTI Ops IP network
services is Ethernet Version II as specified in Request for Comment
(RFC) 894. In addition to Ethernet, the OPS IP service data link layer
supports Point-to-Point Protocol (PPP), Serial Line Internet Protocol
(SLIP), Fast Ethernet, and FDDI Media Access Control (MAC) and Logical
Link Control (LLC). Associated standards with these protocols are given
in Appendix E.

![](media/image9.wmf){width="5.996527777777778in"
height="3.9027777777777777in"}

[]{#__RefHeading___Toc162244601 .anchor}Figure 4‑3. Protocol Stack

As in the case of the physical layer, the data link layer protocol
interface is a local interface and is defined independently for each
user interface specified. Both the physical and data link layer
interfaces are required to define the connection between the user access
device and the local Ops IP edge device. This connection was depicted
earlier in Figure 1-1 and is repeated here as Figure 4-2 for the
convenience of the reader. Specification of the physical and data link
layer interfaces is required to fully define the allowable interactions
of the Ops IP Service Connection.

![](media/image10.wmf){width="5.993055555555555in" height="1.93125in"}

[]{#__RefHeading___Toc162244602 .anchor}Figure 4‑2. Implementation of
Ops IP Service Connection

### Network Layer

The FTI Operational IP network currently supports the IPv4 routed
protocol, as specified in RFC 791 (September 1981). Related IP standards
that are supported in FTI such as the Internet Control Message Protocol
(ICMP) are given in Appendix E. Note that IPv6 support is considered to
be a future capability and is discussed in Section 7.2.

Although most current user to FTI Operational IP network interfaces are
configured using static routing, the Border Gateway Protocol version 4
(BGP-4) routing protocol can also be used for peering with user access
devices as describe earlier in Section 3.

### Upper Layer Protocols

The FTI Operational IP network's network layer service is based on the
IP protocol. IP based packets are typically routed regardless of higher
level protocols, such as those used at the transport and application
layers, to provide guaranteed service delivery and end-to-end flow
control. Upper layer protocols supported by the Ops IP Network are
defined in section 4.3.11 of the FTSD. Typical transport layer protocols
used by communicating NAS systems include connection-oriented TCP as
specified in RFC-793 and the connectionless UDP as specified in RFC 768.
As depicted in Figure 4-1, these upper layer protocols are part of the
application interface between two communicating NAS entities; they are
not typically processed by the Ops IP network. These upper layer
protocols are carried as transparent data in the payload portion of IP
Protocol Data Units processed by the Operational IP network.

## Basic and Enhanced Security Services

Basic security services are integral to all NAS and non-NAS
telecommunications offered by FTI and meet all basic integrity,
availability, authentication, and assurance requirements as defined in
internal FTI security documentation; access to this documentation can be
requested via the FTI Security Office.

### Basic Data (BD1) Security for IP Services

Basic data security (BD1) is intended to provide a level of protection
that meets or exceeds that which is available today with any legacy
telecommunications system for the transport of NAS traffic. As a minimum
BD1 controls are applied to all IP Packets in the Ops IP Network.

Basic Data Security provides fundamental security mechanisms that:

-   Ensure data flows are only accessible to authorized users

-   Require authentication for all external connections

-   Prevent unauthorized packet capture or replay

-   Prevent NAS data on the Ops IP network from commingling with non-NAS
    traffic

BD1 security controls require the implementation of adequate physical
security and adherence to industry best practices in securing,
provisioning and maintaining the FTI Operational IP Network transport
infrastructure. These protections are in addition to the inherent
security capabilities provided by the transport technologies.

BD1 may be configured in one of two ways:

-   [BD1 Restricted (also known as BD1-Closed)]{.underline} - restricts
    communications to only intra-program IP addresses (e.g., User
    Request Evaluation Tool (URET)-to-URET communications)

-   [BD1 Unrestricted (also known as BD1-Open)]{.underline} - allows
    unrestricted inter-program IP communications, which will enable the
    associated services to communicate any similarly configured
    services.

The use of BD1 Restricted thus provides logical separation from other
programs through access controls. Programs that require unrestricted
inter-program communications with only *some* NAS programs, and wish to
disallow traffic sent to or received from other NAS program users
connected to Operational IP Network should order their SDPs with
Enhanced Access Control Lists (ED11) to refine their WAN access controls
as needed.

### Basic Data with IPSec AH (BD2)

The Basic Data Security Level 2 (BD2) includes IP Security (IPSec)
Authentication Header (AH) capability. This service is used for the
transport of NAS data traffic and provides added authentication
capability. BD2 requirements (formally specified in the FTI protection
profile) include:

-   Incorporate all functionality, features, and security mechanisms
    used for BD1 above.

-   Incorporate the integrity measures of IPSec AH or its successor.

This service is intended for program services with a clear requirement
for specific packet authentication but no requirements for IPSec
encryption (see VPN Service described in Section 5.1).

# Enhanced IP Security Services

Enhanced security services are optional security features and must be
explicitly ordered by programs wishing to utilize them. Options include:

-   Stateful Packet Filtering Firewall (ED6)

-   Enhanced Access Control Lists (ED11)

-   VPN (ED3)

-   Extranet Gateway Services (ED8)

Options ED6, and ED11 are ordered independently for each required
service SDP. Options ED3 and ED8 are essentially connection-oriented
services and required associations be created between two Ops IP
services. These relationships are defined in supplemental ordering data.

All Operational IP Network Enhanced Security Services are considered
cost plus and programs will need to budget for the inclusion of these
selected services above and beyond their basic telecommunication
services costs.

## Packet Filtering Firewall (ED6)

ED6 services allow an FAA program/user to add stateful packet filtering
firewall to further protect its communications and network traffic from
traffic on the WAN. With ED6 one can assign restrictions to services,
ports, protocols, and/or source and destination addresses based on
access control lists. It is important to note that the source and
destination is limited to other Operational IP Network users. Since IP
Datagrams can be filtered, routed between network segments, or forwarded
between network segments all based on source and destination IP address
combinations, ED6 examines the packets after they cross a network
boundary and disallows packets based on an unknown IP address(es),
unapproved ports, ranges or protocols.

The purpose for providing orderable packet filtering firewall services
is to allow individual programs to develop and request customized access
controls based on source and destination, as well as to perform ingress
and egress packet filtering. The program is required to submit a list of
firewall rules that it wants to employ for this service along with the
services, ports, protocols, and/or source and destinations required for
the service. These access controls and filters provide another layer of
protection for the programs---not just from unauthorized traffic that
may exist on the WAN---but also to insulate or protect program traffic
from the traffic that is transmitted by other FAA programs and
associated users**[.]{.underline}**

## Enhanced Access Control Lists (ED11)

BD1 router ACLs were originally meant to be innocuous and low
maintenance and therefore, any specialized program security requirements
were to be implemented in either an appliance firewall (Cisco PIX, or
Sidewinder) or as a software implementation (e.g. Context-Based Access
Control - CBAC). As programs were being transitioned a requirement was
identified for an Ops IP network security service that provides more
flexible IP data filtering functionality (based on Access Control Lists,
ACL) than BD1 but less than the full firewall filtering feature set of
the existing Enhanced Data security services (ED6 described in the
previous subsection).

The resulting ED11 security service includes the following features:

-   Is fully compatible with the ACL features and controls implemented
    as a part of Basic Data security (BD1) but allows ACLs for data
    flows between multiple user systems.

-   Should only be used when it is not practical to use CBAC, because of
    data latency requirements of FAA data traversing the router.

-   Should only be used when it is not practical to deploy a firewall
    appliance (Cisco PIX) because of IP bandwidth consideration.

-   Will provide protection between various user system data flows as
    established within the Ops IP network.

-   Can be implemented on any Ops IP services.

## Virtual Private Network, VPN (ED3)

VPN technology is being provided as an orderable service using the IPSec
tunnel mode Encapsulating Security Payload (ESP) protocol for
encryption. VPNs provide the logical equivalent of dedicated and
encrypted point-to-point communications over an IP backbone. This
service is similar to link encryption and is used when a program
requires SDP-to-SDP confidentiality, increased integrity, and improved
SDP-to-SDP source authentication. It is used to isolate program
communications from other Operational IP Network users. An example of
such a requirement would be the need for a program to transmit traffic
between a Terminal Radar Approach Control (TRACON) facility and an Air
Route Traffic Control Center (ARTCC) and be logically isolated from the
rest of the FAA traffic at that site while providing SDP-to-SDP source
authentication.

FTI will encapsulate data into a VPN at the point of entry to the
Operational IP Network Edge device (SDP/CPE) to ensure that logical data
separation and segregation between programs is maintained across the WAN
segments of the network and from other NAS user data/source programs. As
with link encryption, the key to end-to-end protection is to be sure
that program protection exists outside the boundaries of the Operational
IP Network through some other means (i.e., FTI encryption service ends
at the SDP).

## Extranet Gateway (ED8) 

The FAA WAN Connection Policy \[7\] governs NAS system connectivity to
external systems and provides guidelines for controlling access to and
from external systems and networks. The order requires segregation and
access control between all of the FAA's NAS systems and networks from
their associated external systems and networks. All external network
access to the FTI Ops IP Network is controlled through approved FAA
security extranet gateways.

FTI Ops IP extranet gateways provide security control services using a
combination of stateful packet inspection firewall, VPN tunneling, Virus
scanning and application proxy technology. The initial gateway has been
implemented at the William J. Hughes Technology Center (WJHTC).
Additional Extranet Gateways are being installed and implemented at
other sites to provide physical diversity and geographical proximity to
external users to reduce latency and costs associated with connectivity
to the external side of the gateways. Internal access to the gateway is
available from all NAS facilities with access to FTI Ops IP Network.
External access is available from specifically identified access
locations via either Internet connectivity or dedicated service
connections.

### Extranet Gateway for External (non-NAS) Users (ED8)

The ED8 Gateway provides Ops IP services with the ability to communicate
to external (FAA non-NAS or non-FAA) users. The application layer data
flow is thus between a NAS system and an external system, both of which
require connectivity to the Ops IP Network. The general guiding
definition is that an external user is a user component
(inter-networking interface) of a system that that is not in the NAS
administrative domain and thus has not been through the FAA/NAS Security
Certification and Authorization processes. All external users must
connect to the Ops IP network via an extranet gateway**.** ED8 services
provide secure data transfer between specific external user SDPs and NAS
user SDPs and are thus inherently connection oriented. Since individual
Ops IP interfaces are point-to-cloud (connection-less) services, an
association between multiple services is required in order to define an
end-to-end service flow between a NAS system and an external (non-NAS)
system.

#### ED8 Service Segments

An end-to-end extranet gateway service requires at least two service
demarcation points (SDPs), an Internal ED8 SDP and an External ED8 SDP,
and the establishment of an association between these two SDPs**.** A
typical end-to-end extranet service includes the following three
segments:

1.  External access to the ED8 Gateway can be implemented via the
    Internet or a dedicated transmission service (DTS). A VPN tunnel is
    required for each external user connection implemented via Internet
    access. See Appendix H for Internet VPN details.

2.  An internal connection is required from the internal NAS system SDP
    to the gateway; these connections provision an internal limited
    access sub-network within the Ops IP Network. External service data
    flows within the Ops IP Network are constrained to the sponsor
    program's internal limited access sub-network.

3.  An association between an external user connections and internal
    Sponsor program limited access sub-networks is required to establish
    an end-to-end data flow; the authorized data flow association is
    implemented via an application proxy within the ED8 extranet
    gateway.

##### Extranet Gateway Capabilities 

The FTI extranet gateway provides the capability to connect entities in
different security enclaves, such as a NAS system (connected to the Ops
IP network) and a system external to the NAS. The FTI extranet gateway
provides the capability to protect information flows over an un-trusted
environment; it protects the information from the time the data enters
the security control at the remote end of an access connection until it
exits the user side of the internal ED8-enabled SDP. Ideally all
connections through the gateway utilize a full application (layer 7)
proxy Appropriate and required security controls at the remote user and
NAS sponsor program access LAN's are determined and defined as part of
the FAA SCAP process for the sponsoring NAS system.

##### Extranet Services and Associated Security Controls 

A NAS user system PO participating in an extranet service has the added
responsibility to act as an extranet user "***Sponsor***" for external
systems connecting to the NAS to access that system. As part of this
responsibility the sponsoring NAS PO must ensure that the system
security controls adhere to all guidelines and procedures defined for
the NAS. Extranet security controls to be used to communicated to
external users are delineated by a NAS Sponsor Program as part of the
that systems' SCAP process and are also defined in a user-specific
inter-connection agreement (IA) between the NAS sponsoring program and
an external user. Once the sponsoring NAS PO identifies an appropriate
set of security controls, it specifies which controls will be
implemented within the user system, which will be implemented within the
sponsor system and which will be implemented within the extranet
gateway. Those security controls to be implemented within the ED8
Extranet Gateway must be specified in sufficient detail for them to be
ordered and implemented via the FTI vendor. Exhibit 5-1 depicts an
example end-to-end extranet data flow; the open arrows represent the
three end-to-end service segments described in Section 5.4.1.1.

![](media/image11.wmf){width="5.999305555555556in"
height="2.1930555555555555in"}

[]{#__RefHeading___Toc162244603 .anchor}Figure 5-1. Extranet Gateway
Data Flows and Security Controls

NAS Boundary protection is implemented as a combination of physical,
personnel and information security controls. Information security
controls include controls implemented within the NAS Sponsor program,
the external system and the ED8 Extranet Gateway. The NAS Sponsor
program SCAP package includes the description and specification of all
security controls to be implemented within each of these information
security areas.

An external system is required to implement security controls capable of
establishing a VPN tunnel between the external user system WAN access
device and the ED8 Extranet Gateway. The security controls to be
implemented within the external system should also provide industry
standard information security features for isolating the external system
processes from un-trusted access by un-trusted users. External system
security requirements are addressed in more detail in Appendix H.

A sponsoring NAS system is required to implement an Ops IP limited
access subnetwork to support required connectivity between the ED8
Gateway and its NAS system locations participating in the extranet
services. The NAS system also choose to implement an internal NAS VPN
and any other information security controls identified in their system
SCAP that were not obtained via the ED8 extranet gateway.

ED8 gateway security controls participate in both the external and the
internal systems with the NAS sponsor system. The ED8 Application Proxy
controls the data flow between the internal and external users; it also
manages any and all processing required to authorize the connection of
the two segments, including operations of the internal and external
demilitarized zones (DMZ) and associated ED8 gateway security controls.

#### Provisioning Extranet Gateway (Ops IP ED-8) Services 

Extranet services include "Internal" gateway service connections and
"external" gateway service connections. Both are defined as part of ED8
security options associated with Ops IP services. Additional details for
external service provisioning are provided in Appendix H.

##### Provisioning Internal Extranet Gateway (Ops IP ED-8) Services 

Internal Gateway services (NAS system connections) are ordered via the
same processes as any other Ops IP service requirement. Note if the FAA
system is not collocated with the Extranet Gateway, each Internal ED8
service order actually results in an Ops IP limited access sub-network
with at least two Ops IP ports, one at an identified system location and
a second at a gateway location. The limited access sub-network meta data
discussed below is required to establish the desired sub-network for
that service. It should be noted that the ED8 internal ports at the
gateway may not be one-to-one with the ED8 internal services at the
various NAS system locations; i.e. one port at the gateway could suffice
to terminate multiple internal ED8 connections for that program. TSG
engineering will work with the NAS user system PO to define required
gateway SDPs, internal SDPs and the associated limited access
sub-network configuration. Once the sponsor programs limited access
sub-network is defined, associated end-to-end services to be offered to
external users can then be specified.

Sponsor Program Internal limited access sub-network data includes the
following characteristics:

a.  Standard service requirements apply:

    i.  Locations of all required Internal SDPs (including the SDP at
        the ED8 gateway)

    ii. Data Rate of each Internal ED8-enabled SDP

    iii. RMA of each SDP

b.  Additional configuration management (CM) and security control
    information is required to configure the internal ED8 services (to
    be documented as part of the IP Services Description (ISD)
    information) including:

    i.  Definition of connections that are to be part of the ED-8 subnet
        for that user:

        1.  Specifically identified SDPs that will act as the connection
            end-points

        2.  Associated USIs for each end-point

        3.  Assigned IP addresses for each end-point

        4.  Available IP address subnet at the end of each connection

    ii. Specification of Application proxy requirements include:

        1.  Limited access sub-network Identifier

        2.  NAS System implemented and operated security controls

        3.  Extranet gateway implemented security controls

        4.  Identification of Transport layer ports and protocol

        5.  Identification of Application

    iii. Operational parameters anticipated for associated ED-8 external
         services include/require:

         1.  Number of anticipated external connections/services (total
             eventual number)

             a.  Number projected for first six months of operation

             b.  Growth factor

         2.  Projected data rate of individual external connections

         3.  Projected total data rate anticipated on external service
             (first year -- end state)

Identification of Extranet User VPN connections to be associated with
the NAS system service; this log will be incremented as additional
extranet user service orders are filed. \[It is envisioned that a NAS
system may wish to implement an internal ED8 service sub-network and
then incrementally add extranet users.\].

##### Provisioning External Extranet Gateway (Ops IP ED-8) Services 

External user access is required to have a NAS system PO to sponsor its
access. External service connections to Sponsor program systems can be
defined once a NAS sponsoring program establishes an limited access
sub-network with internal ED8 gateway connections.

An application layer ICD with the sponsoring NAS system is required to
support assessment of the required application layer proxy. It is the
responsibility of the sponsoring NAS system PO to coordinate external
user service provisioning with the external program and TSG engineering.

The Sponsoring NAS system is required to have completed the SCAP process
and NAS connection authorization process before external ED8-enabled
services are ordered.

Each external extranet gateway service order must include:

-   Anticipated Data Rate and associated traffic flow characteristics

-   Associated internal NAS program SDPs (and associated USIs)

-   A fixed IP Address to be used on remote (external) user side of the
    Access VPN

-   Description of user system VPN control mechanism

Appendix H provides additional details for planning and ordering of
external ED8-enabled services.

### Extranet Gateway for Trusted Users (ED10)

TBD.

### Extranet Connectivity Authorization

There are currently five approved gateway services available to support
external IP connections to the NAS. These are the NAS Aeronautical
Information Management Enterprise System (NAIMES) Internet and NIPRNet
Gateways, the two legacy Direct User Access Terminal (DUAT) Internet
Gateways, and the FAA Telecommunications Infrastructure (FTI) gateway
services.

The NAIMES Gateway services will continue to be used for their existing
external connections as required, but all newly defined external NAS IP
connections must use the FTI gateway services. The evoluation of the
DUATS gateways and associated services are being reevaluated.

All external NAS IP connections must be coordinated through a sponsoring
NAS Program Office (PO). Sponsoring NAS systems are required to develop
and sign an Interconnection Agreement with each external user
documenting all connections and services (as specified in FAA Order
1370.95). Sponsoring NAS systems must submit all external connection
requests to the Telecommunications Services Group (TSG) with a
notification to the ATO ISS Program.

In order to provide segregation of external NAS IP data flows and
internal NAS IP data flows, separate FTI Service Delivery Points (SDP)
are required for a NAS system to communicate to external users versus
internal NAS users. The FAA Operational IP network must segregate
internal and external data flows while in transit. Additionally the NAS
system application assets (e.g. front-end servers) that support
communications with external users must be physically separate assets
from the assets (e.g. back-end servers) used for communications with
internal NAS users.

Communications between NAS system front-end external communication
assets and back-end internal NAS communication assets must be made
through a Designated Approving Authority (DAA) approved security control
(such as a firewall or filtering router service) that limits
communications to only the addresses, ports, protocols and services
required for operations. If operational requirements prevent this type
of segregation, a waiver request that includes justification must be
submitted by the NAS System PO to the DAA.

Legacy systems that are changing connectivity from non-IP to IP-based
communications require a Security Certification and Authorization
Package (SCAP) revision. Any NAS System PO requesting an external NAS IP
connection must contact the ATO ISS Program to set up a Level of Effort
meeting to determine the extent of the SCAP revision required.

# Management and Monitoring

FTI provides centralized network management and operations (NMO) for the
Operational IP Network. The Ops IP Network is owned and operated by
Harris, the prime contractor. Harris is responsible for managing all NMO
activities for the Ops IP Network. These activities include performing
scheduled maintenance, restoration, repair, and configuration of the
both FTI-installed customer premises equipment (CPE) and coordinating
the same activities with their partner telecommunications service
providers.

The focal point for managing these activities is the FTI Primary Network
Operations Control Center (PNOCC) in Melbourne, Florida; a Backup NOCC
(BNOCC) is located in Chantilly, VA. The FTI NOCCs, however, have a
single POC as far as the FAA is concerned; this is referred to as the
PNOCC [(with the understanding that the BNOCC may actually be the active
control center at times)]{.underline} In general, the NMO function
performed by the FTI NOCC is responsible for the following as related to
FTI services:

-   Providing oversight and management of the FTI network

-   Remotely monitoring and controlling the FTI installed CPE

-   Coordinating the activities of their partner telecommunications
    service providers

-   Coordinating scheduled maintenance activities

-   Coordinating response to unscheduled FTI service interruptions
    and/or outages

-   Coordinating the activities of the on-site FTI technicians

-   Exchanging information about the status, configuration, and
    performance of FTI services to various Technical Operations
    organizations

FTI uses a Unique Service Identifier (USI) to designate each specific
interface. Each USI has a designated primary and backup Technical
Operations Control Center (TOCC) contact, e.g. a SOC or an OCC. When the
PNOCC needs to contact the FAA about a specific USI, e.g. to report a
problem or to request a maintenance release, the PNOCC will contact the
TOCC. Likewise, users should contact their TOCC regarding operational
issues with FTI services. Users and/or the TOCC identify their USIs
while communicating with the PNOCC for easy identification and better
service.

.

# Future Capabilities

This section discusses emerging FTI capabilities and features that have
a potential of being provided as services in the near future. These
capabilities include Quality of Service (QoS), and IPv6.

## Quality of Service (QoS)

QoS refers to the capability of a network to provide better service to
selected network traffic over various technologies. FTI has implemented
an aspect of QoS which in FTI is referred to as Rate Limiting (see
Section 3.3 for details). Additional rate limiting and service
enhancement options are being discussed and pursued with the FTI service
provider, including implementation of full QoS mechanism to further
enhance the customer service performance on the FTI Operational IP
Network. Some of the ideas under discussion and evaluation by the FTI
service provider are:

-   Use of a combination of "packet marking" on the user input ports and
    the use of WAN QOS mechanisms, to implement a more tolerant rate
    limiting mechanism.

-   The possibility of processing intra-facility IP traffic, with and
    without rate limiting and QoS implementation for the same.

## IPv6 

At the present time IPv6 is considered to be an emerging service. The
Ops IP network service provider is in the process of performing
evaluations on IPv6 routing within the FTI backbone using routers at
selected sites in order to meet relevant agency mandate related to IPv6
compliance. FTI CPE is capable of supporting IPv6.   There currently is
no firm schedule for supporting IPv6 on the Operational IP Network.

# FAQ (TBD)

**Does FTI support or provide Domain Name Services (DNS)?**

A DNS translates domain names into IP addresses. Currently, there is no
NAS-wide DNS scheme. NAS IP users have historically maintained their own
DNS. With NAS wide systems like System Wide Information management
(SWIM) that leverage the OPS IP network in the horizon, the importance
of NAS-wide DNS is essential. FTI managed DNS services are limited to
the Ops IP address space reserved for Ops IP management traffic and
limited extranet applications. At the present time, users continue to be
responsible for implementing DNS for their network operations.

**Has FTI gone through a Certification & Accreditation process?**

FTI is a fully certified system. The Level 3 Security Certification and
Authorization Package (SCAP) was approved September 2005. This SCAP
addresses both NAS and non-NAS infrastructure. A copy of this relevant
Certification and Accreditation (C&A) documents for FTI can be obtained
from the program office on request.

**Additional FAQs**

This is a living document and additional FAQs will be addressed as they
come up. Readers are encouraged to submit additional questions as
questions and concerns arise.

# Appendix A: FTI Program Points of Contact {#appendix-a-fti-program-points-of-contact .unnumbered}

**Telecommunications Services Group (TSG) Manager\
**Steve Dash\
<Steve.Dash@faa.gov>

**FAA Telecommunications Infrastructure (FTI) Program Manager\
**Curtis Porter\
<Curtis.Porter@faa.gov>

**TSG Engineering Manager\
**Maureen Cedro 202-493.1410\
<Maureen.Cedro@faa.gov>

**TSG Security Lead\
**Jerry Hancock 202.493.5936\
<Jerry.Hancock@faa.gov>

**TSG Interoperability Test Lead\
**Jim Skalski 609.485.5706

Jim.Skalski@faa.gov

**TSG Operations Lead\
**Jeff McCoy 202493.5987

<Jeffrey.E.McCoy@faa.gov>

**IP Address Assignment *\
***NAIMES Technical Support\
Telephone: (703) 326-3905\
e-mail: [7-AWA-NAIMES@faa.gov](mailto:9-AWA-NAIMES@faa.gov)

# Appendix B: FTI Service Classes  {#appendix-b-fti-service-classes .unnumbered}

FTI telecommunications service classes define specific combinations of
RMA, latency and basic-security levels and are defined in the FTI
Telecommunications Services Description (FTSD) document. The latest
version of this document is Modification P013. The domain of FTI Service
classes associated with the Ops IP Network includes service classes (SC)
SC-71, SC-72, SC-73, SC-74 and SC-75. These services class definitions
(as extracted from the FTSD) are provided in Table B-1 for the
convenience of the reader. Enhanced security levels are defined in
4.2.13 of the FTSD.

[]{#__RefHeading___Toc162244604 .anchor}Table B-1. Service Class
Parameters

+------+----+-------+-------+--------+--------+------+--------+------+
| SER  | R  | LA    | BASIC | INT    | INT    | SDP  | INT    | FEA  |
| VICE | MA | TENCY | SEC   | ERFACE | ERFACE | -SDP | ERFACE | TURE |
|      |    |       | URITY |        |        | SEC  | N      |      |
| C    | CA | LEVEL | LEVEL | TYPE   | S      | TION | UMBERS | SEC  |
| LASS | T. |       |       |        | ECTION |      |        | TION |
|      |    |       |       |        |        | (F   |        |      |
|      |    |       |       |        | (FTSD) | TSD) |        | (F   |
|      |    |       |       |        |        |      |        | TSD) |
+======+====+=======+=======+========+========+======+========+======+
| 71   | RM | LL-3  | BD1   | ET     | 5.6,   | 6.7  | TABLE  | 4.   |
|      | A2 |       |       | HERNET | 5.8 &  |      | 6.4-1  | 3.11 |
|      |    |       |       |        | 5.9    | 6.4  |        |      |
|      |    |       |       | DDC    |        |      |        |      |
|      |    |       |       |        | 5.3.2  |      |        |      |
|      |    |       |       |        | -5.3.5 |      |        |      |
|      |    |       |       |        |        |      |        |      |
|      |    |       |       |        | 5.11 & |      |        |      |
|      |    |       |       |        | 5.12   |      |        |      |
+------+----+-------+-------+--------+--------+------+--------+------+
| 72   | RM | LL-3  | BD1   | ET     | 5.6,   | 6.7  | TABLE  | 4.   |
|      | A3 |       |       | HERNET | 5.8 &  |      | 6.4-1  | 3.11 |
|      |    |       |       |        | 5.9    | 6.4  |        |      |
|      |    |       |       | DDC    |        |      | TABLE  |      |
|      |    |       |       |        | 5.3.2  | 6.5  | 6.5-1, |      |
|      |    |       |       | T1     | -5.3.5 | .1-6 | 6.5-2  |      |
|      |    |       |       |        |        | .5.4 | or     |      |
|      |    |       |       |        | 5.11 & |      | 6.5-3  |      |
|      |    |       |       |        | 5.125. |      |        |      |
|      |    |       |       |        |        |      |        |      |
|      |    |       |       |        | 5.4    |      |        |      |
|      |    |       |       |        | .1.1-5 |      |        |      |
|      |    |       |       |        | .4.1.4 |      |        |      |
+------+----+-------+-------+--------+--------+------+--------+------+
| 73   | RM | LL-3  | BD1   | ET     | 5.6,   | 6.7  | TABLE  | 4.   |
|      | A3 |       |       | HERNET | 5.8 &  |      | 6.4-1  | 3.13 |
|      |    |       |       |        | 5.9    | 6.4  |        |      |
|      |    |       |       | DDC    |        |      |        |      |
|      |    |       |       |        | 5.3.2  |      |        |      |
|      |    |       |       |        | -5.3.5 |      |        |      |
|      |    |       |       |        |        |      |        |      |
|      |    |       |       |        | 5.11 & |      |        |      |
|      |    |       |       |        | 5.12   |      |        |      |
+------+----+-------+-------+--------+--------+------+--------+------+
| 74   | RM | LL-3  | BD1   | VG     | 5.1    | 6.1  | TABLE  | 4.   |
|      | A3 |       |       |        |        |      | 6.1-1  | 3.11 |
|      |    |       |       | ET     | 5.6,   | 6.7  |        |      |
|      |    |       |       | HERNET | 5.8 &  |      |        |      |
|      |    |       |       |        | 5.9    | 6.3  |        |      |
|      |    |       |       | IS     |        |      |        |      |
|      |    |       |       | DN-PRI | 5.4.2  |      |        |      |
+------+----+-------+-------+--------+--------+------+--------+------+
| 75   | RM | LL-3  | BD1   | ET     | 5.6,   | 6.7  | TABLE  | 4.   |
|      | A4 |       |       | HERNET | 5.8 &  |      | 6.4-1  | 3.13 |
|      |    |       |       |        | 5.9    | 6.7  |        |      |
|      |    |       |       | FDDI   |        |      |        |      |
|      |    |       |       |        | 5.7 &  | 6.4  |        |      |
|      |    |       |       | DDC    | 5.9    |      |        |      |
|      |    |       |       |        |        |      |        |      |
|      |    |       |       |        | 5.3.2  |      |        |      |
|      |    |       |       |        | -5.3.5 |      |        |      |
|      |    |       |       |        |        |      |        |      |
|      |    |       |       |        | 5.11 & |      |        |      |
|      |    |       |       |        | 5.12   |      |        |      |
+------+----+-------+-------+--------+--------+------+--------+------+

Definition of Interface Types:

1.  VG Includes 4-wire and 2-wire physical interfaces for VG-1, VG-3,
    VG-6 and VG-8 as specified in section 5.1 of the FTSD

2.  DDC Includes RS-232, RS-449, RS-530/530A and V.35 physical
    interfaces at all data rates from .075 to 1536 Kbps as specified in
    section 5.3.2 to 5.3.5 of the FTSD.

3.  DDS Includes 4-wire physical interfaces at all data rates from 2.4
    to 56 Kbps as specified in section 5.3.1 of the FTSD.

4.  T1 Includes 4-wire physical interfaces for F-1, FB-1, T1C-1536 and
    T1B-1536 as specified in sections 5.4.1.1 to 5.4.1.4 of the FTSD.

5.  T1C-1544 Includes 4-wire physical interfaces for T1C-1544 as
    specified in section 5.4.1.5 of the FTSD.

6.  ISDN Includes 4-wire physical interfaces for ISDN-PRI at 1544 Kbps
    as specified in section 5.4.2 of the FTSD.

7.  T3 Includes 4-wire physical interfaces for T-3 and Fractional T-3 as
    specified in section 5.4.3 of the FTSD.

8.  ETHERNET Includes physical interfaces for 10BASE-T, 100BASE-T and
    Gigabit IP service as specified in section 5.6 and 5.9 of the FTSD.

9.  FDDI Includes physical interfaces for Fibre Distributed Data
    Interface (FDDI) IP service as specified in section 5.7 and 5.9 of
    the FTSD.

# Appendix C: Diversity and Avoidance {#appendix-c-diversity-and-avoidance .unnumbered}

The FTI Operational IP Network backbone is highly available and has ten
fully meshed core nodes (see Figure C-1). Diversity and avoidance are
terms that refer to the separation between telecommunications paths
and/or services such that the cause of a disruption or failure in one of
the paths will not likely cause a failure in the other path, and
therefore a service can continue in spite of the failure.

![](media/image12.wmf){width="5.997222222222222in"
height="3.9694444444444446in"}

[]{#__RefHeading___Toc162244605 .anchor}Figure C-1: FTI Backbone

#### Path Diversity for FTI Services

Path Diversity is defined as physical, electrical, optical, or media
separation in the routing of a single connectivity along either of two
paths between the SDPs, such that a failure at one point on either path
shall not cause the loss of both paths. For operational IP services
diversity is interpreted as diversity between the SDP and the backbone,
i.e., diversity for a NAS Operational IP service is defined as diversity
in the access of the SDP to the Ops IP backbone as depicted in Figure
2-1 and repeated here as Figure C-2.

High availability (RMA-2 and RMA-3) connection-less (also referred to as
point-to-cloud services) Ops IP services provide diversity from the SDP
to the Ops IP backbone; the selection of a high availability service
class implicitly defines the need for SDP to backbone diversity and is
not ordered explicitly. Facility B on the right of Figure C-2
illustrates the dual access connection of a high availability Ops IP
service.

![](media/image3.wmf){width="5.995138888888889in"
height="2.6972222222222224in"}

[]{#__RefHeading___Toc162244606 .anchor}Figure C-2: Ops IP Network
Backbone

#### Ops IP Service Avoidance

FTI service avoidance is defined as physical, electrical, optical, and
media separation in the routing of multiple services (with endpoints at
the same or different facilities) such that a failure at one point on
either path shall not cause the loss of both services. Avoidance thus
has the same access properties as diversity, except it is defined
between two service paths instead of two paths for a single service.

For operational IP services two ports ordered with avoidance implies the
two ports will have avoided paths from their SDP to the operational IP
backbone, i.e., the two ports would be implemented with access
avoidance. Avoidance must be explicitly ordered. When ordering avoidance
for a particular service, one must define what other service is to be
avoided. Ordering two SDPs with avoidance also provides the dual access
connection to the backbone as depicted at Facility B in Figure C-2

With Ops IP service avoidance, the user has multiple services and thus
multiple interfaces to the FTI network and the FTI network will provide
separate paths for access. In case of failure of a path, the end user
will have the responsibility to provide any switching elements (hardware
and software) necessary for switching between the primary and the backup
access path. Switching will not be transparent to the IP user and the
user will have to use separate IP addresses for the different
interfaces. Dual interfaces to FTI are often practically implemented
with automatic routing protocols such as BGP to ensure that service
disruption is minimal.

# Appendix D: References and Terminology {#appendix-d-references-and-terminology .unnumbered}

## References {#references .unnumbered}

1.  *FTI Telecommunications Services Description( FTSD), Modification
    P013,* Attachment J.1*,* Document DTF01-02-D-03006, Feb 2005*,*
    Federal Aviation Administration, Washington, DC.

2.  *Engineering Guide to FTI Services*, August 2003, Federal Aviation
    Administration, Washington, DC.

3.  *Policing and Shaping Review,* Cisco IOS Quality of Service
    Solutions Configuration Guide, Release 12.1,
    [**http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_chapter09186a00800c60d1.html**](http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_chapter09186a00800c60d1.html),
    CISCO Corporation, San Jose, CA.

4.  *Internet Protocol Version 4 (IPv4) Address Assignment Plan,\
    *NAS1370-500.5, August 2004, Air Traffic Organization, Federal
    Aviation Administration, Washington, DC.

5.  *FTI Security CONOPS*, *Version 2.0,* March 2005, Federal Aviation
    Administration, Washington, DC.

6.  *FTI Network Management & Operations Concept of Operations*,
    *Version 2.0.1,* March 2005, Federal Aviation Administration,
    Washington, DC,

7.  *FAA WAN Connectivity Security,* Order 1370.95, November 2006 ,
    Federal Aviation Adminsitration, Washington, DC.

## Terminology {#terminology .unnumbered}

In this document, the following definitions are used:

Access Device: An Ops IP access device is defined as user system
equipment that supports user connections to the FTI Operational IP
network.

Circuit: A circuit is a point-to-point or multipoint telecommunications
link between specific locations.

Corrective Maintenance and Service Restoration: Corrective maintenance
is defined as the automated (e.g., alternate path switching, dial
back-up) and manual (e.g., remote reconfiguration by Network Management
and Operations (NMO) personnel, technician dispatched to site) actions
taken by FTI to restore a service outage. Corrective maintenance is
separate and distinct from preventive maintenance.

Edge Device: An Ops IP edge device is defined as an FTI CPE element that
supports user connections to the FTI Operational IP network.

Emerging Services: The term "emerging service" refers to a new program's
projected required services or new services for existing programs.

Extranet: An extranet is part of the FAA's intranet that is extended to
users outside the FAA. In the context of this document, an extranet is a
private network that uses the Internet protocols and public
telecommunications resources to provide secure access from FAA
suppliers, vendors, partners, customers, or businesses to a subset of
FAA's intranet resources.

FTI Connection Oriented Service: An FTI connection oriented service is
an SDP-to-SDP telecommunication link provided by the FTI service
provider.

FTI Ops IP Service Delivery Point (SDP): An FTI Ops IP Service Delivery
Point (SDP) is defined as the point of demarcation between a User System
and the Ops IP Network. Interface characteristics are referenced to
either the User-side or Network-side of the SDP.

Internet Access Point (IAP): An IAP is defined as a specialized form of
a security gateway used for connecting protected FAA network resources
and the Internet. There are restrictions on the types of FAA network
resources that are allowed to connect to an IAP.

NAS Intranet: The FAA intranet is a TCP/IP-based information and content
management infrastructure. It is accessible only by NAS systems and
users for the purpose of sharing data. NAS intranet services are
provisioned via NAS systems (TCP protocol machines are embedded in the
NAS systems themselves) which access NAS inter-connection services (see
NAS System-to-System Ops IP services) provisioned from the FTI
Operational IP network.

NAS System-to-System Ops IP Service: While Ops IP services are defined,
ordered and implemented as individual Point-to-Cloud services, logical
NAS end-to-end data flows allow two NAS systems to communicate using the
IP protocol.

Ops IP SDP Connection: An Ops IP SDP connection is a circuit or local
cable providing a communications path for the flow of IP packets (over
Data Link and Physical mechanisms and protocols) between a user access
device and an FTI edge device.

Ops IP Network: The NAS Operational IP Network is the IP-based service
offering available via the FTI contract. It is composed of an IP-based
backbone infrastructure and associated user accesses referred to as IP
Service Delivery Points (SDPs).

Ops IP Extranet Gateway: The Ops IP extranet gateway is a specialized
form of a security gateway implemented on the Ops IP Network. It is used
to extend the FAA's intranet to users outside the FAA. The Ops IP
extranet is implemented by approved external communications from
authorized non-NAS entities to the external side of the Ops IP extranet
gateway.

Ops IP Relay Functions: Ops IP relay functions (sometimes referred to as
the forwarding function) include all processing and storage and handling
of user packets to enable the transfer of a user packet from a source to
a destination SDP.

Ops IP Routing Functions: Ops IP routing functions include all
processing and exchange of management data required to determine the
routing of a user packet within the Ops IP Network. This includes the
exchange of addressing and routing information across an Ops IP
Connection (i.e. between a user access device and an FTI edge device)
and routing exchanges between various network layer entities (routers)
within the Ops IP Network. IP Routing protocols enable routers to build
up a forwarding table that correlates final destinations with next hop
addresses.

Ops IP Service: Ops IP services are connection-less (sometimes referred
to as Point-to-Cloud) services. They have a single SDP that provides
connectivity to the NAS Ops IP network. For Ops IP services the service
is not end-to-end but extends from the user system to the Ops IP
network.

Preventive Maintenance: Preventive maintenance is defined as any FTI
maintenance action that is planned and scheduled in advance. Preventive
maintenance is tracked against individual connectivities and support
system interfaces, and may be either service interrupting or non-service
interrupting. Preventive maintenance is separate and distinct from
corrective maintenance.

Reliability and Availability: For purposes of reliability and
availability, an outage occurs whenever any interface, SDP-to-SDP
service, or network performance parameter is not within specified
performance limits. Minimum requirements for SDP-to-SDP services and
support system interfaces are provided in the FTSD.

Security Gateway: A controlled access point between a protected network
and an unprotected network.

# Appendix E: Protocol and Interface Standards {#appendix-e-protocol-and-interface-standards .unnumbered}

***1. Physical Layer***

-   Ethernet interface as specified in IEEE 802.3

-   EIA/TIA-232 interface as specified in ANSI/EIA/TIA-232-C, D, and E

-   EIA/TIA-449 interface as specified in EIA/TIA-449A

-   EIA-530 interface as specified in EIA/TIA-530

-   EIA-530A interface as specified in EIA/TIA-530A

-   V.35 interface as specified in ITU V.35 and ISO 2593

-   ISDN interface (2B+D) as specified in ASNI (T1.601) and ASNI
    (T1.601)

-   T1 interface as specified in ANSI T1.403-1999

-   T3 interface as specified in Bellcore GR-499-CORE Section 10.5.4

-   FDDI as specified in IEEE 802.5

2.  ***Data Link Layer***

-   PPP as specified in RFC 1661

    -   Other PPP related RFCs that are supported are:

        -   RFC 1663: PPP Reliable Transmission, July 1994

        -   RFC 1662: HDLC-Like Framing, July 1994

        -   RFC 1598: PPP in X.25, March 1994

        -   RFC 1618: PPP over ISDN, May 1994

        -   RFC 2363: PPP over FUNY, July 1998

        -   RFC 1570: PPP LCP Extentions, January 1994

        -   RFC 2484: PPP LCP Internationalization Configuration Option,
            Jaunuary 1999

        -   RFC 1989: PPP Link Quality Monitoring, August 1996

        -   RFC 1962: The PPP Compression Control Protocol (CCP), June
            1996

        -   RFC 1994: PPP Challenge Handshake Authentication Protocol
            (CHAP), August 1996

        -   RFC 2284: PPP Extensible Authentication Protocol (EAP),
            March 1998

        -   RFC 1968: The PPP Encryption Control Protocol (ECP), June
            1996

        -   RFC 2419: The PPP DES Encryption Protocol, Version 2
            (DESE-bis), September 1998

        -   RFC 2420: The PPP Triple-DES Encryption Protocol (3DESE),
            September 1998

-   SLIP as specified in RFC 1055

    -   The SLIP interface supports physical dedicated serial links and
        dialup lines with line speeds from 1.2 kbps to 19.2 kbps

-   Ethernet MAC layer as specified in IEEE 802.3 and Ethernet II;
    Ethernet LLC layer as specified in IEEE 802.2 LLC

-   FDDI MAC and LLC layers as specified in ANSI X3.239-1994 and IEEE
    802.2 LLC respectively

3.  ***Network Layer***

-   RFC 791: Internet Protocol, September 1981

-   RFC 792: Internet Control Message Protocol (ICMP), September 1981

-   RFC 919: Broadcasting Internet Datagrams, October 1984

-   RFC 922: Broadcasting Internet Datagrams in the Presence of Subnets,
    October 1984

-   RFC 950: Internet Standard Subnetting Procedure, August 1985

-   RFC 1112: Host Extensions for IP Multicasting, August 1989

```{=html}
<!-- -->
```
-   RFC 1654: Border Gateway Protocol 4 (BGP-4), July 1994

-   RFC 1247: Open Shortest Path First (OSPF) Version 2, July 1991

-   RFC 2281: Hot Standby Router Protocol (Cisco), March 1998

4.  ***Transport Layer***

    -   RFC 793: Transmission Control Protocol (TCP), September 1981

    -   RFC 768: User Datagram Protocol (UDP), August 1980

**Additional RFC Compatibility**

The RFCs listed in the previous section were explicitly identified in
the FTI FTSD and/or associated documentation. The development of the FTI
Operational IP Network has resulted in an IP network that is compatible
with any Internet Engineering Task Force (IETF) request For Comments
(RFC) supported by the Cisco IOS. The complete list of Cisco compatible
RFCs is can be found on the Cisco web site:

***"http://www.cisco.com/en/US/products/ps6350/prod_bulletin0900aecd802eaa4f.html"***

In general, FTI Operational IP services will support any service as
defined in the above reference for standards supported in CISCO IOS
Software releases 12.4 and 12.2S. However, there are many RFCs/features
that have not (at time of the writing of this document) been tested in
the FTI test bed at the WJHTC. Any questions or concerns about Ops IP
compatibility should be referred to the TSG engineering staff.

**Appendix F: Sample IP Service Description (ISD)**

**General items contained in ISD for a particular service (SDP)**

1.  Program Name

2.  Connectivity ID

3.  USI (once one has been assigned)

4.  Facility LID

5.  Facility FAC

6.  Required Availability

7.  Required Restoration Time

8.  Latency Limit

9.  Avoidance (between multiple SDPs, i.e. identification of pairs of
    SDPs that should avoid each other)

10. RMA Level

11. Service_Class

12. SVC

13. PDC

14. Interface_Type

15. Security Level

16. Required_Service_Date

17. Domain of communicating systems {Set of SDPs with which the defined
    SDP will communicate}

18. Projected data rate of each data flow identified in item 19 (in each
    direction)

19. Max_Data_Rate (sum of all expected data flows through a SDP)

20. Busy_Hour_Usage

**Additionally, for BD1 Services**

1.  Multicast or Unicast Services

2.  Multicast Group Addresses

3.  Routing Protocol in use by user program

4.  BGP Peer (if applicable)

5.  Distance from user equipment to FTI SDP

6.  SDP physical interface

7.  User equipment at SDP

8.  Applicable subnets/hosts

9.  User program operating systems

10. Client-server applications using the WAN

11. IP addresses of management workstations

12. Technical POC

**For ED3 and Internal ED8 VPN Subnet Tunnel Services**

1.  VPN subnet reference_name

2.  SDP (referenced by either a Connection_ID or a USI) of each end of
    each VPN tunnel

-   For an Internal ED8 VPN at least one SDP is required to be
    co-located with an Extranet Gateway

3.  Allowable Tunnel Protocols

4.  Allowable Tunnel Ports

5.  Address Range and Subnet Mask for each side of each VPN tunnel

6.  VPN subnet service Technical POC

7.  For Internal ED8 VPN subnets:

-   Anticipated number of external connections

-   Anticipated data rate of each external connection

**For External ED8 Services**

1.  Associated NAS System Internal VPN Subnet reference Name

2.  Source IP Address, Subnet, Host and Port of external user system
    access device

3.  ED8 service Technical POC

**For ED6 Services (in addition to BD1 Material)**

1.  Source Address, Subnet, Host and Port

2.  Destination Address, Subnet, Host and Port

3.  Technical POC

# Appendix G: Acronyms {#appendix-g-acronyms .unnumbered}

ADTN Agency Data Telecommunications Network

AH Authentication Header

AMS Acquisitions Management System

ANSI American National Standards Institute

ARTCC Air Route Traffic Control Center

ATC Air Traffic Control

ATCT Airport Traffic Control Tower

ATMS Asynchronous Transfer Mode Service

ATO Air Traffic Operations

BD1 Basic Data

BD2 Basic Data with IPSec AH

BGP Border Gateway Protocol

BNOCC Backup Network Operations Control Center (FTI)

Bps Bits per Second

BWM Bandwidth Manager

C&A Certification & Accréditation

CCITT Comite Consultatif Internationale de Telegraphique et Telephonique

CDRL Contract Deliverable Requirements List

COI Critical Operation Issues

CONOPS Concept of Operations

COS Class of Service

COTS Commercial off-the-Shelf

CPE Customer Premises Equipment

CPP Critical performance Parameters

CSIRC Computer Security Incident Response Center

DAA Designated Approving Authority

DCE Data Circuit Terminating Equipment

DDC Direct Digital Connectivity

DDS Digital Data Services

DMN Data Multiplexing Network

DMZ de-militarized zone

DNS Domain Name Service

DS Dedicated Service

DS-1 Digital Service-1

DS-2 Digital Service-2

DS-3 Digital Service-3

DTE Data Termination Equipment

DTS Dedicated Transmission Service

EAP Extensible Authentication Protocol

ED2 Encryption

ED3 VPN Technology

ED6 Packet Filtering Firewall

ED7 Bastion Host

ED8 Extranet Gateway for Untrusted Users

ED9 Extranet Gateway for Partially Untrusted Users

ED10 Extranet Gateway for Trusted Users

ESP Encapsulating Security Payload

F1 Fractional T-1

F3 Fractional T-3

FAA Federal Aviation Administration

FAATSAT FAA Telecommunications Satellite

FAC Facility Code

FAQ Frequently Asked Questions

FDDI Fiber Distributed Data Interface

FIRMNet FAA IP-Routed Multiuser Network

FNTB FTIN National Test Bed

FR Frame Relay

FRS Frame Relay Service

FSA Field Service Area

FTI FAA Telecommunications Infrastructure

FTP File Transfer Protocol

FTS 2001 Federal Telecommunications System 2001

FTSD FTI Telecommunications Services Description

HDLC High-Level Data Link Control

HSRP Hot Standby Routing Protocol

HTTP Hypertext Transfer Protocol

HW Hardware

Hz Hertz

IBS Integrated Business System (FTI)

ICD Interface Control Document

ICMP Internet Control Message Protocol

IETF Internet Engineering Task Force

IKE Internet Key Exchange

IP Internet Protocol

IPCP Internet Protocol Control Protocol

IPN Interior Protected Network

IPS Internet Protocol Service

IPSec IP Security

ISD IP Service Description

ISDN Integrated Services Digital Network

ISO International Standards Organization

ISS Information Systems Security

IT Interoperability Testing

Kbps Kilobits Per Second

Khz Kilohertz

LAN Local Area Network

LAPB Link Access Procedures, Balanced

LDRCL Low Density Radio Communications Link

LINCS Leased Interfacility NAS Communications System

LL Latency Limit

LLC Logical Link Control

MAC Media Access Control

Mbps Megabits Per Second

MOU Memorandum of Understanding

Ms Milliseconds

MSD1 Basic Mission Support Data Service

MTBO Mean Time Between Outage

MTTR Mean Time To Repair

NADIN National Airspace Data Interchange Network

NAIMES NAS Aeronautical Information Management

NAS National Airspace System

NAT Network Address Translation

NIMS NAS Infrastructure Management System

NMO Network Management and Operations

NNCC National Network Control Center (FAA)

NOCC Network Operations Control Center (FAA)

O&M Operations and Maintenance

OCC Operations Control Center (FAA)

OT Operational Testing

PAT Port Address Translation

PNOCC Primary Network Operations Control Center (Service Provider)

PO Program Office

POC Point of Contact

POP Point of Presence

PP Protection Profile

PPP Point-to-Point Protocol

PSN Packet Switched Network

QoS Quality of Service

RCL Radio Communications Link

RFC Request for Comments

RFS Request for Service

RMA Reliability/Maintainability/ Availability

RTP Real Time Protocol

SA Service Acceptance

SCAP Security Certification and Authorization Package

SDP Service Delivery Point

SIR Screening Information Request

SLIP Serial Line IP

SMO System Management Office

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SOC Service Operations Center (FAA)

SSC/WC Service Support Center/Work Center

SUI Security Users Interface

SWIM System Wide Information Management

T-1 1.544 Mbps (DS-1) Service

TBD To Be Determined

TCP Transmission Control Protocol

TDM Time Division Multiplexing

TOCC Technical Operations Control Center, a generic term for the FAA
control center (such as an OCC, SOC, etc.) serves as the operational
point of contact for an individual FTI service

TRACON Terminal Radar Approach Control Center

TSG Telecommunications Service Group

TSP Telecommunications Service Priority

TPP Telecommunications Program Plan

UDP User Datagram Protocol

UTP Unshielded Twisted Pair

UI User Interface

USI Unique Service Identifier

VG Voice Grade

VPN Virtual Private Network

WAN Wide Area Network

WJHTC William J. Hughes Technical Center

**APPENDIX H: Ops IP External User Service Connection Guidelines**

**(This appendix is being revised.)**

**Background / Purpose**

For the purposes of this document any system not in the FAA's National
Airspace System (NAS) security enclave is considered an external system.
This appendix provides guidance to external system owners for
provisioning a connection to a NAS system. External connections to a NAS
system require security controls as defined in the FAA
Telecommunications Infrastructure (FTI) Enhanced Data security - option
8 (referred to as ED8-enabled services). ED8-enabled services support
the establishment of virtual connections between NAS systems and
external systems. ED8 services can extend the NAS Ops IP network into an
"extranet" over non-FAA transport resources (such as the Internet or
Dedicated Transmission Services, DTSs). FTI ED8 extranet gateways
terminate all ED8-enabled services. The gateway makes use of IP Security
(IPSec) controls such as Virtual Private Networks (VPNs) to create
authorized connections between external systems and the ED-8 gateway;
these VPN tunnels are referred to as "Access VPN" security controls.
Similar security controls are used to connect the ED-8 gateway to the
desired NAS system; these Ops IP connections are referred to as an "Ops
IP VPN Subnet". Additional FTI Network security controls, referred to as
the ED8 Application Proxy, support the connection of access VPN tunnels
to the Ops IP VPN Subnet. The combination of Access VPN tunnels, FTI
network security controls and additional security controls implemented
by the NAS sponsor program are used to establish "Boundary Protection"
for critical NAS systems. Figure H-1 depicts a typical extranet
connection between a NAS system and an external system.

![](media/image13.wmf){width="5.999305555555556in"
height="2.186111111111111in"}

[]{#__RefHeading___Toc162244607 .anchor}Figure H-1. Ops IP Extranet
Connection

**Roles and Responsibilities**

*FAA Sponsor Program* -- Extranet services, by definition, provide a
service connection between a NAS system and an external system. It is
the responsibility of the NAS system participating in an extranet
service connection to be the "Sponsor Program" for the external system.
The FAA Sponsor Program manages the "application space" and associated
data with which an external user system interacts. This group acts as
the champion for establishing end-to-end connectivity services via FAA
telecommunications assets. They provide all application details (such as
ICDs), create Memorandum of Agreements (MOAs) and exchange technical
data required for establishing a connection, including the acquisition
of public IP address space through the FAA's centrally managed address
authority and managing data exchanges. The sponsor program is also
responsible for certifying the data quality, ensuring NAS system
integrity and ultimately obtaining authorization to connect the external
system to the Ops IP network.

*FAA Telecommunications Services Group (TSG)* -- TSG provisions and
manages all telecommunication services for the FAA including FTI and the
associated FTI Operational (Ops) IP network resources. The Ops IP
network provides network level connectivity between an FAA system and
the ED8 extranet gateway. The Ops IP network is thus the mechanism that
transfers IP packets between an FAA sponsor system and the internal side
of the extranet gateway. TSG accepts external service connection
requests from the NAS Sponsor Program and works with the Sponsor PO (and
the external system owner as required) to define extranet service
attributes:

1.  Connection attributes of NAS sponsor system to internal side of the
    extranet gateway

2.  Connection attributes of external end-user program to the external
    side of the gateway.

3.  Security control attributes of extranet gateway required for
    permitting information flows between the internal VPN Subnet and the
    access VPN tunnels.

Once the end-to-end service connection is understood and funded, TSG
submits service orders to the FTI vendor for the required ED8-enabled
services and associated security controls.

*FAA Telecommunications Infrastructure (FTI) Vendor* -- FTI Services
(including all Ops IP services and associated ED8-enabled extranet
services) are installed and operated by the FTI Vendor. Once extranet
gateway services are ordered, appropriate resources are installed and
configured by the FTI vendor. The FTI Vendor will work directly with the
external system technical staff to establish, configure and verify
connectivity to appropriate external systems as required. The Ops IP
staff operates network level services only and is not involved in the
design or specification of application layer services and associated
data exchanges.

*Extranet End-User* -- The Extranet end-user is the external
organization that intends to provide and/or consume NAS data. An
external system must comply with all FAA policies and technical
requirements as well as sign any MOAs required to operate. The end-user
should appoint a single point of contact to manage and oversee
establishment of connectivity. This is particularly required in
organizations where several departments are employed to build the
connection.

**Getting Connected**

The basic process for getting connected via an ED8 extranet gateway
service includes:

1.  Complete Initial Planning:

-   Work with FAA sponsor program to gather the necessary information on
    the application operation including Interface Control Documents
    (ICDs) and other guidance material.

-   Exchange IP address information (with NAS sponsor program and TSG
    engineers) necessary to configure the access VPN tunnels and allow
    the application to connect to the ED8 gateway. This data will be
    documented via an "IP Supplemental Form".

-   Verify extranet VPN equipment for compatibility with Ops IP access
    VPN requirements.

-   Complete and return any required program MOA/MOU.

2.  Establish Connection:

-   Work with the FTI Vendor (Harris) Ops IP staff to configure the
    access VPN tunnel between the external system access device and the
    FAA ED8 extranet gateway.

3.  Get Certified:

-   In some cases, it will be necessary to certify your system before it
    is allowed to communicate with FAA operational (NAS) systems. This
    may be accomplished by connection to an interim test system. This
    step is FAA sponsor program dependent and often includes
    interoperability testing with the FAA sponsor program.

4.  Begin Operation:

-   Once the FAA application sponsor grants permission to operate, you
    will be allowed the appropriate access to exchange data. Please see
    section below "Support Concept" for additional information.

**External End-User Security Responsibilities**

ED8-enabled services are used to establish virtual connections between
NAS systems and external systems not directly attached to the NAS.
ED8-enabled services thus facilitate the extension of the NAS network
into an "extranet" by using non-FAA transport resources (such as the
Internet or Dedicated Transmission Services, DTSs). Each end of an
extranet connection must be secured from hostile attack. Some NAS
programs require periodic audits to certify compliance with established
security requirements. The security requirements can vary by NAS
program, depending upon the sensitivity of the data. Complete detail for
a specific NAS program is provided in the MOA as developed by the
sponsoring NAS system for external users.

For the purpose of general guidance, the following notes are considered
standard practice in the establishment of security controls for
isolating processes that will connect to a NAS system via the Ops IP
extranet gateway (These descriptions reference terms as illustrated in
Figure H-1):

1.  External systems are required to install security controls to
    protect any application processing environment that interfaces to a
    NAS system via extranet services. The objective of external system
    security controls is to isolate the external processes, access
    devices and the associated ED8-enabled interface from other external
    systems and un-trusted user access.

2.  External system security controls are required to have the following
    properties:

    -   Established security policies

        i.  Have a documented security policy.

        ii. Demonstrate adherence to all security policies.

        iii. Security policy must allow only approved traffic flows.

        iv. Security policy must be granular enough to specify filtering
            based on source IP address, destination IP address, and
            ports.

    -   Security controls must protect the application environment and
        associated access device that that implements the user-side of
        the NAS Service Delivery Point (SDP).

        i.  Security controls and access device must be on the same
            platform, or the security controls must be between the
            access device and the Internet.

    -   The security controls must maintain logs that store data
        necessary to analyze a potential attack.

        i.  Logs must show detailed data on connection attempts and VPN
            negotiations.

        ii. Logs must be made available to FAA upon request.

    -   The security control must employ minimum firewall functionality
        such as stateful inspection.

    -   The client hosts (platforms for the external application
        processes and access device) participating in the access VPN
        must be protected from unauthorized access and Internet attack.

3.  An external user must run the VPN and security control software on a
    machine that runs a secured and hardened operating system.

4.  The user must maintain the remote end access VPN security control
    and additional firewall operating system software at a currently
    supported version and apply all appropriate system and security
    patches.

**Support Concept**

The FAA Sponsor Programs (example: Traffic Flow Management (TFM), NADIN/
Weather Message and Switching Center Replacement (WMSCR) maintain
operations staff and monitor the health of their program's applications
and associated extranet service instantiations. Individual application
support groups act as the one-stop hotline for interaction with external
customers, providing all coordination and assistance for application
based operations. Ops IP Network operations provide support only after
it has been determined to be a network / extranet service connectivity
issue. [FTI does not monitor individual user VPNs]{.underline} and is
not aware of the state of applications. For these reasons it is critical
that all support be coordinated though the sponsor program.

**\
Ops IP Access VPN Tunnel Technical Requirements**

To establish and operate an access VPN service to the ED8 extranet
gateway, external users must comply with all security configurations as
well as be compatible with ED8 gateway equipment. IPSec encompasses a
suite of protocols, however the FAA reserves the right to dictate
particular choices to meet best practices and security mandates. In
general, to establish extranet services users must:

-   Provide one or more fixed public IP addresses for the access VPN to
    the gateway (to be provided via the IP Supplemental form for
    external end-users). It is the responsibility of the NAS sponsor
    program to provide the data, but it is the responsibility of the
    external user to coordinate with both the NAS sponsor program and
    the TSG engineering staff to obtain all required information and
    configure the access VPN tunnel.

-   Comply with standard ED8 access VPN service / IPSec settings:

    -   Encapsulation Security Payload (ESP)

    -   Encryption: AES-256

    -   Authentication: SHA-1

    -   IPSec / IKE Authentication: Pre-shared secret and digital
        certificate

    -   IKE phase 1: Diffie-Hellman group 5

    -   Perfect Forward Secrecy (PFS): Diffie-Hellman group 1

    -   Pre-shared secret key (to be exchanged at the time of VPN
        establishment)

> Note: Ops IP Network does not use simplified mode, aggressive mode or
> VPN communities for ED8 access VPN tunnels.

-   Conservatively configure security settings to permit only the
    required application traffic. The IP source, destination, and ports
    must be fully specified.

> Example:
>
> Client source IP: x.x.x.x
>
> Destination IP (Server): y.y.y.y
>
> Destination TCP Port: 3000

-   Prohibit all other access.

**Equipment Compatibility**

All ED8 access VPN tunnels created between the FAA and external end-user
systems are based on IPSec. Vendor implementation variances could result
in compatibility problems even though IPSec is an open suite of
standards (see RFC 2401 for general information). The likelihood of
vendor incompatibility has diminished significantly over the last
several years.

Cisco appliances are used to decrypt/terminate ESP IPSec tunnels between
the FAA and external users. Below is the vendor documentation listing
its compatibility with other Cisco products as well as known alternative
vendors for this functionality. The lists may not be complete and should
not be regarded as mandatory. It is provided simply as a courtesy to
potential end-users.

Site-to-Site VPN Compatibility Between FTI Cisco Appliance and Other VPN
Products

  ------------------------- ---------------------------------------------
  VPN Gateway               Versions Supported

  Cisco ASA 5500 Series     Cisco ASA Software Version 7.0(1) and later
  Appliances                

  Cisco IOS Software        Cisco IOS Software Release 12.1(6)T and later
  Routers                   

  Cisco PIX Security        Cisco PIX Security Appliance Software Version
  Appliances                6.0(1) and later

  Cisco VPN 3000 Series     Cisco VPN 3000 Series Concentrator Software
  Concentrators             Version 3.0 and later
  ------------------------- ---------------------------------------------

The following products have been tested successfully with the FTI Cisco
Appliance Key exchange and ESP encryption:

  ------------------------------------------------------------ ----------------------------- ------------ ----------------
  Vendor                                                       Product                       Product      Operating System
                                                                                             Version      

  [[Check Point                                                \*Checkpoint VPN-1/Firewall-1 R60          customized Linux
  Software]{.underline}](http://www.checkpoint.com/)           NGX on SecurePlatform                      

  [[Check Point                                                Checkpoint VPN-1/Firewall-1   R60 HFA03    SecurePlatform
  Software]{.underline}](http://www.checkpoint.com/)           NGX on SecurePlatform                      

  [[Cisco Systems]{.underline}](http://www.cisco.com/)         Cisco 87x & 18X Integrated    12.4(6)T2    Proprietary
                                                               Service Routers                            

  [[Cisco Systems]{.underline}](http://www.cisco.com/)         \*Cisco IOS Router Family     12.4(1a)     Proprietary
                                                               Vers 12.4(1a)                              

  [[Cisco Systems]{.underline}](http://www.cisco.com/)         Cisco IOS Router Family Vers  12.4(6)T     Proprietary
                                                               12.4(6)T                                   

  [[Cisco-Linksys]{.underline}](http://www.linksys.com/)       BEFVP41                       2.0          Proprietary

  [[FortiNet Inc.]{.underline}](http://www.fortinet.com/)      FortiGate Family of Antivirus 2.80         FortiOS V2.8
                                                               Firewalls                                  

  [[Huawei-3com]{.underline}](http://www.huawei-3com.com/)     \*Quidway SecPath Security    3.30         Proprietary
                                                               Gateway Family                             

  [[Intoto Inc.]{.underline}](http://www.intoto.com/)          iGateway                      3.3SP1P25    Proprietary

  [[Juniper Networks]{.underline}](http://www.juniper.net/)    Netscreen Security Gateway    5.0.0r4      Proprietary
                                                               Product Group                              

  [[Lucent Technologies]{.underline}](http://www.lucent.com/)  \*Lucent VPN Firewall IPsec   8.0.302      Proprietary
                                                               Product Group                              

  [[Lucent Technologies]{.underline}](http://www.lucent.com/)  Lucent VPN Firewall IPsec     8.0.396      Proprietary
                                                               Product Group                              

  [[Secure Computing                                           Sidewinder G2 Firewall        6.1.0.00     Proprietary
  Corporation]{.underline}](http://www.securecomputing.com/)                                              

  [[Stonesoft                                                  StoneGate Firewall            2.61         customized Linux
  Corporation]{.underline}](http://www.stonesoft.com/)                                                    

  [[TippingPoint, a division of                                TippingPoint X505             2.2.4.6517   Proprietary
  3Com]{.underline}](http://www.tippingpoint.com/)                                                        
  ------------------------------------------------------------ ----------------------------- ------------ ----------------