Wireless network operators and end users need the ability to utilize equipment from dif- ferent vendors in their networks and in customer-accessible devices. Left to themselves, vendors of network equipment and of end-user access devices such as wireless terminals tend to produce equipment that is slightly different in various ways, hindering the ability of their customers to build multi-vendor networks from interoperable equipment pieces. The key to ensuring interoperability is to have a standardized system design with clearly specified interfaces between the various network devices and well-designed, standard- ized protocols on the interfaces. The process of systematically identifying requirements and functionality and mapping that into network entities, interfaces, and standardized protocols is the key to ensuring a design that meets real-world needs and in which the pieces work together well. This requirement is generally true for network systems, but it also applies specifically to security systems.
While standardization is the key to ensuring interoperability in complex multi-vendor systems, system architectures are the principal tool for guiding the design, implementa- tion, and deployment process. In this chapter, we examine the topic of network system architecture. In the next section, we discuss the role of architecture in system standard- ization in more detail. Following that, we describe a particular approach to developing a system architecture, the functional architectural approach, that is used in some wireless network standardization processes. We use this approach throughout the book to analyze existing wireless security system architectures, and ultimately in Chapter 7 to add new security architectural enhancements to existing IP systems. To illustrate how network system architectures are developed, we present a simple example of a wireless network system architecture, a key fob used to remotely open a locked car. We then specifi- cally examine how the functional architecture approach worksf
or security systems by developing a functional architecture that provides security for the key fob.
Most large wireless network systems are developed as part of a standardization process involving multiple vendors and network operations. Since the components of such systems are often manufactured by many vendors and the systems are deployed by many network operators, standardization ensures interoperability between equipment from different vendors and deployments by different operators. The first step in developing anew or enhanced standardized wireless network system is to define a system architecture. The term “architecture” is used in a variety of ways to characterize the initial output of the design process. Webster’s Dictionary defines architecture as (among other things) “a style or method of design or construction.” The approach to architecture for a large- scale wireless network system depends on the process traditionally followed by the standardization body.
Most wireless standardization groups have their heritage in the traditional circuit- switched telephony architecture that was common prior to the widespread adoption of the Internet. These groups adhere to a rigorous system development process, in which formal requirements development is followed by an architectural development phase centered on meeting the requirements. The architectural development phase results in the definition of network boxes with interfaces on which the functions of interoperable protocols are specified. Protocol selection or design follows, after which a formal regression analysis is performed to ensure that the resulting system meets the initially defined requirements. The boxes and protocols are then implemented by vendors as products.
While such a rigorous design process ensures accountability and fidelity with the original requirements, it is often inflexible and unable to account for changes in require- ments that come up later in the design process. The process is similar to a waterfall in which the requirements, architecture, protocol design, and implementation fall out of the standardization process like water pouring over a waterfall. Incremental modifications are inhibited, since they are not accommodated by a waterfall development model. The strong emphasis on using the requirements to rigidly structure the architecture often results in pressure by various participants in the standardization process to “game” the requirements, to ensure some advantage for their business or technical positions against their competitors. As a result, the accountability and objectivity that the process was originally intended to provide is usually considerably weakened; most of the important decisions are based on the same kinds of subjective criteria
that are behind group decision making in other areas of human endeavor where interests of various parties conflict.
On the other hand, the group responsible for standardizing Internet protocols, the Internet Engineering Task Force (IETF), has traditionally resisted formal architectural definitions on the Internet as a large-scale system. The rationale for this is that, for the Internet as a whole, any attempt to define a detailed architecture would constrain the development of new protocols and new applications too tightly. One of the key factors in allowing the Internet to flexibly accommodate a new generation of applications every five to ten years is the lack of a rigidly fixed architecture overall. Consequently, discussions of architecture at the level of the Internet as a whole are typically confined to a loose collection of design principles, such as those in RFC 1958 (RFC 1958), or adherence to the modified form of the OSI protocol stack (Layer 2, Network, Transport, Application) which informs the design of the IP network stack (Wikipedia, 2008a). As a result, when wireless links became available in the late 1990s,
there was no global system architecture for the Internet to guide standardization of interfaces and protocols for wireless networks.
As the Internet has become more complex, however, architectural definitions of well- defined subsystems have become necessary to guide protocol development and ensure