Internet DRAFT - draft-candolin-cam
draft-candolin-cam
INTERNET-DRAFT Catharina Candolin
Expires: 24 December 2002 Hannu H. Kari
Helsinki University
of Technology
Context Aware Management Architecture
<draft-candolin-cam-00.txt>
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 <PM> with the given parameters to CAM.
(2) PM->CAM: deregister(PM) The function deregisters the policy
manager <PM> from CAM.
(3) PM->CAM: set(module, parameter, value) Sets the value of the
<parameter> in <module> to <value>
(4) PM->CAM: get(module, parameter) Gets the value of <parameter> in
<module>
(5) CAM->PM: event(module, parameter, value) Requests an event to
be issued to <module> when <parameter> reaches <value>
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 <module>
with the given parameters to CAM
(2) Module->CAM: deregister(module) Deregisters <module> from CAM
(3) Module->CAM: set(module, parameter, value) Sets <parameter> in
<module> to <value>
(4) Module->CAM: get(module, parameter) Gets the value of
<parameter> in <module>
(5) CAM->Module: event(parameter, value) Issues an event to the
module, assigning <parameter> to <value>
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
