Individual Submission
Internet Draft E. Lear
Document: draft-lear-config-issues-00.txt Cisco Systems
Expires: March 2003 September 2002
On Transport of Configuration Information
draft-lear-config-issues-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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
How are network elements configured? What are the different ways in
which a device receives configuration, and why do they use those
particular mechanisms? How do these mechanisms perform for their
given use? This document discusses the problem of device
configuration and state exchange. As we do so we will point out some
protocol considerations, such as the objects being transported, how
transfers are initiated, and what the security requirements are.
Table of Contents
1. Introduction...................................................2
2. Our Target Audience and What They Do...........................3
2.1 The Individual Small Office or Home (SOHO).................3
2.2 The Small to Medium Sized Businesses.......................4
2.3 Enterprises................................................4
2.4 Service Providers..........................................5
2.5 Common Needs...............................................5
Lear Expires - March2003 [Page 1]
draft-lear-config-issues-00.txt August 2003
3. How tools work to meet user needs..............................7
3.1 Limitations................................................7
4. Moving to the solution space: schema(s) and protocols..........8
4.1 Schema! Schema! WhoÆs Got The Schema?.....................9
5. Protocol Design Considerations................................10
5.1 Protocol Operations.......................................12
5.2 Protocol Choices: Use an existing one or grow a new one?..13
Security Considerations..........................................14
References.......................................................15
Acknowledgments..................................................17
Author's Addresses...............................................17
Copyright Statement..............................................17
1. Introduction
Many implementations provide their users with ways to send and
retrieve both configuration and state information that is wrapped in
XML.[2] There is no standard for configuration of devices through
XML, and there is no standard transport for this purpose.
This document considers the problem of device configuration and state
exchange and offers suggestions for a standard network protocol.
This work builds on that of others, and the reader is expected to
have read [3], [4] and [5]. There are numerous management tasks that
can be performed on a device, including fault and performance
monitoring and accounting. The task we consider today is the
handling of configured state.
Non-volatile configuration provides all necessary information for a
device to perform its designated function, from the time the power is
turned on. Operational state includes configuration state, as
modified by alterations made during operation and statistics and
information accumulated while in operation. There are two forms of
configuration- volatile and non-volatile.
A configuration operation that enables or disables service for
individuals on a frequent basis is known as provisioning. An example
of provisioning is the set of those configuration operations needed
to create a dial-in account and/or create an electronic mailbox. As
a matter of course, provisioning operations are driven by events,
such as a customer calling up and requesting an account, or the
billing system turning off a customerÆs account due to lack of
payment.
Lear Expires - March 2003 [Page 2]
draft-lear-config-issues-00.txt August 2003
configuration protocol __________
...................................>| |
. |Enterprise|
. _________ _________ | VPN |
| v | | | | | Server B|
| _______ | EDGE | | ISP core| |__________|
|-|_______|<---->| ROUTER |-->| |
__ | home | A | | |
|PC|-| router ^ |_________| | |
|A_| D . |_________| __________
. | |
. | Enhanced |
...................................>| Service |
configuration protocol | Manager C|
|__________|
Figure 1: SOHO / ISP Problem Space
2. Our Target Audience and What They Do
There are different types of individuals who need their devices
considered. Figure 1 illustrates a simple SOHO/ISP diagram.
Operators can largely be grouped in the following way.
2.1 The Individual Small Office or Home (SOHO)
This group usually has a very simple configuration, in our example
owning PC A and having home router D. They largely want a device to
work from the moment it is plugged in. They would prefer the device
operate securely. In some cases, where configuration is required, it
must be straight forward, and it must require as little interaction
with the existing environment. In todayÆs world, configuration web
pages are common for everything from small firewalls to power
distribution systems.
In some cases, a customer may delegate the task of configuration to a
service provider, as the service provider is more likely to be able
to answer questions necessary for a deviceÆs proper configuration.
Indeed, some network devices may enforce a service provider policy,
such as packet policing.[6] Indeed, it may be necessary to delegate
a portion of a configuration to different service providers. A case
in point is when someone wishes to use the same device to connect to
the wide area network, an enterprise VPN, and a media controller of
some form. Thus, the SOHO user has a need for split configuration.
Lear Expires - March 2003 [Page 3]
draft-lear-config-issues-00.txt August 2003
Somehow, the SOHO device must receive configuration from the VPN
manager and the media device, not to mention the service provider,
and potentially the SOHO user. A reasonable approach would be for
the SOHO user to configure the device through a web page or other
craft interface with the IP addresses of the management systems of
the ISP, the VPN server, and the media controller. Another would be
for the device to learn this information through some sort of
auto-configuration system. This can at least be done for the ISP, as
it is with DOCSIS.[7] In all cases with the exception of the
configuration web page, we note that the SOHO device will initiate
the communication with the manager, and NOT the other way around.
2.2 The Small to Medium Sized Businesses
Small to medium businesses (SMBs) will have a few devices that need
configuring. They will largely want to use common tools such as web
browsers or a simple command line or menu driven interface to
configure devices. SMBs perform configuration operations initially
by hand. As they grow they may automate some tasks either by
purchasing or downloading free software or by developing their own
simple tools, probably through the use of a scripting language such
as Perl or TCL.[8,9] In most cases, the tools currently used contact
the network element, and not the other way around (i.e., the exact
opposite of SOHO devices).
2.3 Enterprises
As they grow into larger enterprises SMBs will begin to automate
their provisioning operations, tying them to their hiring procedures
or web based request pages. Enterprises often require that
accounting information be tied to a service offered to an individual
employee within a company. For instance, a departmental account will
be billed for the use of a pager or a dial-up account. Enterprises
have enough money to buy tools off the shelf and customize them as is
appropriate to their environment. They also have business logic that
they may tie to particular services. For instance, a taxi dispatch
service may have a method to dispatch calls that sends notifications
to available taxis of a certain group.
Enterprises may also have enough money to develop tools from scratch
when it is necessary to perform their core business functions. For
instance, a ski lift at a resort might be configured with certain
limitations, such as "only allow premier members through this gate".
Often enterprises may wish to control equipment both in the office
and at the employee home, to enforce a security policy or to maintain
service quality. Indeed enterprises may delegate some or all of this
function to a service provider.
Lear Expires - March 2003 [Page 4]
draft-lear-config-issues-00.txt August 2003
The tools enterprises use typically must navigate the differences
between vendors in order to retrieve and send configuration
information. Those tools typically initiate contact to a device that
has been configured on a craft interface.
2.4 Service Providers
Service providers vary widely from small local community providers to
gigantic national telecommunications concerns. Although they differ
in scale, small and large service providers share in common the goal
to automate provisioning as much as possible in order to minimize
human interaction with the customer. Indeed the provisioning tasks
are also largely similar between the two. Examples include actions
like creating a VPN, provisioning a circuit, or increasing the quota
of a web account. In many cases, a provisioning operation involves
multiple transactions, any one of which could fail, requiring
rollback of the others.
Small service providers will likely not be able to afford fancy
service provisioning tools that have well defined programmatic and
web interfaces. As is the case with SMBs, they are unlikely to have
people dedicated to developing tools, and they will often write tools
in scripting languages such as Perl and TCL. And of course they will
have to debug the tools they write.
In each case, they will want to interpose their business logic for
accounting, billing, fault, and performance management.
Large service providers are similar to enterprises in that they are
likely to have developers available to customize tools that they have
either procured or built. Very large service providers are likely to
have their own proprietary provisioning systems that encompass
inventory control as well as some sort of work flow management.
In addition, large service providers will specialize functions. A
provisioning system may modify provider edge interfaces as well as
control customer edge gear, such as cable or DSL modems; a first
level support person may need be allowed to review configurations;
and a second or third tier support person may have full reign of a
device. In a way not unlike SOHO devices, service provider devices
may require some sort of authorization approach (more on this later).
2.5 Common Needs
In any event, one requirement that seems to cross all borders to be
able to atomically roll forward or backward a configuration action.
In addition, as devices grow in size, service providers and
enterprises require the ability to retrieve only the information they
Lear Expires - March 2003 [Page 5]
draft-lear-config-issues-00.txt August 2003
are interested in, and no more. For instance, one may request
information on a particular network interface, in order to
reconfigure it. Retrieving and processing an entire configuration of
hundreds or thousands of interfaces when one only needs a few lines
is costly, both computationally and in terms of network bandwidth.
Another requirement that crosses all boundaries is the ability to
minimize and automate configuration. The history of configuration of
devices has been that of prearranged access and exchange. A Radius
server is configured so that login and enable access can be
authenticated, or a password file can be copied from a master server,
or a device can be configured within a Kerberos realm.
Starting with the SOHO environment, and moving upwards it is strongly
desirable that devices be able to operate with minimal or no operator
intervention. Thus such devices must be able to automatically
configure themselves. In doing so they may need to be aware of other
devices, such as DNS & DHCP servers, as well as various network
management tools, such as a configuration manager or a fault
management tool. Once theyÆre aware of those devices, because new
functionality will be incrementally added over time, both management
tool and device must be able to discover the otherÆs capabilities.
On the other hand, auto-configuration begs the question of whose
information one can trust. Without knowing who to trust, a device
must either not come into service until it has been told who to
trust, or it must simply record who it decided to trust. That "who"
is in and of itself an interesting question. One reasonable answer
is a valid certificate from a well-known certificate hierarchy of the
management tools it is interacting with. While this wouldnÆt prevent
damage, it would at least document who authorized the damage.
Another answer for "who", in particular for small devices, might
allow for an implied trust based on port. This is the case for small
firewalls.
In addressing all of these concerns, one common desire is that any
standards in this area -- as always -- should be as complex as
necessary, but no more so. In particular, when considering any RPC
mechanisms, this concern must be addressed.
Finally, a basic requirement of nearly all groups of network users is
the ability to review changes within a network configuration. This
is necessary as part of the fault resolution process, to determine
what's changed. Maybe someone fat fingered an access list or
disabled an interface. A concise view of each device configuration,
and in particular recent changes to that configuration, is strongly
desirable.
Lear Expires - March 2003 [Page 6]
draft-lear-config-issues-00.txt August 2003
3. How tools work to meet user needs
There are three configuration models that fall out from our
discussion in Section 2. First, there is the trivial case: a person
connects either to a serial port or via telnet or a web interface
(i.e., HTTP) and directly configures a device.[10] In some cases the
person might use a tool that generates SNMP "gets" and "sets" to
configure a device. This is the mechanism classically used by SOHO
customers for everything from a small network HUB to printers and
wireless devices.
The second model is equally classic: a network manager connects to
the device, having used some sort of discovery process, and
configures it based on a request from either an automated process or
a person. The manager is said to configure the managed element.
Those tools might again use SNMP or they will more likely use some
sort of scripting mechanism to communicate with the device.
Very large deployments require something different. They require the
element to register with an element manager in order to receive its
initial configuration, as well as any changes that may be necessary
over time. Many cable and DSL systems use this method today through
DOCSIS and PPP, respectively.[11] It is important to recognize that
even though the element is the connection initiator in the classic
sense, the element manager may at some point need to initiate an
action on the element. There is no standard protocol to do this,
although dynamic host configuration protocol (DHCP) has been employed
in some cases.[12]
3.1 Limitations
The available toolset for configuration and provisioning operations
includes SNMP and associated MIBs, vendor specific CLI that is
configured through telnet or SSH.[13,14,15] For very simple devices,
the web is also used. From a network standpoint, even where it is
possible to use standard MIBs to monitor fault and performance of a
service, it is often not possible to configure those services in the
same way.
Indeed it is not possible to retrieve a device configuration in a
concise way with SNMP, as it is difficult for an automated tool to
determine what information is persistent, or for that matter even
present, without walking the MIB tree (an expensive operation).
Persistent and volatile information is intermixed throughout the
MIBs. While it might be possible to provide a table of contents
within a MIB to keep track of such information, a better approach
would allow for the reference of the same data in different contexts
to indicate whether one wants to review volatile or non-volatile
information.
Lear Expires - March 2003 [Page 7]
draft-lear-config-issues-00.txt August 2003
Another complaint that is frequently heard about SNMP is the use of
binary encoding rules (BER) to represent information on the wire.
BER is used in SNMP for good reason, in as much as it provides a very
compact data representation. In the case of configuration objects,
however, the need for such compactness is not clear. Indeed such
rules require specialized tools to configure and retrieve
information. One common complaint is that such specialized tools are
not plentiful enough, and do not receive sufficient attention that
they are considered robust or easy to use.
On the other hand, vendor CLI and SSH or telnet offers an equally
daunting set of problems. For one, the CLI between vendors is
necessarily different, as each vendor or implementation expresses
functionality in a way intended to distinguish it from others. In
addition, such CLI tends to be built for humans to read and
understand. Thus, if a programmer makes a spelling error she would
correct it, particularly if the error changes the semantic meaning of
the exchange. Unfortunately, while computers can cope with spelling
errors, they have a very difficult time coping with change.
While this is a well-understood problem in terms of scriptwriters,
what is not so clear to many is just how CLI-based scripts can and
have impeded development. Because changes between elements and
element managers are often not synchronized, the addition of a column
of information in a table, or the restructuring of a command may lead
to misinterpretation or misconfiguration.
For these reasons and others, no standard way to configure devices
has yet to succeed within the Internet. However, it now seems
possible that at least a portion of the problem can be standardized
while we further consider other portions.
4. Moving to the solution space: schema(s) and protocols
Experience has demonstrated a clear approach that allows for
successful incremental development: find a way to modularize the
problem and then work on the modules. Experience also has
demonstrated where those modules are for network management.[16]
With SNMP, for example, there are basically, three: the protocol used
to transport information, the organization of that information (a
schema), and definitions of individual objects within that schema.
Here we propose to use that same model with one change: protocol
operations themselves should largely be a function of the
organization of information.
As has been said and written, XML has conveniently entered into the
fray, providing a (mostly) readable syntax with which one can use a
schema. XML provides a very generic framework around which one can
Lear Expires - March 2003 [Page 8]
draft-lear-config-issues-00.txt August 2003
provide oneÆs schema and data dictionary or name space to easily
expose configuration functionality. This in and of itself does not
provide programmer interface stability between releases of software.
That is what standards organizations and vendor discipline are for.
However, the mere ability to have a more structured way to retrieve
and send configuration information, or to cause certain actions, is
an improvement over what previously existed.
An XML schema provides a natural scoping, around which authorization
mechanisms can be built. Split configuration needs could thus be
addressed.
In addition, because XML is used for everything under the sun,
numerous tool sets are being built for it. These tool sets will be
useful for things OTHER than network management, and that is a key
distinguishing factor over SNMP. Thus, the fad may have snowballed
itself into a useful mechanism.
Indeed a brief survey shows that many leading vendors are supporting
XML on at least some of their products. None of the information
transported is standardized, but it is at the most basic level
wrapped in angle brackets.
4.1 Schema! Schema! WhoÆs Got The Schema?
Whose responsibility is it to derive a schema? At one level, the
IETF has already done a tremendous amount of work on MIBs, and many
vendors have implemented them. Clearly we want to retain this work
as we move forward. Numerous efforts have provided translations
between SMIv2 MIBs and XML Schema Definitions (XSDs).[17]
Rather than start with a battle over schemas, letÆs accept that in
fact multiple schemas exist, provided by both vendors and standards
organizations, much in the same way that enterprises MIBs exist, and
that this is likely to remain the case for a very long time.
While it is perhaps desirable for all devices to use standard data
models and schemas, as a matter of modularity, we leave it to others
to define them. There is at least one additional reason to do so: it
remains unproven that configuration information could be sufficiently
divorced from implementation that complex configuration tasks can in
fact be standardized.
Indeed the native protocol operations themselves could be limited to
the transmission of XML and a response code that may also include
some XML. Operations that have more meaning than that must be
defined within a particular schema, again, in order to preserve
modularity.
Lear Expires - March 2003 [Page 9]
draft-lear-config-issues-00.txt August 2003
For example, there could exist a schema that maps directly to the
managed information base (MIB) tree. The SNMP operations that act
upon that tree are "get", "getnext", "set", etc. On the other hand,
there could exist a schema that looks an awfully lot like a CLI,
whose operations include "configure", "reboot", "debug", "reset
card", etc.
5. Protocol Design Considerations
A protocol addressing this space will carry transactions back and
forth, in one direction or another. Although transactions do not
require a session, experience has taught us that a session is in fact
required to avoid the need to re-authenticate for every transaction.
In addition, many configuration objects can be quite large, and there
is a need for congestion avoidance. Finally, reliable communications
are desirable for most such operations. For these reasons we assume
for the following discussion that a connection-oriented protocol such
as TCP or SCTP is used.
In considering a protocol we will look at the following tasks:
o Connection establishment
o Transport encryption and authentication
o Capabilities exchange
o Protocol operations and transmission of configuration objects
o Responses
o Disconnection
The rest of this section discusses the first three bullets and
disconnection. Protocol operations and transmission of XML objects
and associated responses are discussed in Section 5.1.
The circumstances of a device may determine the direction of
connection establishment. Typically element managers contact the
elements they wish to manage and send configuration. This is
particularly true for SNMP and for tools that "screen scrape" (i.e.,
connect to an element over telnet or ssh and then navigate the user
interface). In some circumstances, however, it is desirable for
devices to connect to an element manager in order to request
configuration data. This is done with COPS-PR[18]. In the former
case, the network manager needs to know about the device before the
device can be managed. In the latter case, the device needs to know
about the network manager before it can be managed. While there are
tradeoffs in scaling properties and complexity with either model, we
assume that both are valid.
Indeed another reason we concern ourselves with connection direction
is that firewalls and NATs may limit so-called "inbound" TCP
Lear Expires - March 2003 [Page 10]
draft-lear-config-issues-00.txt August 2003
connections. Thus, either the element manager or managed element may
initiate a transport connection.
Once a connection is established, it must be possible to secure the
connection and for each end to authenticate itself to the other.
There are several approaches that are commonly used today, including
transport layer security (TLS) and Kerberos.[19,20]. Others may come
along. A flexible approach is desirable to enable both these and
future mechanisms without having to update the protocol
specification. Even within these approaches there are variations.
For instance, it might be desirable for one end to use certificates
and another to use user names. This allows, for example, existing
configuration authentication mechanisms such as Radius[21] to be
used.
Operations may require authentication on either side of a connection.
That authentication might even take a different form on either side
of a connection. For instance, an element may attempt to request its
configuration from an element manager, and thus be required to
authenticate itself. Or, as more typically seen, an element manager
may attempt to deliver some instructions and be required to
authenticate to the element. In either case, because of the nature
of the problem, it is probably safe to assume that if there is to be
any authentication it should occur once, directly after a connection
is established.
Once each side knows who the other is, it should be possible for them
to learn the capabilities of the other, subject to whatever
authorization may be imposed. When we say capabilities, we really
mean some sort of defined schema. This is the point where an element
manager might learn which language it must use to configure a device,
and perhaps which version of that language. It is possible that for
compatibility reasons, a device may understand more than one schema.
It is also possible that schemas may develop for very specific
purposes. Again, while not precluding such scenarios, it is beyond
the scope of this work to specify how many schemas may be employed,
or their use. What will be necessary is a namespace for schemas from
which to choose.
At this point we are ready to exchange XML. Typically, the element
manager will initiate such a transfer, but an element might just as
easily request a particular object. How those objects are identified
or named will vary based on the schema in use [XXX name spaces??
XXX]. It is possible that multiple schemas may be used, and
therefore we must avoid ambiguities. It is possible to design a
protocol such that each message would state which schema is used.
This would be analogous to starting every sentence with "IÆm speaking
English". Identifying the context at the beginning of a
Lear Expires - March 2003 [Page 11]
draft-lear-config-issues-00.txt August 2003
communication is probably good enough for the uses described in
earlier sections.
Connections may be very long-lived, such as in COPS-PR, or they may
exist for brief periods of time. Disconnection may occur for many
reasons, and just as with any protocol, may be planned or unplanned.
The protocol should allow for either side to initiate a connection
close.
5.1 Protocol Operations
As we previously discussed, requests may be initiated in either
direction. We must now discuss the structure of a request. For
illustrative purposes alone we consider a few lines of XML that
demonstrates a small handful of functions:
<configure>
<interface-section>
<interface name="eth1">
<ip-address v4="10.1.1.1" v4mask="255.255.255.0" />
</interface>
</interface-section>
<routing-section>
à
</routing-section>
</configure>
In this illustrative example, an interface is configured with an ipv4
address and mask. <configure> can be viewed as either transaction
content or a protocol operation. In this case we could conceivably
take the angle brackets away, were we to agree to all the mechanisms
to manipulate configuration. Because we canÆt, we may place a thin
wrapper around <configure>, and allow the element to be defined
within individual schema. Note that the problem gets more difficult
the further inward one goes. For instance, not every device may
route, and therefore have a <routing-section>. A key goal for the
protocol is to provide sufficient maximum utility while remaining
stable.
Thus, the actual protocol operations need to be fairly basic,
allowing for the semantic requests to be placed in some structured
way (in this case XML) and responses to be sent in a similar manner.
Still there are several common operations that we would like to
perform on the device, associated with the above configuration. One
would be to commit it, and another would be to roll it back. There
are probably others. It is likely that such operations are within
the bounds of standardization.
Lear Expires - March 2003 [Page 12]
draft-lear-config-issues-00.txt August 2003
5.2 Protocol Choices: Use an existing one or grow a new one?
Because XML itself is just a text-based syntax, there are numerous
ways to transport it such that it gets to a destination intact, and a
response returns reasonably intact. One could even use Email or
Netnews (donÆt laugh, moving control information through such
mechanisms is nothing new).[22] However, realistically speaking
since we are talking about network control, we require an interactive
protocol that provides responses in real time, as opposed to a store-
and-forward mechanism.
The protocols people use today to transport XML and other
configuration data are SSH, HTTP, SSL, and Blocks Extensible Exchange
Protocol (BEEP).[23] Each protocol has advantages and disadvantages.
To start with, SSH is perhaps the most widely deployed protocol that
provides some amount of ad-hoc security. Indeed, with the IETF just
having standardized it, it has the advantage of having gone through
some security review, and it requires very little infrastructure to
use. Keys are exchanged out of band, and they may be aggregated
through whatever mechanism an administrator wishes to use. Of
course, this same advantage is also a disadvantage, because there is
no standard way for a device to determine whether or not to trust
another device. Once an authenticated connection is established,
however, there is no way to determine supported schemas, and there is
no clear way to know when a response should even be expected, never
mind whether the actual XML has been acted upon. Were we to use SSH,
we would have to add a layer between the transport and the XML to
accomplish this.
HTTP and SSL are two peas in a pod. SSL provides a layer of security
for HTTP that sits on top of it. Of all the mechanisms used to move
XML today, HTTP is clearly the protocol of choice, through the use of
GETs and POSTs.[24] HTTP has the enormous benefit of a large amount
of available tools to scale its delivery. Still, architecturally,
the server and the client look very different. An HTTP client
submits requests and a server submits responses. This clearly does
not naturally fit a model where requests could come from either side.
A rebuttal to this limitation is that the protocol could be so
general as to encompass every conceivable requirement, and therefore
be impossible to implement. Clearly a balanced approach is required.
SSL is useful in a way similar to SSH, in that it provides for an
authentication model. SSL uses a hierarchical certificate approach
that is widely deployed. However, what happens in environments where
either a certificate authority is temporarily unavailable, or where
there is never access to the certificate hierarchy? Also, generating
and enrolling certificates in new devices is a hard problem. An
easier approach is to verify through a certificate one side of a
connection, and then using a shared secret for the other side, a
Lear Expires - March 2003 [Page 13]
draft-lear-config-issues-00.txt August 2003
common approach used on the web. SSL supports such an approach, as
does TLS.
BEEP is a new addition to the IETF protocol suite, and is not today
heavily used to move device configuration information. Although it
suffers from limited implementation, it was designed with the notion
that XML or another blocks of data. BEEP was designed not so much
with one specific application involved, but as a framework
applications could use to exchange data with one another, in a secure
way, if so desired. BEEP also matches the model that we discussed
above in two other respects: first, while providing framing, it
provides very little in the way of application protocol operations.
Second, it allows either side to initiate a transaction.
However, BEEP is not perfectly simple. While the protocol provides
for security and framing, it also requires the use of control and
data channels within a single stream, thus increasing implementation
complexity, where it is not yet clear that the use of a channelized
stream is warranted.[25,26] Here again, we see a tradeoff between
generalization and specific optimization.
There are numerous other protocols that could be considered. The
actual choice must be made in the context of customer requirements.
Security Considerations
Configuration of devices is by its nature a sensitive activity.
Whatever mechanisms advance must be able to allow for a flexible
authentication model, as well as encryption. Each device must be
able to authenticate itself.
Bootstrapping is a particularly tricky case in such an environment,
as it may not be possible for a newly purchased device to
authenticate itself to anyone. Therefore, an initial enrollment step
with some sort of out of band data may be necessary.
Splitting of responsibilities for a configuration requires particular
attention. A known ages-old operator requirement is that a
configuration be viewed discretely, as one file. This is necessary
for debugging purposes, among many other reasons. In addition, some
responsibilities may not be easily partitioned. Various studies of
policy demonstrate the need to understand and avoid such
conflicts.[27]
In the context of authorization, it must be possible to audit
configuration changes, and that audit capability needs to scale
nicely. One concern about SNMP is that provisioning would be
implemented through a number of sets. In order to reduce load there
Lear Expires - March 2003 [Page 14]
draft-lear-config-issues-00.txt August 2003
must be a way to aggregate those sets into a concise configuration
operation that can be traced back to the entity that initiated it.
If something more concise is used in the first place, the aggregation
may be less necessary. A better understanding is needed in this
area.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Marsh, J. Ed., XML Base, W3C Recommendation, June 2001.
3 Woodcock, B., ôOperator Requirements of Infrastructure Management
Methodsö, draft-ops-operator-req-mgmt-02.txt, Work In Progress.
4 Wasserman, M., ôConcepts and Requirements for XML Network
Configurationö, draft-wasserman-xmlconf-req-00.txt, Work in
Progress.
5 Bierman, A., ôNetwork Management Observationsö, draft-bierman-nm-
observations-00.txt, Work In Progress.
6 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and Weiss,
W., ôAn Architecture for Differentiated Servicesö, RFC 2475,
December 1998.
7 Cable Television Laboratories, "Data of Cable Service Interface
Specification: Operations Support System Interface Specification",
SP-OSSIv2.0-I02-020617, June 2002.
8 Wall, L., Christianson, T., Orwant, J., ôProgramming Perl 3rd
Editionö, OÆReilly & Associates, July 2000.
9 Ousterhout, J., ôTcl: An Embeddable Command Languageö, USENIX
Conference Proceedings, ppg. 133-146, January 1990.
10 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., Berners-Lee, T., ôHypertext Transfer Protocol û
HTTP/1.1ö, RFC 2616, June 1999.
11 Simpson, W., ed., "The Point to Point Protocol", RFC 1661, July,
1994.
12 Droms, R., ôDynamic Host Configuration Protocolö, RFC 2131, March
1997.
Lear Expires - March 2003 [Page 15]
draft-lear-config-issues-00.txt August 2003
13 Harrington, D., Wijnen, B., ôAn Architecture for Describing SNMP
Management Frameworksö, RFC 2571, May 1999.
14 McKenzie, A.M., ôTelnet Protocol Specificationsö, RFC 495, May
1973.
15 Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., Lethinen, S.,
ôSSH Transport Layer Protocolö, Work in Progress, draft-ietf-
secsh-transport-14.txt, March 2002.
16 Wasserman, M., ôConcepts and Requirements for XML Network
Configurationö, draft-wasserman-xmlconf-req-00.txt, Work in
progress.
17 Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., ed., ôXML
Schema Part 1: Structuresö, W3C Recommendation, May 2001.
18 Chan, K., et al., ôCOPS Usage for Provisioning (COPS-PR)ö, RFC
3084, March 2001.
19 Dierks, T., Allen, C., ôThe TLS Protocol Version 1.0ö, RFC 2246,
January 1999.
20 Kohl, J., Neuman, C., ôThe Kerberos Network Authentication Service
(V5)ö, RFC 1510, September 1993.
21 Rigney, C., Willens, S., Rubens, A, Simpson, W., ôRemote
Authentication Dial In User Service (RADIUS)ö, RFC 2865, June
2000.
22 Smith, R., Gottesman, S., Hobbs, B., Lear, E., Kristofferson, D.,
Benton, D., Smith, P., ôA mechanism for maintaining up-to-date
GenBank database via Usenetö, Computational Applied Biosciences,
ppg. 111-112, January 1991.
23 Rose, M., ôThe Blocks Extensible Exchange Protocol Coreö, RFC
3080, March 2001.
24 Moore, K., ôOn the use of HTTP as a substrateö, RFC 3205, February
2002.
25 Postel, J., ed., ôTransmission Control Protocolö, RFC 793,
September 1981.
26 Stewart, R., Xie, Q., Morneault, K., Charp, C., Schwarzbauer, H.,
Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V., ôStream
Control Transmission Protocolö, RFC 2960, October 2000.
Lear Expires - March 2003 [Page 16]
draft-lear-config-issues-00.txt August 2003
27 Moore, B., Elleson, E., Strassner, J., Westerinan, A., "Policy
Core Information Model-- Version 1 Specification", RFC 3060,
February, 2001.
Acknowledgments
This document is based on the work of Andy Bierman, Fred Baker, Bill
Woodcock, and Margaret Wassmerman. Substantial input came from
Marshall Rose and Dave Crocker, as well as numerous operators.
Author's Addresses
Eliot Lear
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
Email: lear@cisco.com
Copyright Statement
Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Lear Expires - March 2003 [Page 17]
draft-lear-config-issues-00.txt August 2003
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.
Lear Expires - March 2003 [Page 18]