Internet DRAFT - draft-boucadair-netconf-req
draft-boucadair-netconf-req
netconf Working Group M. Boucadair
INTERNET-DRAFT C. Jacquenet
Document: draft-boucadair-netconf-req-00.txt M. Achemlal
Category: Informational Y. Adam
Expires January 2005 France Telecom
July 2004
Requirements for Efficient and Automated Configuration Management
<draft-boucadair-netconf-req-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Given the ever-increasing importance of configuration tasks for the
provisioning of a wide range of IP resources, networks, and services
in today's Internet, this draft aims at listing the basic
requirements that should drive the specification of a protocol to
convey configuration information towards network devices. This memo
doesn't aim at listing candidate protocols to convey such
information, nor at choosing one of these. This draft basically
describes a whole set of issues a service provider has to deal with,
hence a list of requirements to better address such issues.
Table of Contents
1. Introduction................................................3
2. Conventions used in this document...........................3
3. Terminology.................................................3
4. Motivations and Goals.......................................5
Boucadair Informational - Expires January 2005 [Page 1]
Internet Draft Network Configuration requirements July 2004
5. Positioning this Draft within the NETCONF Working Group.....5
6. Current Issues with Configuration Procedures................6
6.1. Protocol Diversity..........................................6
6.2. Topology Discovery..........................................6
6.3. Device capabilities discovery...............................6
6.4. Impact on the performance...................................7
6.5. Scalability.................................................7
6.6. Automation..................................................7
6.7. Security issues.............................................8
7. Towards a Service-Oriented Configuration Policy.............8
8. Requirements................................................9
8.1. Protocol Requirements.......................................9
8.1.1. Functional Requirements.....................................9
8.1.2. Performance requirements...................................10
8.1.3. Backward Compatibility.....................................10
8.2. Information requirements...................................10
8.2.1. Network services...........................................11
8.2.1.1. Identification of Interfaces.............................11
8.2.1.2. Quality of Service (QoS).................................12
8.2.1.3. Security.................................................12
8.2.1.4. Applications.............................................12
8.2.2. Forwarding services........................................13
8.2.2.1. Routing and Forwarding Configuration Information.........13
8.2.2.2. Traffic Engineering Configuration Information............13
8.2.2.3. Configuration Information for Tunnel Design and
Activation...............................................13
8.2.2.4. Tunnel Identification Information........................14
8.2.2.5. Tunneling Protocol Configuration Information.............14
8.2.3. Management services........................................14
8.2.3.1. Fault Management.........................................14
8.2.3.2. Configuration Management.................................14
8.2.3.3. Performance Management...................................15
8.2.3.4. Security Management......................................15
8.2.3.4.1. Device Authentication..................................15
8.2.3.4.2. Integrity of configuration information.................15
8.2.3.4.3. Confidentiality of exchanged data......................15
8.2.3.4.4. Key management.........................................16
8.2.3.4.5. Log of connections.....................................16
8.2.3.4.6. Profiles...............................................16
9. Security Considerations....................................16
10. References.................................................16
11. Acknowledgments............................................17
12. Authors' Addresses.........................................17
Boucadair et al. Informational - Expires January 2005 [Page 2]
Internet Draft Network Configuration requirements July 2004
1. Introduction
In today's Internet, configuration procedures are achieved by
technical personnel who's required an ever-growing level of expertise
because of the various technologies and features that need to be
used, configured and activated to deploy a wide range of IP service
offerings. This level of expertise has become mandatory as each
equipment manufacturer has developed its own interfaces and
configuration schemes. In addition, as IP services may rely upon the
activation of a set of sophisticated yet complex features, the time
to adequately provision such services is also increasing.
As a consequence, the specification and the use of standardized
protocol (for conveying configuration information) and interfaces
SHOULD dramatically help in facilitating if not automating the
configuration process and the operational production of a wide range
of IP services.
This draft aims at describing basic requirements for configuration
task purposes, from a service provider perspective.
This document is structured as follows:
- Section 3 introduces some terminology that is used by this
document
- Section 4 presents the goals and motivations of this draft
- Sections 5 position this draft within the current netconf
working group initiative.
- Section 6 summarizes important issues that are related to
configuration tasks in today's IP networks.
- Section 7 discusses the importance of introducing a service-
oriented configuration scheme.
- Section 8 lists configuration information and protocol
requirements.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
3. Terminology
This section aims at providing a set of basic definitions for the
terms that will be used by this document.
. Decision point: is an entity that is responsible for generating
decisions related to configuration tasks that yield the
production of configuration data which needs to be conveyed
Boucadair et al. Informational - Expires January 2005 [Page 3]
Internet Draft Network Configuration requirements July 2004
towards (and processed by) a participating device.
. Endpoint: one of the extremities of a tunnel.
. Participating device: any networking equipment that will
participate in the establishment, the activation and the
maintenance of a given network service. Such devices may
include routers and hosts, whatever the configuration
procedures and underlying technologies to be used for the
deployment of such service.
. Subscriber: A subscriber (or a customer) is a legal
representative who has the (legal) ability to subscribe to a
service offering.
. Tunnel activation: the configuration tasks that position a
tunnel facility into an activated state, so that it can be used
to convey traffic. Obviously, a tunnel must not (and,
hopefully, cannot) be activated before it has been established.
. Tunnel establishment: all the configuration tasks that lead to
the configuration of a tunnel facility. Once the tunnel is
established, it needs to be activated in order to be able to
convey traffic.
. Tunnel maintenance: the period of time during which a tunnel
facility remains activated.
. Tunnel: a tunnel is a transport facility that is designed to
convey' (IP) data traffic between one endpoint and another
(point-to-point tunnels), or between one endpoint and several
others (point-to-multipoint tunnels). Tunnels can be used for
different purposes, e.g.:
- Access IP multicast networks over IP clouds that do not
support multicast forwarding capabilities,
- Access IPv6 networks over IPv4 clouds,
- Deploy IP Virtual Private Networks,
- Deploy Mobile IP architectures.
. User: A user is an entity (a human being or a process, from a
general perspective) who has been identified (and possibly
authenticated) by a service provider, and who will access this
service offering according to his associated rights and duties.
. VPN: Virtual Private Network. A collection of switching
resources (e.g. routers) and transmission resources that will
be used over an IP backbone thanks to the establishment and the
activation of tunnels. These tunnels will convey the IP traffic
that characterizes the data oriented-communication service of a
customer (VPNs that are designed to support intranet-based
Boucadair et al. Informational - Expires January 2005 [Page 4]
Internet Draft Network Configuration requirements July 2004
applications) or a set of customers (VPNs that are designed to
support extranet-based applications). Thus, IP VPN networks are
an applicability example of tunnel configuration and management
activities.
4. Motivations and Goals
Operators and protocol developers have gained experience to
implement, deploy and manipulate a large set of protocols and
associated information. Some data models have also been defined for
network management purposes. Thus, several protocols have been
standardized, such as SNMP (Simple Network Management Protocol, RFC
3410([3])), COPS (Common Open Policy Service, RFC 2748([4])), (COPS-
PR, RFC 3084([5])). Multiple data models have been defined and used
by operators like: CIM (Core information model, [6]), DEN (Directory
enabled Network), SMI (Structure of Management Information, [7]),
SPPI (Structure of Policy Provisioning Information, [8]), MIB
(Management Information Base), PIB (Policy Information Management)à
Despite this standardization effort, some operators and
standardization bodies address a negative report (RFC3535) about the
capacity of existing tools to deal with operator's requirements about
network management and configuration operations.
The purpose of this document is to clarify what are such requirements
from a configuration task perspective. This initiative also aims at
gathering any feedback from other service providers or vendors in
order to agree on a common yet consolidated set of requirements,
which SHOULD dramatically help in facilitating if not automating the
configuration process and the operational production of a wide range
of IP services.
5. Positioning this Draft within the NETCONF Working Group
In mid-2003, the IETF netconf (Network Configuration) working group
has been set up. The main objective of netconf is to produce a
protocol suitable for network configuration. A proposal to use XML
(Extensible Markup Language) for configuration purposes has been
adopted. The choice of this technology hasn't been motivated nor
discussed by some formal document yet.
For instance, neither an analysis of existing configuration-based
protocols nor a requirement draft have been published. Therefore,
there is no explicit consensus about this technical choice (possibly
an implicit consensus between some netconf WG members). Because of
the lack of guidance documents (framework and requirement documents)
and also of a clear view on the actual requirements, the netconf
working group may experience some difficulties to make the Internet
community widely adopt its ongoing protocol specification effort.
Boucadair et al. Informational - Expires January 2005 [Page 5]
Internet Draft Network Configuration requirements July 2004
6. Current Issues with Configuration Procedures
This section aims at listing issues that SHOULD be carefully studied
when dealing with configuration tasks. The items below SHOULD be
taken into account when designing a protocol for configuration
purposes.
6.1. Protocol Diversity
The production of a whole set of IP yet complex services relies upon
the activation of a set of capabilities in the participating devices.
Especially, a large set of protocols need to be configured, such as
routing protocols, management protocols, security protocols, not to
mention capabilities that relate to addressing scheme management, QoS
policy enforcement, etc.
Such a diversity of features and protocols MAY increase the risk of
inconsistencies. Therefore, the configuration information which is
forwarded to the whole set of participating devices for producing a
given service or a set of services SHOULD be consistent, whatever the
number of features/services to be activated/deployed in the network.
6.2. Topology Discovery
Network operators SHOULD have means to dynamically discover the
topology of their network. This topology information should be as
elaborate as possible, including details like: the links that connect
network devices, including information about their capacity, such as
the total bandwidth, the available bandwidth, the bandwidth that can
be reserved, etc.
6.3. Device capabilities discovery
As stated above a large number of participating devices are involved
in deploying and offering IP-based services. These devices could vary
depending on the following:
- The manufacturer in charge of designing these devices
- The version of operating system of the devices
- The supported protocols
- Configuration tools
- Others
As a result, it isn't evident to have homogenous capabilities and
means to activate similar functionalities in two participating
devices. Therefore, operators SHOULD have means to (1) detect the
capabilities, (2) have an exhaustive description and (3) list
activated process and functions of a given of participating devices.
This COULD be done automatically or in demand.
Boucadair et al. Informational - Expires January 2005 [Page 6]
Internet Draft Network Configuration requirements July 2004
6.4. Impact on the performance
Configuring network devices and IP services is a human task, and
occurrences of erroneous configurations are therefore plausible. Such
occurrences MAY seriously affect the overall quality of a service,
like the access to a service or its global availability. From this
perspective, some performance indicators SHOULD be defined and
measured to qualify:
- The impact of any modification of an operational configuration,
in terms of performances,
- The time needed to deliver and achieve any elementary
configuration task.
Simulation tools can also be useful to qualify any possible impact of
an elementary configuration task before such task is performed.
6.5. Scalability
As far as scalability is concerned, adequate indicators SHOULD be
specified in order to qualify the ability of a given technical means
to support a large number of configuration processes. The maintenance
of these processes SHOULD not impact the performance of a given
system (a system is a set of elements that compose the key
fundamentals of an architecture that aims at delivering configuration
data).
Therefore, configuration operations SHOULD be qualified with
performance indicators in order to check whether the architecture
designed for configuration management is scalable in terms of:
- Volume of configuration data to be processed per unit of time
and according to the number of capabilities and devices that
need to be configured,
- Volume of information generated by any reporting mechanism that
may be associated to a configuration process,
- Number of processes that are created in order to achieve
specific configuration operations,
6.6. Automation
The efficiency of a configuration process SHOULD be enhanced by the
introduction of the highest level of automation when performing
configuration tasks.
Automation is defined as follows:
Boucadair et al. Informational - Expires January 2005 [Page 7]
Internet Draft Network Configuration requirements July 2004
- Automatic provisioning of configuration information to the
participating devices,
- Dynamic enforcement of configuration policies,
- Dynamic reporting mechanisms to notify about the actual
processing of configuration information by a participating
device.
6.7. Security issues
Configuring a network or a service raises several security issues
that need to be addressed, such as:
- The integrity of the configuration information, possibly
yielding the preservation of the confidentiality of such
information when being conveyed over a public IP
infrastructure,
- The need for authorizing and authenticating devices/entities
that have the ability of manipulating configuration information
(define, instantiate, forward and process).
- Mutual authentication between a decision point and a device
that will receive configuration data
In addition, additional configuration data SHOULD NOT yield
additional security lacks.
7. Towards a Service-Oriented Configuration Policy
Current configuration practice basically focuses on elementary
functions, i.e. configuration management for a given service offering
is decomposed in a set of elementary tasks. Thus, the consistency of
configuration operations for producing IP services MUST be checked by
any means appropriate, while current. Configuration methods can, at
best, only check if provisioning decisions are correctly enforced by
a single device.
A network device SHOULD be seen as a means to deploy a service and
not just as a component of such service. Thus, service configuration
and production techniques SHOULD NOT focus on a set of devices taken
one-by-one, but on the service itself, which will rely upon a set of
features that need to be configured and activated in various regions
of the network that supports such service.
Service providers could dedicate centralized entities that will be
responsible for the provisioning and the management of participating
devices. The main function of these centralized entities is to make
appropriate decisions and generate convenient configuration data that
will be delivered to the participating devices. In addition, these
Boucadair et al. Informational - Expires January 2005 [Page 8]
Internet Draft Network Configuration requirements July 2004
centralized entities will make sure of the consistency of the
decisions that have been taken to produce the service, as per a
dynamic configuration policy enforcement scheme.
Service-oriented configuration SHOULD rely upon the following
requirements:
- The data models MUST be service-oriented;
- The configuration protocol(s) SHOULD at large extent possible
reuse existing data and information models;
- The configuration protocol(s) SHOULD be open for further
enhancement and adding new functionalities that could reveal in
the future as a must;
- The configuration protocol(s) SHOULD provide means to validate
the consistence and the validation of service configuration
8. Requirements
8.1. Protocol Requirements
Configuration information SHOULD be provided to the participating
devices by means of a communication protocol that would be used
between the aforementioned participating devices and a presumably
centralized entity that would aim at storing, maintaining and
updating this configuration information as appropriate, as well as
making adequate decisions at the right time and under various
conditions.
8.1.1. Functional Requirements
The vendor-independent communication protocol for conveying
configuration information SHOULD have the following characteristics:
1. The protocol SHOULD use a reliable transport mode, and independent
from the network layer (i.e. IPv4/IPv6),
2. The protocol architecture SHOULD provide a means for dynamically
provision the configuration information to the participating
devices, so that it may introduce a high level of automation in
the actual negotiation and invocation of a a whole range of IP
service offerings.
3. The protocol SHOULD provide the relevant means (encoding
capabilities, operations and command primitives, extension
capabilities that SHOULD allow additional operations, etc.) to be
able to reliably convey any kind of configuration information,
4. The protocol SHOULD be a privileged vector for the dynamic
provisioning of any kind of configuration data, as well as the
dynamic enforcement of any kind of policy such as a routing
Boucadair et al. Informational - Expires January 2005 [Page 9]
Internet Draft Network Configuration requirements July 2004
policy, a QoS policy and/or a security policy. This requirement
MAY yield the definition and the support of vendor-independent
instantiation procedures that will aim at uniquely identifying the
configuration data model and/or the policy enforcement scheme that
refer to a given IP service offering.
5. The protocol SHOULD support a reporting mechanism that may be used
for statistical information retrieval,
6. The protocol SHOULD support the appropriate security mechanisms to
provide guarantees as far as the preservation of the
confidentiality of the configuration information is concerned.
7. The protocol SHOULD support a notification mechanism that may be
used to initiate configuration-related tasks (i.e. inform that a
link drop down)
8.1.2. Performance requirements
The protocol architecture for conveying configuration information
within a network SHOULD be designed so that:
1. The activation of the protocol by the participating devices SHOULD
not affect the overall switching performances of such devices,
whatever the volume of configuration data these devices will have
to process on a given period of time,
2. The activation of the protocol SHOULD NOT dramatically affect the
global resources of the network infrastructure that will convey
the protocol-specific traffic, whatever the volume of such traffic
and whatever the scope (set of IP service offerings the
configuration data refer to, set of policies to dynamically
enforced, etc.) covered by such traffic.
8.1.3. Backward Compatibility
The introduction and the activation of a protocol for conveying
configuration data SHOULD allow for smooth migration procedures, so
that vendor-specific and vendor-independent configuration procedures
and management MAY gracefully co-exist on a (hopefully) limited
period of time.
Also, in case of any kind of protocol failure, it MUST be possible to
rely upon any vendor-specific configuration procedure to keep on
performing configuration tasks without any risk of disruption that
may affect the availability of a (set of) service offerings, and/or
the access to network resources.
8.2. Information requirements
Boucadair et al. Informational - Expires January 2005 [Page 10]
Internet Draft Network Configuration requirements July 2004
The increase of network service offerings, of the protocol amount to
be implemented by equipment as well as the diversity of vendors made
the configuration tasks being critical. These tasks are commonly
achieved with vendor-specific solutions that deal with device-related
information. Moreover the configuration information may be spread
across different repositories through the network. It then becomes
more and more difficult for the service provider to get a unified
(and obviously confident) view of its network in term on æoffered
servicesÆ rather than a ænetwork device jigsawÆ.
Configuration information SHOULD therefore be provided to the
participating devices as unified service parameters being independent
from the aforementioned devices vendors. These parameters MUST relate
to a standardized service model rather than device-specific as it
used to be. Examples of the so-called service model may be tunneling
service, internal routing service, VPN service. Their definition is
outside the scope of this draft.
Current service providers' concerns focus on the unification of
accesses to heterogeneous devices (those that are part of a multi-
vendor environment) and introduce a high level of automation when
achieving configuration of this infrastructure. This unification
depends on two major issues, the definition of a protocol (the
container) and the definition of data models (the content).
Standardizing these two points bring new opportunities:
- Equipment are seen as functional blocks providing a set of
standardized capabilities;
- These functional blocks are described as vendor-independent
capabilities;
- These functional blocks are all managed homogeneously, whatever
the underlying technology;
As a result, it would be possible to add semantic rules to automate
detection and correction of false configurations, either at the scale
of a single device or at the scale of a whole network. Furthermore,
an equipment from vendor X could de replaced by another device from
vendor Y with no impact on the configuration management.
To do so, the data models SHOULD satisfy the requirements described
below.
8.2.1. Network services
8.2.1.1. Identification of Interfaces
Configuration information that relates to identification deals with
the namespace of the interfaces of a network equipment. This naming
scheme describes the properties of an interface, and must take into
Boucadair et al. Informational - Expires January 2005 [Page 11]
Internet Draft Network Configuration requirements July 2004
account all the parameters that are required to correctly configure
an interface. The following information MUST be provided:
A name, with a generic syntax not related to a specific vendor. The
name can define the media type of the interface;
Depending on the media type, further information MAY be added (link
mode, MTU, speed...);
- Optionally, a logical descriptor. Depending on the media type
it can be relevant to have a logical descriptor (for VLANs
declared on Ethernet interfaces, for instance). In this case
the encapsulation type must be provided;
- Optionally, a description field giving general information
about the interface (i.e. ôOC192 link from LA to SFö)
8.2.1.2. Quality of Service (QoS)
IP services are provided with a level of quality that MAY be
guaranteed (either qualitatively or quantitatively) by any means
appropriate. QoS policies SHOULD be dynamically enforced according to
a data model that will accurately reflect all the elementary QoS
capabilities that MAY be configured and activated to enforce such
policies.
For instance, in the case of the activation of the DiffServ QoS model
within a network infrastructure, the participating routers should be
provided with the appropriate parameters.
8.2.1.3. Security
The protocol architecture MUST provide security functions that
provide source authentication, integrity and confidentiality of
configuration information. The security functions MUST be activated,
whatever the contents of the payload.
In order to protect device accesses, the configuration architecture
MUST provide a filtering / fire-walling access scheme that would
allow to control remote and in-band accesses (i.e. console security
rules, access listsà)
8.2.1.4. Applications
Network devices usually run network functions that allow activation
of specific services, like HTTP, BOOTP, DHCP, SYSLOG ...
Such devices must therefore be provided with the relevant information
related to these services:
- the ability to enable or disable the service;
- the mandatory parameters for each of the service.
Boucadair et al. Informational - Expires January 2005 [Page 12]
Internet Draft Network Configuration requirements July 2004
8.2.2. Forwarding services
8.2.2.1. Routing and Forwarding Configuration Information
Routing and forwarding configuration information deals with the
decision criteria that should be taken by a participating device to
forward an incoming IP datagram, according to a given routing policy.
From this perspective, the participating devices should be provided
with the following information:
- In the case of the activation of dynamic routing protocols for the
computation and the selection of routes that will be considered
for forwarding traffic, the participating routers SHOULD be
provided with the relevant metric information so that the routers
(dynamically) assign the metric values accordingly,
- In the case where the traffic is to be conveyed across domains,
the participating devices should be provided with the relevant
BGP-4 (Border Gateway Protocol, version 4)-based reachability
information, including the BGP-4 attribute-related information
that will be taken into account by the route selection process of
the router to decide where to forward the corresponding traffic,
- Also, the participating routers should be provided with the
configuration information related to any static route that may
identify specific next hops to reach a given destination prefix.
8.2.2.2. Traffic Engineering Configuration Information
Traffic engineering is an important task of configuration management:
within this context, the participating devices should be provided
with the configuration information that will help them to choose the
appropriate routes that lead to a set of destinations, according to
specific constraints.
These constraints may be expressed in terms of time duration (e.g.
the use of a traffic-engineered route on a weekly basis), traffic
characterization (e.g. all the IP multicast traffic should be
conveyed by a specific route), security concerns (e.g. use IPSec [9]
tunnels whenever possible), and/or QoS considerations (e.g. EF
(Expedited Forwarding, [10])-marked traffic should always use a
subset of activated and well-identified routes).
The enforcement of an IP traffic engineering policy would therefore
yield the use of specific routes that will be dynamically computed
and selected according to the aforementioned type of configuration
information.
8.2.2.3. Configuration Information for Tunnel Design and Activation
Boucadair et al. Informational - Expires January 2005 [Page 13]
Internet Draft Network Configuration requirements July 2004
8.2.2.4. Tunnel Identification Information
The identification of a tunnel should be globally unique, especially
if the tunnel is to be established and activated across autonomous
systems. The tunnel identification schemes (e.g. endpoint numbering)
should be left to service providers, given that the corresponding
formalism may be commonly understood, whatever the number of
autonomous systems the tunnel may cross.
The tunnel identification information should at least be composed of
the tunnel endpoint identification information. The tunnel
identification information may also be composed of an informal
description of the tunnel, e.g. the purpose of its establishment, the
customer(s) who may use this tunnel, etc.
There may be cases where this additional information is irrelevant,
e.g. in the case where the tunnel has been designed to convey public
Internet traffic, where a user wishes to access IP multicast-based
services through non-multicast capable clouds.
8.2.2.5. Tunneling Protocol Configuration Information
Any participating device MUST be provided with the configuration
information related to the tunneling technique to be used for the
establishment and the activation of the tunnel. Such techniques
include Generic Routing Encapsulation (GRE, [11]), IP Secure in
tunnel mode (IPSec), Layer 2 Tunneling Protocol (L2TP, [12]), etc.
8.2.3. Management services
8.2.3.1. Fault Management
Fault management is one of the critical points when managing a given
service. Indeed, an operator MAY deploy means to detect fault
occurring in its network and has pre-configured policies that SHOULD
be enforced by participating devices to limit the impact on the
quality of service.
Mechanisms to monitor and report the incidents that occurred to the
service management SHOULD be independent of the configuration
protocol.
8.2.3.2. Configuration Management
Configuration management is responsible for the provisioning of
configuration information to produce a service. Errors during a
configuration procedure could impact the availability of a given
service offering, while consistency checks are mandatory so as to
correctly enforce a configuration policy.
The following requirements have been identified:
Boucadair et al. Informational - Expires January 2005 [Page 14]
Internet Draft Network Configuration requirements July 2004
- Data provisioning SHOULD be as automated as possible
- An operator SHOULD have means to detect and diagnose
configuration errors
- An operator SHOULD deploy means to check the consistency of the
configuration information forwarded to the participating
devices, especially when a whole range of IP services can be
delivered upon subscription requests.
- An operator MAY simulate the impact of the enforcement of a
given configuration policy on its services before delivering
such information to the participating devices.
8.2.3.3. Performance Management
Performance management is mainly deals with the monitoring of the
network and the status of the services.
The performance of a configuration policy/architecture will be
studied in the next version of this draft.
8.2.3.4. Security Management
8.2.3.4.1. Device Authentication
It MUST be possible to activate mutual authentication between a
participating device and a centralized entity that is responsible for
instantiating and forwarding configuration data to these
participating devices. The authentication MUST be checked before
exchanging any configuration data to prevent DoS (Denial of Service)
attacks.
8.2.3.4.2. Integrity of configuration information
Two types of integrity MUST be provided. The first one MAY be done at
the network layer, e.g. by using the IPsec protocol suite. It will
protect each IP datagram, exchanged between a participating device
and the configuration management platform(s), from malicious
modification. The second one SHOULD protect the configuration data at
the application layer (e.g. the entire file configuration is
integrity protected).
8.2.3.4.3. Confidentiality of exchanged data
The participating device SHOULD provide security functions that
provide confidentiality. The encryption algorithms MUST be selectable
manually and/or automatically. The encryption algorithms MUST be the
standard ones.
Boucadair et al. Informational - Expires January 2005 [Page 15]
Internet Draft Network Configuration requirements July 2004
8.2.3.4.4. Key management
The configuration system MUST provide a scalable key management
scheme. The number of keys to be managed must be at most linearly
proportional to the number of the devices.
8.2.3.4.5. Log of connections
The participating device MUST log all configuration connections. At
least the following information must be provided:
- Identity of the device which provided the configuration
information,
- Date of the connection,
- Identity of the user that has launched the configuration process,
- Version of the configuration data has been enforced.
8.2.3.4.6. Profiles
The configuration system MUST allow the definition and the activation
of several privilege levels. Each level could be associated to a set
of administrative functions. And each configuration administrator
could be assigned a specific privileged access level to perform a
(possibly limited) set of configuration tasks.
9. Security Considerations
This draft reflects a set of requirements as far as the design and
the enforcement of configuration policies are concerned for
(automated) service subscription, delivery and exploitation. As such,
the document addresses some security concerns that have been depicted
in section 9.2.3.5, and that SHOULD be taken into account when
considering the specification of a protocol that will convey
configuration information, as well as configuration information
itself.
10. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Boucadair et al. Informational - Expires January 2005 [Page 16]
Internet Draft Network Configuration requirements July 2004
[3] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
and Applicability Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
[4] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[5] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie,K.,
Reichmeyer, F., Seligson, J., Smith, A. and R. Yavatkar, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[6] Distributed Management Task Force, "Common Information Model
(CIM) Specification Version 2.2", DSP 0004, June 1999.
[7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[8] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
Provisioning Information (SPPI)", RFC 3159, August 2001.
[9] Atkinson R., "Security Architecture for the Internet Protocol",
RFC 2401, August 1998.
[10] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec,
J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
[11] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000.
[12] Townsley, W., et al., "Layer Two Tunneling Protocol "L2TP"", RFC
2661, August 1999.
11. Acknowledgments
12. Authors' Addresses
Mohamed Boucadair
France Telecom R & D
42, rue des Coutures
14000 Caen,
France
Phone: 33 2 31 75 92 31
Email: mohamed.boucadair@francetelecom.com
Boucadair et al. Informational - Expires January 2005 [Page 17]
Internet Draft Network Configuration requirements July 2004
Christian Jacquenet
France Telecom Long Distance
3 Avenue Fran‡ois Ch‚teau
35901 Rennes Cedex,
France
Phone: 33 2 99 87 63 31
Email: christian.jacquenet@francetelecom.com
Mohammed Achemlal
France Telecom R & D
42, rue des Coutures
14000 Caen, France
Phone: 33 2 31 75 92 28
Email: mohammed.achemlal@francetelecom.com
Yan Adam
France Telecom R&D LANNION
2 Avenue Pierre Marzin
22307 Lannion Cedex
France
Phone: 33 2 96 05 29 19
Email: yan.adam@francetelecom.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Boucadair et al. Informational - Expires January 2005 [Page 18]
