Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

trusted environment. These protocols either had very weak security (ARPA services) or no
security at all (IP, UDP, TCP). As the Internet grew and evolved into an untrusted environment,
the security provisions of the IETF’s protocols improved. Security enhancements (i.e., Internet
protocol security (IPsec) for IP, transport layer security (TLS) for TCP) and protocol
replacement Secure Shell (SSH version (v)2 replaces the file transfer protocol (FTP), trivial file
transfer protocol (TFTP), and Telnet ARPA services) were devised so that most of the original
protocols could be secured. The security provisions of the newer IETF protocols reflect the
security knowledge of the era when the protocol was designed. Certain protocols, therefore,
were designed with what proved over time to have security limitations that thwarted their ability
to evolve as best current practice network security evolved. Other protocols do not have these
limitations and thus are able to use Federal Information Processing Standard (FIPS)-compliant
encryption algorithms and keying material.
In all cases, the security provisions of IETF protocols are optional. Secured protocol
deployments are unable to interoperate with unsecured protocol deployments. Originally, few, if
any, deployments deployed IETF protocols with their security features turned on. More
deployments have been configuring their systems to use these security features since network
attacks have become increasingly common.
An attribute defining the IETF work in general is that they did not design their protocols in terms
of a common top-down systems perspective. They were designed in a piecemeal fashion to
resolve specific technology needs as they were identified over time. Until recently, lessons
learned from the development of one protocol were incompletely applied to the development of
other protocols. The lessons learned were not completely applied because the working group
developing that protocol was composed of specialists for that particular technology, who may or
may not be aware of how similar problems were addressed by other IETF working groups. Also
until recently, the security provisions of protocols were designed in isolation, usually without
reference to the security provisions used by other IETF protocols. As of mid 2006, the IETF has
yet to begin trying to orchestrate the key management requirements of the various protocols that
populate the IP family. As a result, the cumulative key management requirements for the IP
family are varied and extraordinarily complex, with most protocols approaching key
management in a unique and idiosyncratic manner. Worse, different implementations of the
same protocol on different platforms usually have devised key management mechanisms that are
unique to that implementation only. Thus, a very large diversity of key management approaches
currently exist across the COTS Internet products. However, a few general patterns can be
abstracted. These patterns are:
• Router-to-router protocols (e.g., open shortest path first (OSPF), BGP, and multicast
open shortest path first (MOSPF)) generally need to be configured with identical
passwords and symmetric keys for their communicating interfaces. The specific
mechanism for accomplishing this varies widely between differing implementations of
the same protocol. Although these protocols have similar algorithms, they are
implemented differently on each protocol. For example, although OSPF and BGP use
common password and symmetric keys, on OSPF, this is done on an area basis, while on
BGP, it is done on a per interface basis. Please note from table 1 that the Linux
implementations of BGP do not support MD5 authentication as of 2005.
42