INTERNET-DRAFT Catharina Candolin Expires: 24 December 2002 Hannu H. Kari Helsinki University of Technology Context Aware Management Architecture Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Most protocols and applications are designed for connections that are fairly static. When a node changes its point of attachment to the Internet frequently, it must be able to rapidly adapt to the new environment. Traditionally, each application and protocol tries to do this independently of each other. In some cases, applications have been tailored to communicate with one other protocol layer to notice such changes. The main problem with this approach is that adding new protocols and applications to the node cannot be made in a generic way. In order to obtain at least some level of context awareness, protocols and applications must be specifically tailored to intercommunicate. This also adds complexity to application and protocol design, since protocols and applications perform a wide range of tasks for which they have not originally been designed. To overcome these problems, we add a new Context Aware Management (CAM) layer to the Internet Protocol stack. The purpose of CAM is to optimize the functionality of the node by monitoring the environment for changes and by adapting the behavior of the node accordingly. The protocols and applications thus perform the tasks for which they have been designed in the first place, and CAM makes the decisions regarding which protocols to use and with what parameters. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 1.2. Terminology . . . . . . . . . 2. The Context Aware Management Architecture . . . . . . . . . . . 3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. CAM-PM interface . . . . . . . . . . . . . . . . . . . . 3.2. CAM-Module interface . . . . . . . . . . . . . . . . . . 3.3. PM functionality. . . . . . . . . . . . . . . . . . . . . 4. Security considerations . . . . . . . . . . . . . . . . . . . . 5. Ad hoc networking considerations . . . . . . . . . . . . . . . 5.1. The CAM-to-CAM module . . . . . . . . . . . . . . . . . . 5.2. Security considerations . . . . . . . . . . . . . . . . . 6. Error messages . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . A. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction Most protocols are designed for connections that are fairly static. When the node changes its point of attachment to the Internet on frequent basis, it must be able to adapt to the new environment rapidly. If the reaction is too slow, the result may be: (1) The quality of service is bad. For example, the transmission of a video stream may be glitchy or the service cannot be provided at all. (2) Resources are wasted. For example, a video stream is transferred from the server to the access network, but the access network is unable to deliver the stream to the mobile node. (3) An uneconomical connection is used. For example, the node has several connections to the Internet, but uses one that is more expensive than another. (4) The decisions are not optimal. For example, the mobility management system chooses a non-optimal access medium. Traditionally, each application or protocol tries to adapt to the new environment independently. In some solutions, an application is specifically tailored to communicate with one other protocol layer. For example, the Real Time Protocol (RTP) [RTP] (and its control protocol RTCP) monitors the quality of the connection and informs the application (e.g. the multimedia video player) about degradation in quality. The application then changes the video encoding to better suit the current quality of the connection. Another example is a combination of Mobile IP [MIP] with a mechanism for choosing the access medium considered optimal for the applications. The main problems with current solutions are the following: (1) The solutions are not generic. Thus, it is hard to add context awareness to protocols and applications. (2) Protocol and application design becomes complex, as each protocol and application has to be tailored to intercommunicate with each other. (3) Old protocols and applications cannot take advantage of information provided by new protocols or applications without modification. To overcome these problems, a new Context Aware Management (CAM) layer is added to the Internet protocol stack. The purpose of CAM is to monitor the environment for changes and to adapt the behavior of the node to the current environment. The applications and protocols need not be aware of the environment at all, but rather focus on taking care of the tasks they have been designed for in the first place. For example, a routing protocol is responsible for establishing routes and forwarding packets, but need not handle issues regarding the choice of access medium. The decisions how to change the behavior of the node are made by the Policy Manager (PM). Furthermore, the architecture consists of a common database, which contains all environment related data of the node. The database is accessed via CAM. Protocols and applications communicate with each other and with the database through CAM, using a standard interface. 1.1. Applicability In principle, the CAM architecture MAY be applied to any IPv4 or IPv6 protocol stack. Currently, this specification is purely EXPERIMENTAL in nature. 1.2. Terminology Ad hoc network A collection of nodes that do not need to rely on a predefined infrastructure to keep the network connected. Nodes participate in network operations, such as routing and network management. CAM layer Context Aware Management layer added to the Internet Protocol stack. CAM offers the interface between the modules, the common database, and the policy manager. CDB Common database for storing all environment specific data that is common to several modules. Module A protocol, application, device driver, or other piece of software that is attached to the CAM layer. A module residing on another node is called a "remote module". Node A network host. PM The Policy Manager of CAM. PM processes requests and is responsible for making decisions regarding the functionality of the node. Request Queue A data structure for processing requests. The modules write to the queue and the PM read from the queue. Requests may be assigned a priority. 2. The Context Aware Management Architecture To enable a node to adapt its behavior according to its current environment, a Context Aware Management (CAM) layer is added to the Internet protocol stack. The purpose of CAM is to allow modules to perform the tasks to which they are dedicated while allowing CAM to make decisions regarding the operation of the node. Furthermore, modules should not need to be aware of each other to take advantage of environment related information. CAM therefore functions as a common layer through which modules may communicate in a standard fashion. In the figure below, a conceptual model of the CAM architecture is depicted. ___ |PM | --- | _______________ ______________ | APPLICATIONS |<---->| | --------------- | | | | ___________________ | | |MOBILITY SECURITY | | | |QoS ACCESS CONTROL|<->| | -------- |MULTICAST | | CONTEXT AWARE| |COMMON | ------------------- | MANAGEMENT |<-->|DATABASE| | | | LAYER | -------- | ___________ | | | | AD HOC |<->| | | | NETWORKING| | | | ----------- | | | | | | __________________  | | | IP |<->| | ------------------ | | | | | __________ | | |ACCESS |<--------->| | |INTERFACES| | | ---------- -------------- The CAM architecture contains the following components: (1) The Context Aware Management (CAM) layer. (2) The Policy Manager (PM) (3) The common database (CDB) (4) The modules attached to CAM. The purpose of CAM is to provide a common layer to all modules that operate in the node to allow the node to behave in a manner optimal to the current environment. CAM offers two interfaces; one to the modules and one to the PM. The interfaces are presented in section 3. The PM is responsible for making the decisions regarding how the behavior of the node should be changed. The PM is aware of all modules that are loaded into the node. The PM also maintains the state information of each module. Thus, it is possible for the PM to make complicated decisions regarding the functionality of the node. For example, if the node enters an ad hoc network, the PM makes the decision regarding which routing protocol to use and with what parameters. If the node changes to another ad hoc network that uses another routing protocol, the PM may switch off the old protocol and switch on another. Another functionality provided by CAM is event handling. A module may request the PM to send a wake up signal upon the occurrence of a given event. For example, an application may request the PM to signal it once a given QoS level can be offered. This may occur when a network interface (e.g. a WLAN driver) informs the PM of a base station with sufficient signal strength. The security management module of the node may have declared that the given base station is on the list of trusted base stations and access could thus be allowed. The PM then informs the mobility management protocol to make a location update through the given base station. Once the connection is established and the required level of QoS can be offered, the PM informs the application. The CDB contains all information that is common to several modules. In principle, the CDB is itself regarded as a module. Access to the CDB is managed through CAM and controlled by the PM. The modules are the protocols, applications, device drivers, and other pieces of software that communicate with each other and the PM via CAM. Modules are organized in a hierarchical fashion so that e.g. all network modules are organized under the category "access devices" etc. Thus, the PM is able to recognize new modules without modification. 3. Interfaces CAM contains two standard interfaces: one for communication between CAM and PM, and one for communication between CAM and the modules. 3.1. CAM-PM interface The CAM-PM interface is defined for communication between CAM and the PM. The CAM-PM interface provides the following functions: (1) PM->CAM: register(PM, parameters) The function registers the policy manager with the given parameters to CAM. (2) PM->CAM: deregister(PM) The function deregisters the policy manager from CAM. (3) PM->CAM: set(module, parameter, value) Sets the value of the in to (4) PM->CAM: get(module, parameter) Gets the value of in (5) CAM->PM: event(module, parameter, value) Requests an event to be issued to when reaches 3.2. CAM-Module interface The CAM-Module interface is defined for communication between CAM and the modules. The CAM-Module interface provides the following functions: (1) Module->CAM: register(module, parameters) Registers with the given parameters to CAM (2) Module->CAM: deregister(module) Deregisters from CAM (3) Module->CAM: set(module, parameter, value) Sets in to (4) Module->CAM: get(module, parameter) Gets the value of in (5) CAM->Module: event(parameter, value) Issues an event to the module, assigning to 3.3. PM functionality CAM processes the requests made by modules by placing them into a Request Queue. Requests may be prioritized so that some requests made by certain modules are guaranteed to be handled as soon as possible whereas other requests may need to wait longer to be scheduled. Furthermore, if the queue fills up, the requests with lower priority will be dropped first. The PM processes the requests from the queue by first checking that the module is authorized to make the given request. If the request is valid, the PM will process it accordingly, otherwise the request will be dropped and the PM will send the module a REQUEST DENIED error message. 4. Security considerations When a module registers itself, it may provide CAM with some proof or statement signed by a trusted authority stating that the module does what it claims to do and nothing else. The PM may check this statement by verifying the signature. If the PM does not allow the module to be loaded, it will send the module a REQUEST DENIED error message. Otherwise, the module will be loaded and is thereafter considered to be completely trustworthy. This means that the module will be granted the permission to perform specific actions in the node. Verifying the trustworthiness of modules is optional. When initializing the modules, the PM grants them a set of privileges stating which actions they are allowed to perform in the node. When a module issues a request, the PM verifies that the request is authorized. The CDB contains all security related information, such as cryptographic key material, that is common for several operations of the node. For example, the CDB contains the cryptographic keys that form the identity/identities of the node. The CDB also contains information regarding which access networks provide the promised quality of service and level of security, etc. When engaging in ad hoc network communications where the CAM layers of several different nodes communicate and exchange information, security must be considered both from the network point of view and the node point of view (e.g. access control and authorization). These issues are briefly discussed in section 5.2. [The complete security requirements and solutions of CAM are TBD.] 5. Ad hoc networking considerations To allow nodes to share and distribute information dynamically and efficiently, the CAM layers of different nodes in the network may exchange information and make requests to each other. To perform this task, a protocol for CAM intercommunication is needed. The protocol is briefly described in section 5.1. and the security requirements related to the protocol and to network requests in general are discussed in section 5.2. 5.1. CAM-to-CAM module The CAM-to-CAM protocol must in principle be able to perform the following tasks: (1) The protocol must be able to send requests to other nodes in the network. (2) The protocol must be able to handle requests received by other nodes in the network. To achieve these tasks, a CAM-to-CAM module is defined. The CAM-to-CAM module provides the protocol for exchanging information and also provides CAM with a list of remote modules. Thus, the PM is able to determine what sort of information it may exchange with other nodes. When issuing a request to another node, the PM delivers the request to the CAM-to-CAM module, which delivers the message to the other node and handles the response, which it returns to the PM. When the CAM-to-CAM module receives a request from the network, it performs the necessary security verifications, assigns the request a priority, and places the it in the Request Queue. The PM processes the request as if it were local to the node and delivers the response to the CAM-to-CAM module. The CAM-to-CAM module then delivers the response back to the sender of the request. 5.2. Security considerations The main security requirements of the CAM-to-CAM module are the following: (1) Data origin authentication: CAM-to-CAM must be able to determine that the sender of the message is who it claims to be. (2) Integrity verification: CAM-to-CAM must be able to determine that the message has not been tampered with. (3) Timeliness: CAM-to-CAM must be able to determine that the message received is not a replay. (4) Access control: CAM-to-CAM must be able to determine whether the request is authorized and to process the request accordingly. Requirements 1-3 are assumed to be handled by another module, for example, IPSec AH or ESP [IPS][AH][ESP]. The CAM-to-CAM module will thus only receive packets that meet these requirements, as other packets are dropped. However, the CAM-to-CAM module should consider requirement 4. If the requester provides CAM-to-CAM with a certificate or some other form of signed statement of the requested privileges, CAM-to-CAM verifies the signature and allows or denies access based on the success of verification. Such certificates are typically issued by the node itself. In this case, CAM-to-CAM verifies the signature(s) in the certificate or certificate chain to determine whether the original issuer was CAM itself. If the requester does not possess a certificate of this kind and the nodes have no prior knowledge of each other, CAM-to-CAM may request a Trusted Third Party (TTP) in the environment to serve as a recommender. If no such TTP exist, the CAM-to-CAM must itself determine whether to accept the request or not. This decision is made based on the policy of the node, which in turn has been specified by the PM. 6. Error messages The error messages include: [TBD] (1) REQUEST DENIED This error message is sent to all modules that have made unauthorized requests. (2) REQUEST FAILED This error message is sent to all modules for which the request has been accepted but for which the processing of the request has failed. (3) ... References [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998 [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [IPS] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [MIP] D.B. Johnson, C. Perkins, J. Arkko, " Mobility Support in IPv6", Internet-Draft draft-ietf-mobileip-ipv6-17.txt, Internet Engineering Task Force, May 2002. [RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889. Authors' Addresses Catharina Candolin Helsinki University of Technology Laboratory for Theoretical Computer Science P.O. Box 5400 FIN-02015 HUT Finland Phone: +358 9 4515189 EMail: Catharina.Candolin@hut.fi Hannu H. Kari Helsinki University of Technology Laboratory for Theoretical Computer Science P.O. Box 5400 FIN-02015 HUT Finland Phone: +358 9 4511 EMail: Hannu.Kari@hut.fi Appendix A: Future work Future work include, but is not limited to: (1) The interfaces of CAM are more specifically defined. (2) The security architecture for CAM is designed. First, the requirements are specified and thereafter the appropriate security solutions are embedded in the architecture. (3) The CAM-to-CAM ad hoc networking module is defined. (4) Error messages are properly developed and defined. (5) The hierarchical structure of the modules are specified. Expires 24 December 2002