draft-ietf-isms-tmsm-05.txt   draft-ietf-isms-tmsm-06.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track J. Schoenwaelder Updates: 3411,3412,3414,3417 J. Schoenwaelder
Expires: June 16, 2007 International University Bremen (if approved) International University Bremen
December 13, 2006 Intended status: Standards Track February 5, 2007
Expires: August 9, 2007
Transport Subsystem for the Simple Network Management Protocol (SNMP) Transport Subsystem for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-tmsm-05 draft-ietf-isms-tmsm-06
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2007. This Internet-Draft will expire on August 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in RFC 3411. Network Management Protocol (SNMP) architecture defined in RFC 3411.
This document describes a subsystem to contain transport models, This document defines a subsystem to contain Transport Models,
comparable to other subsystems in the RFC3411 architecture. As work comparable to other subsystems in the RFC3411 architecture. As work
is being done to expand the transport to include secure transport is being done to expand the transport to include secure transport
such as SSH and TLS, using a subsystem will enable consistent design such as SSH and TLS, using a subsystem will enable consistent design
and modularity of such transport models. This document identifies and modularity of such Transport Models. This document identifies
and discusses some key aspects that need to be considered for any and describes some key aspects that need to be considered for any
transport model for SNMP. Transport Model for SNMP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The Internet-Standard Management Framework . . . . . . . . 3 1.1. The Internet-Standard Management Framework . . . . . . . . 4
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Where this Extension Fits . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements of a Transport Model . . . . . . . . . . . . . . 6 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Message Security Requirements . . . . . . . . . . . . . . 6 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8
3.1.1. Security Protocol Requirements . . . . . . . . . . . . 6 3.1. Message Security Requirements . . . . . . . . . . . . . . 8
3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8
3.2.1. Architectural Modularity Requirements . . . . . . . . 7 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Access Control Requirements . . . . . . . . . . . . . 11 3.2.1. Architectural Modularity Requirements . . . . . . . . 9
3.2.3. Security Parameter Passing Requirements . . . . . . . 12 3.2.2. Access Control Requirements . . . . . . . . . . . . . 13
3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14 3.2.3. Security Parameter Passing Requirements . . . . . . . 14
3.3.1. Session Establishment Requirements . . . . . . . . . . 14 3.2.4. Separation of Authentication and Authorization . . . . 15
3.3.2. Session Maintenance Requirements . . . . . . . . . . . 16 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 16
3.3.3. Message security versus session security . . . . . . . 16 3.3.1. Session Establishment Requirements . . . . . . . . . . 17
4. Scenario Diagrams for the Transport Subsystem . . . . . . . . 17 3.3.2. Session Maintenance Requirements . . . . . . . . . . . 18
4.1. Command Generator or Notification Originator . . . . . . . 17 3.3.3. Message security versus session security . . . . . . . 18
4.2. Command Responder . . . . . . . . . . . . . . . . . . . . 18 4. Scenario Diagrams for the Transport Subsystem . . . . . . . . 19
5. Cached Information and References . . . . . . . . . . . . . . 19 4.1. Command Generator or Notification Originator . . . . . . . 19
5.1. securityStateReference . . . . . . . . . . . . . . . . . . 20 4.2. Command Responder . . . . . . . . . . . . . . . . . . . . 21
5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 21 5. Cached Information and References . . . . . . . . . . . . . . 22
6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 23
6.1. Generating an Outgoing SNMP Message . . . . . . . . . . . 22 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 24
6.2. Processing for an Outgoing Message . . . . . . . . . . . . 23 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 24
6.3. Processing an Incoming SNMP Message . . . . . . . . . . . 23 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 24
6.3.1. Processing an Incoming Message . . . . . . . . . . . . 23 6.2. Other Outgoing ASIs . . . . . . . . . . . . . . . . . . . 25
6.3.2. Prepare Data Elements from Incoming Messages . . . . . 23 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 26
6.3.3. Processing an Incoming Message . . . . . . . . . . . . 24 6.4. Other Incoming ASIs . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 28 Appendix A. Parameter Table . . . . . . . . . . . . . . . . . . . 31
A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 28 A.1. ParameterList.csv . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 29 Appendix B. Why tmStateReference? . . . . . . . . . . . . . . . . 33
B.1. Define an Abstract Service Interface . . . . . . . . . . . 29 B.1. Define an Abstract Service Interface . . . . . . . . . . . 33
B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 30 B.2. Using an Encapsulating Header . . . . . . . . . . . . . . 33
B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 30 B.3. Modifying Existing Fields in an SNMP Message . . . . . . . 34
B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 30 B.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 34
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 34
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 31 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document describes a Transport Subsystem, extending the Simple This document defines a Transport Subsystem, extending the Simple
Network Management Protocol (SNMP) architecture defined in [RFC3411]. Network Management Protocol (SNMP) architecture defined in [RFC3411].
This document identifies and discusses some key aspects that need to This document identifies and describes some key aspects that need to
be considered for any transport model for SNMP. be considered for any Transport Model for SNMP.
1.1. The Internet-Standard Management Framework 1.1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. RFC 3410 [RFC3410].
1.2. Conventions 1.2. Where this Extension Fits
It is expected that readers of this document will have read RFC3410
and RFC3411, and have a general understanding of the functionality
defined in RFCs 3412-3418.
The "Transport Subsystem" is an additional component for the SNMP
Engine depicted in RFC3411, section 3.1.
The following diagram depicts its place in the RFC3411 architecture.:
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ | |
| | | Transport | | |
| | | Subsystem | | |
| | +------------+ | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
The transport mappings defined in RFC3417 do not provide lower-layer
security functionality, and thus do not provide transport-specific
security parameters. This document updates RFC3411 and RFC3417 by
defining an architectural extension and ASIs that transport mappings
(models) can use to pass transport-specific security parameters to
other subsystems, including transport-specific security parameters
translated into the transport-independent securityName and
securityLevel.
1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The key words "must", "must not", "required", "shall", "shall not",
"should", "should not", "recommended", "may", and "optional" in this
document are not to be interpreted as described in RFC2119. They
will usually, but not always, be used in a context relating to
compatibility with the RFC3411 architecture or the subsystem defined
here, but which might have no impact on on-the-wire compatibility.
These terms are used as guidance for designers of proposed IETF
models to make the designs compatible with RFC3411 subsystems and
Abstract Service Interfaces (see section 3.2). Implementers are free
to implement differently. Some usages of these lowercase terms are
simply normal English usage.
2. Motivation 2. Motivation
There are multiple ways to secure one's home or business, in a Just as there are multiple ways to secure one's home or business, in
continuum of alternatives. Let's consider three general approaches. a continuum of alternatives, there are multiple ways to secure a
In the first approach, an individual could buy a gun, learn to use network management protocol. Let's consider three general
it, and sit on your front porch waiting for intruders. In the second approaches.
approach, one could hire an employee with a gun, schedule the
employee, position the employee to guard what you want protected, In the first approach, an individual could sit on his front porch
hire a second guard to cover if the first gets sick, and so on. In waiting for intruders. In the second approach, he could hire an
the third approach, you could hire a security company, tell them what employee , schedule the employee, position the employee to guard what
you want protected, and they could hire employees, train them, buy he wants protected, hire a second guard to cover if the first gets
the guns, position the guards, schedule the guards, send a sick, and so on. In the third approach, he could hire a security
replacement when a guard cannot make it, etc., thus providing the company, tell them what he wants protected, and they could hire
security you want, with no significant effort on your part other than employees, train them, position the guards, schedule the guards, send
a replacement when a guard cannot make it, etc., thus providing the
desired security, with no significant effort on his part other than
identifying requirements and verifying the quality of the service identifying requirements and verifying the quality of the service
being provided. being provided.
The User-based Security Model (USM) as defined in [RFC3414] largely The User-based Security Model (USM) as defined in [RFC3414] largely
uses the first approach - it provides its own security. It utilizes uses the first approach - it provides its own security. It utilizes
existing mechanisms (SHA=the gun), but provides all the coordination. existing mechanisms (e.g., SHA), but provides all the coordination.
USM provides for the authentication of a principal, message USM provides for the authentication of a principal, message
encryption, data integrity checking, timeliness checking, etc. encryption, data integrity checking, timeliness checking, etc.
USM was designed to be independent of other existing security USM was designed to be independent of other existing security
infrastructures. USM therefore requires a separate principal and key infrastructures. USM therefore requires a separate principal and key
management infrastructure. Operators have reported that deploying management infrastructure. Operators have reported that deploying
another principal and key management infrastructure in order to use another principal and key management infrastructure in order to use
SNMPv3 is a deterrent to deploying SNMPv3. It is possible but SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use
difficult to define external mechanisms that handle the distribution external mechanisms to handle the distribution of keys for use by
of keys for use by the USM approach. USM. The more important issue is that operators wanted to leverage a
single user base that wasn't specific to SNMP.
A solution based on the second approach might use a USM-compliant A solution based on the second approach might use a USM-compliant
architecture, but combine the authentication mechanism with an architecture, but combine the authentication mechanism with an
external mechanism, such as RADIUS [RFC2865], to provide the external mechanism, such as RADIUS [RFC2865], to provide the
authentication service. It might be possible to utilize an external authentication service. It might be possible to utilize an external
protocol to encrypt a message, to check timeliness, to check data protocol to encrypt a message, to check timeliness, to check data
integrity, etc. It is difficult to cobble together a number of integrity, etc. It is difficult to cobble together a number of
subcontracted services and coordinate them however, because it is subcontracted services and coordinate them however, because it is
difficult to build solid security bindings between the various difficult to build solid security bindings between the various
services, and potential for gaps in the security is significant. services, and potential for gaps in the security is significant.
skipping to change at page 4, line 30 skipping to change at page 7, line 32
checking. There are a number of IETF standards available or in checking. There are a number of IETF standards available or in
development to address these problems through security layers at the development to address these problems through security layers at the
transport layer or application layer, among them TLS [RFC4366], SASL transport layer or application layer, among them TLS [RFC4366], SASL
[RFC4422], and SSH [RFC4251]. [RFC4422], and SSH [RFC4251].
From an operational perspective, it is highly desirable to use From an operational perspective, it is highly desirable to use
security mechanisms that can unify the administrative security security mechanisms that can unify the administrative security
management for SNMPv3, command line interfaces (CLIs) and other management for SNMPv3, command line interfaces (CLIs) and other
management interfaces. The use of security services provided by management interfaces. The use of security services provided by
lower layers is the approach commonly used for the CLI, and is also lower layers is the approach commonly used for the CLI, and is also
the approach being proposed for NETCONF [I-D.ietf-netconf-ssh]. the approach being proposed for NETCONF [RFC4741].
This document describes a Transport Subsystem extension to the
RFC3411 architecture.
+-------------------------------------------------------------------+ This document defines a Transport Subsystem extension to the RFC3411
| SNMP entity | architecture based on the third approach. This extension specifies
| | how other lower layer protocols with common security infrastructures
| +-------------------------------------------------------------+ | can be used underneath the SNMP protocol and the desired goal of
| | SNMP engine (identified by snmpEngineID) | | unified administrative security can be met.
| | | |
| | +------------+ | |
| | | Transport | | |
| | | Subsystem | | |
| | +------------+ | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
This extension allows security to be provided by an external protocol This extension allows security to be provided by an external protocol
connected to the SNMP engine through an SNMP transport-model connected to the SNMP engine through an SNMP Transport Model
[RFC3417]. Such a transport model would then enable the use of [RFC3417]. Such a Transport Model would then enable the use of
existing security mechanisms such as (TLS) [RFC4366] or SSH [RFC4251] existing security mechanisms such as (TLS) [RFC4366] or SSH [RFC4251]
within the RFC3411 architecture. within the RFC3411 architecture.
There are a number of Internet security protocols and mechanisms that There are a number of Internet security protocols and mechanisms that
are in wide spread use. Many of them try to provide a generic are in wide spread use. Many of them try to provide a generic
infrastructure to be used by many different application layer infrastructure to be used by many different application layer
protocols. The motivation behind the transport subsystem is to protocols. The motivation behind the Transport Subsystem is to
leverage these protocols where it seems useful. leverage these protocols where it seems useful.
There are a number of challenges to be addressed to map the security There are a number of challenges to be addressed to map the security
provided by a secure transport into the SNMP architecture so that provided by a secure transport into the SNMP architecture so that
SNMP continues to work without any surprises. These challenges are SNMP continues to provide interoperability with existing
discussed in detail in this document. For some key issues, design implementations. These challenges are described in detail in this
choices are discussed that may be made to provide a workable solution document. For some key issues, design choices are described that
that meets operational requirements and fits into the SNMP might be made to provide a workable solution that meets operational
architecture defined in [RFC3411]. requirements and fits into the SNMP architecture defined in
[RFC3411].
3. Requirements of a Transport Model 3. Requirements of a Transport Model
3.1. Message Security Requirements 3.1. Message Security Requirements
Transport security protocols SHOULD ideally provide the protection Transport security protocols SHOULD provide protection against the
against the following message-oriented threats [RFC3411]: following message-oriented threats [RFC3411]:
1. modification of information 1. modification of information
2. masquerade 2. masquerade
3. message stream modification 3. message stream modification
4. disclosure 4. disclosure
According to [RFC3411], it is not required to protect against denial These threats are described in section 1.4 of [RFC3411]. It is not
of service or traffic analysis. required to protect against denial of service or traffic analysis,
but it should not make those threats significantly worse.
3.1.1. Security Protocol Requirements 3.1.1. Security Protocol Requirements
There are a number of standard protocols that could be proposed as There are a number of standard protocols that could be proposed as
possible solutions within the transport subsystem. Some factors possible solutions within the Transport Subsystem. Some factors
should be considered when selecting a protocol. SHOULD be considered when selecting a protocol.
Using a protocol in a manner for which it was not designed has Using a protocol in a manner for which it was not designed has
numerous problems. The advertised security characteristics of a numerous problems. The advertised security characteristics of a
protocol may depend on its being used as designed; when used in other protocol might depend on it being used as designed; when used in
ways, it may not deliver the expected security characteristics. It other ways, it might not deliver the expected security
is recommended that any proposed model include a discussion of the characteristics. It is recommended that any proposed model include a
applicability of the transport model. description of the applicability of the Transport Model.
A transport model should require no modifications to the underlying A Transport Model SHOULD require no modifications to the underlying
protocol. Modifying the protocol may change its security protocol. Modifying the protocol might change its security
characteristics in ways that would impact other existing usages. If characteristics in ways that would impact other existing usages. If
a change is necessary, the change should be an extension that has no a change is necessary, the change SHOULD be an extension that has no
impact on the existing usages. It is recommended that any transport impact on the existing usages. Any Transport Model SHOULD include a
model include a discussion of potential impact on other usages of the description of potential impact on other usages of the protocol.
protocol.
It has been a long-standing requirement that SNMP be able to work
when the network is unstable, to enable network troubleshooting and
repair. The UDP approach has been considered to meet that need well,
with an assumption that getting small messages through, even if out
of order, is better than getting no messages through. There has been
a long debate about whether UDP actually offers better support than
TCP when the underlying IP or lower layers are unstable. There has
been recent discussion of whether operators actually use SNMP to
troubleshoot and repair unstable networks.
There has been discussion of ways SNMP could be extended to better
support management/monitoring needs when a network is running just
fine. Use of a TCP transport, for example, could enable larger
message sizes and more efficient table retrievals.
Transport models MUST be able to coexist with other transport models, Transport Models MUST be able to coexist with each other.
and may be designed to utilize either TCP or UDP or SCTP.
3.2. SNMP Requirements 3.2. SNMP Requirements
3.2.1. Architectural Modularity Requirements 3.2.1. Architectural Modularity Requirements
SNMP version 3 (SNMPv3) is based on a modular architecture (described SNMP version 3 (SNMPv3) is based on a modular architecture (defined
in [RFC3411] section 3) to allow the evolution of the SNMP protocol in [RFC3411] section 3) to allow the evolution of the SNMP protocol
standards over time, and to minimize side effects between subsystems standards over time, and to minimize side effects between subsystems
when changes are made. when changes are made.
The RFC3411 architecture includes a security subsystem for enabling The RFC3411 architecture includes a Security Subsystem for enabling
different methods of providing security services, a messaging different methods of providing security services, a Message
subsystem permitting different message versions to be handled by a Processing Subsystem permitting different message versions to be
single engine, an application subsystem to support different types of handled by a single engine, Applications(s) to support different
application processors, and an access control subsystem for allowing types of application processors, and an Access Control Subsystem for
multiple approaches to access control. The RFC3411 architecture does allowing multiple approaches to access control. The RFC3411
not include a subsystem for transport models, despite the fact there architecture does not include a subsystem for Transport Models,
are multiple transport mappings already defined for SNMP. This despite the fact there are multiple transport mappings already
document addresses the need for a transport subsystem compatible with defined for SNMP. This document addresses the need for a Transport
the RFC3411 architecture. Subsystem compatible with the RFC3411 architecture. As work is being
done to expand the transport to include secure transport such as SSH
In SNMPv2, there were many problems of side effects between and TLS, using a subsystem will enable consistent design and
subsystems caused by the manipulation of MIB objects, especially modularity of such Transport Models.
those related to authentication and authorization, because many of
the parameters were stored in shared MIB objects, and different
models and protocols could assign different values to the objects.
Contributors assumed slightly different shades of meaning depending
on the models and protocols being used. As the shared MIB module
design was modified to accommodate a specific model, other models
which used the same MIB objects would be broken.
Abstract Service Interfaces (ASIs) were developed to pass model-
independent parameters. The models were required to translate from
their model-dependent formats into a model-independent format,
defined using model-independent semantics, which would not impact
other models.
Parameters have been provided in the ASIs to pass model-independent
information about the authentication that has been provided. These
parameters include a model-independent identifier of the security
"principal", the security model used to perform the authentication,
and which SNMP-specific security features were applied to the message
(authentication and/or privacy).
Parameters have been provided in the ASIs to pass model-independent The design of this Transport Subsystem accepts the goals of the
transport address information. These parameters utilize the RFC3411 architecture defined in section 1.5 of [RFC3411]. This
transportDomain and transportAddress Transport Subsystem uses a modular design that will permit Transport
Models to be advanced through the standards process independently of
other Transport Models, and independent of other modular SNMP
components as much as possible.
The design of a transport subsystem must abide the goals of the Parameters have been added to the ASIs to pass model-independent
RFC3411 architecture defined in [RFC3411]. To that end, this transport address information.
transport subsystem proposal uses a modular design that will permit
transport models to be advanced through the standards process
independently of other transport models, and independent of other
modular SNMP components as much as possible.
IETF standards typically require one mandatory to implement solution, IETF standards typically require one mandatory to implement solution,
with the capability of adding new mechanisms in the future. Part of with the capability of adding new mechanisms in the future. Part of
the motivstion of developing transport models is to develop support the motivation of developing Transport Models is to develop support
for secure transport protocols, such as a transport model that for secure transport protocols, such as a Transport Model that
utilizes the Secure Shell protocol. Any transport model should utilizes the Secure Shell protocol. Any Transport Model SHOULD
define one minimum-compliance security mechanism, preferably one define one minimum-compliance security mechanism, such as
which is already widely used to secure the transport layer protocol. certificates, to ensure a basic level of interoperability, but should
also be able to support additional existing and new mechanisms.
The Transport Subsystem permits multiple transport protocols to be The Transport Subsystem permits multiple transport protocols to be
"plugged into" the RFC3411 architecture, supported by corresponding "plugged into" the RFC3411 architecture, supported by corresponding
transport models, including models that are security-aware. Transport Models, including models that are security-aware.
The RFC3411 architecture,and the USM assume that a security model is The RFC3411 architecture and the Security Subsystem assume that a
called by a message-processing model and will perform multiple Security Model is called by a Message Processing Model and will
security functions within the security subsystem. A transport model perform multiple security functions within the Security Subsystem. A
that supports a secure transport protocol may perform similar Transport Model that supports a secure transport protocol might
security functions within the transport subsystem. A transport model perform similar security functions within the Transport Subsystem. A
may perform the translation of transport security parameters to/from Transport Model might perform the translation of transport security
security-model-independent parameters. To accommodate this, the ASIs parameters to/from security-model-independent parameters.
for the transport subsystem, the messaging subsystem, and the
security subsystem will be extended to pass security-model- To accommodate this, an implementation-specific cache of transport-
independent values, and a cache of transport-specific information. specific information will be described (not shown), and the data
flows between the Transport Subsystem and the Transport Dispatch,
between the Message Dispatch and the Message Processing Subsystem,
and between the Message Processing Subsystem and the Security
Subsystem will be extended to pass security-model-independent values.
New Security Models may also be defined that understand how to work
with the modified ASIs and the cache. One such Security Mode, the
Transport Security Model, is defined in
The following diagram depicts the SNMPv3 architecture including the
new Transport Subsystem defined in this document, and a new Transport
Security Model defined in [I-D.ietf-isms-transport-security-model].
+------------------------------+ +------------------------------+
| Network | | Network |
+------------------------------+ +------------------------------+
^ ^ ^ ^ ^ ^
| | | | | |
v v v (traditional SNMP agent) v v v
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| | Transport Subsystem | | | | Transport Subsystem | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| | | UDP | | TCP | | SSH | | TLS | . . . | other | | | | | | UDP | | TCP | | SSH | | TLS | . . . | other | | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| +--------------------------------------------------+ | | +--------------------------------------------------+ |
| ^ | | ^ |
| | | | | |
| Dispatcher v | | Dispatcher v |
| +-------------------+ +---------------------+ +----------------+ | | +-------------------+ +---------------------+ +----------------+ |
| | Transport | | Message Processing | | Security | | | | Transport | | Message Processing | | Security | |
| | Dispatch | | Subsystem | | Subsystem | | | | Dispatch | | Subsystem | | Subsystem | |
| | | | +------------+ | | +------------+ | | | | | | +------------+ | | +------------+ | |
| | | | +->| v1MP * |<--->| | USM * | | | | | | | +->| v1MP |<--->| | USM | | |
| | | | | +------------+ | | +------------+ | | | | | | | +------------+ | | +------------+ | |
| | | | | +------------+ | | +------------+ | | | | | | | +------------+ | | +------------+ | |
| | | | +->| v2cMP * |<--->| | Transport* | | | | | | | +->| v2cMP |<--->| | Transport | | |
| | Message | | | +------------+ | | | Security | | | | | Message | | | +------------+ | | | Security | | |
| | Dispatch <--------->| +------------+ | | | Model | | | | | Dispatch <--------->| +------------+ | | | Model | | |
| | | | +->| v3MP * |<--->| +------------+ | | | | | | +->| v3MP |<--->| +------------+ | |
| | | | | +------------+ | | +------------+ | | | | | | | +------------+ | | +------------+ | |
| | PDU Dispatch | | | +------------+ | | | Other * | | | | | PDU Dispatch | | | +------------+ | | | Other | | |
| +-------------------+ | +->| otherMP * |<--->| | Model(s) | | | | +-------------------+ | +->| otherMP |<--->| | Model(s) | | |
| ^ | +------------+ | | +------------+ | | | ^ | +------------+ | | +------------+ | |
| | +---------------------+ +----------------+ | | | +---------------------+ +----------------+ |
| v | | v |
| +-------+-------------------------+---------------+ | | +-------+-------------------------+---------------+ |
| ^ ^ ^ | | ^ ^ ^ |
| | | | | | | | | |
| v v v | | v v v |
| +-------------+ +---------+ +--------------+ +-------------+ | | +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | | | | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ | | +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ | | ^ ^ |
| | | | | | | |
| v v | | v v |
| +----------------------------------------------+ | | +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity | | | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
3.2.1.1. USM and the RFC3411 Architecture 3.2.1.1. Processing Differences between USM and Secure Transport
The following diagrams illustrate the difference in the security USM and secure transports differ is the processing order and
processing done by the USM model and the security processing responsibilities within the RFC3411 architecture. While the steps
potentially done by a transport model. are the same, they occur in a different order, and may be done by
different subsystems. The following lists illustrate the difference
in the flow and the responsibility for different processing steps for
incoming messages when using USM and when using a secure transport.
(Note that these lists are simplified for illustrative purposes, and
do not represent all details of processing. Transport Models must
provide the detailed elements of procedure.)
The USM security model is encapsulated by the messaging model, With USM and other Security Models, security processing starts when
because the messaging model needs to perform the following steps (for the Message Processing Model decodes portions of the ASN.1 message to
incoming messages) extract an opaque block of security parameters and header parameters
1) decode the ASN.1 (messaging model) that identify which Security Model should process the message to
2) determine the SNMP security model and parameters (messaging model) perform authentication, decryption, timeliness checking, integrity
3) decrypt the encrypted portions of the message (security model) checking, and translation of parameters to model-independent
4) translate parameters to model-independent parameters (security parameters. A secure transport performs those security functions on
model) the message, before the ASN.1 is decoded.
5) determine which application should get the decrypted portions
(messaging model), and
6) pass on the decrypted portions with model-independent parameters.
The USM approach uses SNMP-specific message security and parameters. Step 6 cannot occur until after decryption occurs. Step 6 and beyond
are the same for USM and a secure transport.
3.2.1.1.1. USM and the RFC3411 Architecture
1) decode the ASN.1 header (Message Processing Model)
2) determine the SNMP Security Model and parameters (Message
Processing Model)
3) verify securityLevel. [Security Model]
4) translate parameters to model-independent parameters (Security
Model)
5) authenticate and decrypt message. [Security Model]
6) determine the pduType in the decrypted portions (Message
Processing Model), and
7) pass on the decrypted portions with model-independent parameters.
3.2.1.2. Transport Subsystem and the RFC3411 Architecture 3.2.1.2. Transport Subsystem and the RFC3411 Architecture
With the Transport Subsystem, the order of the steps may differ and 1) authenticate and decrypt message. [Transport Model]
may be handled by different subsystems: 2) translate parameters to model-independent parameters (Transport
1) decrypt the encrypted portions of the message (transport layer) Model)
2*) translate parameters to model-independent parameters (transport 3) decode the ASN.1 header (Message Processing Model)
model) 4) determine the SNMP Security Model and parameters (Message
3) determine the SNMP security model and parameters (transport model) Processing Model)
4) decode the ASN.1 (messaging model) 5) verify securityLevel [Security Model]
5) determine which application should get the decrypted portions 6) determine the pduType in the decrypted portions (Message
(messaging model) Processing Model), and
7) pass on the decrypted portions with model-independent security 7) pass on the decrypted portions with model-independent security
parameters parameters
If a message is secured using non-SNMP-specific message security and If a message is secured using a secure transport layer, then the
parameters, then the transport model should provide the translation Transport Model should provide the translation from the authenticated
from the authenticated identity (e.g., an SSH user name) to the identity (e.g., an SSH user name) to the securityName in step 3.
securityName in step 3.
3.2.1.3. Passing Information between Engines 3.2.1.3. Passing Information between Engines
A secure transport model will establish an encrypted tunnel between A secure Transport Model will establish an authenticated and/or
the transport models of two SNMP engines. One transport model encrypted tunnel between the Transport Models of two SNMP engines.
instance encrypts all messages, and the other transport model
instance decrypts the messages.
After a transport layer tunnel is established, then SNMP messages can After a transport layer tunnel is established, then SNMP messages can
conceptually be sent through the tunnel from one SNMP engine to be sent through the tunnel from one SNMP engine to the other SNMP
another SNMP engine. Once the tunnel is established, multiple SNMP engine. Transport Models MAY support sending multiple SNMP messages
messages may be able to be passed through the same tunnel. through the same tunnel.
3.2.2. Access Control Requirements 3.2.2. Access Control Requirements
3.2.2.1. securityName Binding RFC3411 made some design decisions related to the support of an
Access Control Subsystem. These include a securityName and
For SNMP access control to function properly, security processing securityLevel mapping, the separation of Authentication and
must establish a securityModel identifier, a securityLevel, and a Authorization, and the passing of model-independent security
securityName, which is the security model independent identifier for parameters.
a principal. The message processing subsystem relies on a security
model, such as USM, to play a role in security that goes beyond
protecting the message - it provides a mapping between the USM-
specific principal to a security-model independent securityName which
can be used for subsequent processing, such as for access control.
The securityName MUST be bound to the mechanism-specific
authenticated identity, and this mapping MUST be done for incoming
messages before the security model passes securityName to the message
processing model via the processIncoming() ASI. This translation
from a mechanism-specific authenticated identity to a securityName
MAY be done by the transport model, and the securityname is then
provided to the security model to be passed to the message processing
model.
If the type of authentication provided by the transport layer (e.g.
TLS) is considered adequate to secure and/or encrypt the message, but
inadequate to provide the desired granularity of access control (e.g.
user-based), then a second authentication (e.g., one provided via a
RADIUS server) MAY be used to provide the authentication identity
which is bound to the securityName. This approach would require a
good analysis of the potential for man-in-the-middle attacks or
masquerade possibilities.
3.2.2.2. Separation of Authentication and Authorization
A transport model that provides security services should take care to
not violate the separation of authentication and authorization in the
RFC3411 architecture. The isAccessAllowed() primitive is used for
passing security-model independent parameters between the subsystems
of the architecture.
Mapping of (securityModel, securityName) to an access control policy
should be handled within the access control subsystem, not the
transport or security subsystems, to be consistent with the
modularity of the RFC3411 architecture. This separation was a
deliberate decision of the SNMPv3 WG, to allow support for
authentication protocols which did not provide authorization
capabilities, and to support authorization schemes, such as VACM,
that do not perform their own authentication.
An authorization model (in the access control subsystem) MAY require 3.2.2.1. securityName and securityLevel Mapping
authentication by certain securityModels and a minimum securityLevel
to allow access to the data.
Transport models that provide secure transport are an enhancement for For SNMP access control to function properly, Security Models MUST
the SNMPv3 privacy and authentication, but they are not a significant establish a securityLevel and a securityName, which is the security-
improvement for the authorization (access control) needs of SNMPv3. model-independent identifier for a principal. The Message Processing
Only the model-independent parameters for the isAccessAllowed() Subsystem relies on a Security Model, such as USM, to play a role in
primitive [RFC3411] are provided by the transport and security security that goes beyond protecting the message - it provides a
subsystems. mapping between the security-model-specific principal to a security-
model independent securityName which can be used for subsequent
processing, such as for access control.
A transport model must not specify how the securityModel and The securityName MUST be mapped from the mechanism-specific
securityName could be dynamically mapped to an access control authenticated identity, and this mapping must be done for incoming
mechanism, such as a VACM-style groupName. The mapping of messages before the Security Model passes securityName to the Message
(securityModel, securityName) to a groupName is a VACM-specific Processing Model via the processIncoming ASI. This translation from
mechanism for naming an access control policy, and for tying the a mechanism-specific authenticated identity to a securityName might
named policy to the addressing capabilities of the data modeling be done by the Transport Model, and the securityName is then provided
language (e.g. SMIv2 [RFC2578]), the operations supported, and other to the Security Model via the tmStateReference to be passed to the
factors. Providing a binding outside the Access Control subsystem Message Processing Model.
might create dependencies that could make it harder to develop
alternate models of access control, such as one built on UNIX groups
or Windows domains. The preferred approach is to pass the model-
independent security parameters via the isAccessAllowed() ASI, and
perform the mapping from the model-independent security parameters to
an authorization-model-dependent access policy within the access
control model.
To provide support for protocols which simultaneously send If the type of authentication provided by the transport layer (e.g.,
information for authentication and authorization, such as RADIUS TLS) is considered adequate to secure and/or encrypt the message, but
[RFC2865], model-specific authorization information MAY be cached or inadequate to provide the desired granularity of access control
otherwise made available to the access control subsystem, e.g., via a (e.g., user-based), then a second authentication (e.g., one provided
MIB table similar to the vacmSecurityToGroupTable, so the access via a RADIUS server) MAY be used to provide the authentication
control subsystem can create an appropriate binding between the identity which is mapped to the securityName. This approach would
model-independent securityModel and securityName and a model-specific require a good analysis of the potential for man-in-the-middle
access control policy. This may be highly undesirable, however, if attacks or masquerade possibilities.
it creates a dependency between a transport model or a security model
and an access control model, just as it is undesirable for a
transport model to create a dependency between an SNMP message
version and the security provided by a transport model.
3.2.3. Security Parameter Passing Requirements 3.2.3. Security Parameter Passing Requirements
RFC3411 section 4 describes primitives to describe the abstract data RFC3411 section 4 describes abstract data flows between the
flows between the various subsystems, models and applications within subsystems, models and applications within the architecture.
the architecture. Abstract Service Interfaces describe the flow of Abstract Service Interfaces describe the flow of data, passing model-
data between subsystems within an engine. The ASIs generally pass independent information between subsystems within an engine. The
model-independent information. RFC3411 architecture has no ASI parameters for passing security
information between the Transport Subsystem and the dispatcher, or
Within an engine using a transport model, outgoing SNMP messages are between the dispatcher and the Message Processing Model. This
passed unencrypted from the message dispatcher to the transport document defines or modifies ASIs for this purpose.
model, and incoming messages are passed unencrypted from the
transport model to the message dispatcher.
The security parameters include a model-independent identifier of the The security parameters include a model-independent identifier of the
security "principal", the security model used to perform the security "principal" (the securityName), the Security Model used to
authentication, and which SNMP-specific security services were perform the authentication, and which authentication and privacy
(should be) applied to the message (authentication and/or privacy). services were (should be) applied to the message (securityLevel).
In the RFC3411 architecture, which reflects the USM security model A Message Processing Model might unpack SNMP-specific security
design, the messaging model must unpack SNMP-specific security
parameters from an incoming message before calling a specific parameters from an incoming message before calling a specific
security model to authenticate and decrypt an incoming message, Security Model to authenticate and decrypt an incoming message,
perform integrity checking, and translate model-specific security perform integrity checking, and translate security-model-specific
parameters into model-independent parameters. parameters into model-independent parameters. When using a secure
Transport Model, security parameters might be provided through means
other than carrying them in the SNMP message; the parameters for
incoming messages might be extracted from the transport layer by the
Transport Model before the message is passed to the Message
Processing Subsystem.
When using a secure transport model, security parameters MAY be This document describes a cache mechanism (see Section 5), into which
provided through means other than carrying them in the SNMP message. the Transport Model puts information about the transport and security
The parameters MAY be provided by SNMP applications for outgoing parameters applied to a transport connection or an incoming message,
messages, and the parameters for incoming messages MAY be extracted and a Security Model may extract that information from the cache. A
from the transport layer by the transport model before the message is tmStateReference is passed as an extra parameter in the ASIs of the
passed to the message processing subsystem. Transport Subsystem and the Message Processing and Security
Subsystems, to identify the relevant cache. This approach of passing
a model-independent reference is consistent with the
securityStateReference cache already being passed around in the
RFC3411 ASIs.
For outgoing messages, even when a secure transport model will For outgoing messages, even when a secure Transport Model will
provide the security services, it is necessary to have an security provide the security services, a Message Processing Model might have
model because it is the security model that actually creates the a Security Model actually create the message from its component
message from its component parts. Whether there are any security parts. Whether there are any security services provided by the
services provided by the security model for an outgoing message is Security Model for an outgoing message is security-model-dependent.
model-dependent. For incoming messages, even when a secure Transport Model provides
security services, a Security Model might provide some security
functionality that can only be provided after the message version or
other parameters are extracted from the message.
For incoming messages, even when a secure transport model provides 3.2.4. Separation of Authentication and Authorization
security services, a security model is necessary because there might
be some security functionality that can only be provided after the
message version is known. The message version is determined by the
Message Processing model and passed to the security model via the
processIncoming() ASI.
The RFC3411 architecture has no ASI parameters for passing security The RFC3411 architecture defines a separation of authentication and
information between a transport mapping (a transport model) and the authorization (access control), and a Transport Model that provides
dispatcher, and between the dispatcher and the message processing security services should take care to not violate this separation. A
model. Transport Model must not specify how the securityModel and
securityName could be dynamically mapped to an access control
mechanism, such as a VACM-style groupName.
This document describes a cache mechanism, into which the transport The RECOMMENDED approach is to pass the model-independent security
model puts information about the transport and security parameters parameters via the isAccessAllowed ASI, and perform the mapping from
applied to a transport connection or an incoming message, and a the model-independent security parameters to an access-control-model-
security model MAY extract that information from the cache. A dependent policy within the Access Control Model. The
tmStateReference is passed as an extra parameter in the ASIs of the isAccessAllowed ASI is used for passing the securityModel,
transport subsystem and the messaging and security subsystems, to securityName, and securityLevel parameters that are independent of
identify the relevant cache. any specific security model and any specific access control model to
the Access Control Subsystem.
This approach of passing a model-independent reference is consistent The mapping of (securityModel, securityName, securityLevel) to an
with the securityStateReference cache already being passed around in access-control-model-specific policy should be handled within a
the RFC3411 ASIs. specific access control model. This mapping should not be done in
the Transport or Security Subsystems, to be consistent with the
modularity of the RFC3411 architecture. This separation was a
deliberate decision of the SNMPv3 WG, to allow support for
authentication protocols which did not provide authorization (access
control) capabilities, and to support authorization schemes, such as
VACM, that do not perform their own authentication.
The View-based Access Control Model uses the securityModel and the
securityName as inputs to check for access rights. It determines the
groupName as a function of securityModel and securityName. Providing
a binding outside the Access Control Subsystem might create
dependencies that could make it harder to develop alternate models of
access control, such as one built on UNIX groups or Windows domains.
To provide support for protocols which simultaneously send
information for authentication and authorization (access control),
such as RADIUS [RFC2865], access-control-model-specific information
might be cached or otherwise made available to the Access Control
Subsystem, e.g., via a MIB table similar to the
vacmSecurityToGroupTable, so the Access Control Subsystem can create
an appropriate binding between the access-control-model-independent
securityModel and securityName and an access-control-model-specific
policy. This would be highly undesirable, however, if it creates a
dependency between a Transport Model or a Security Model and an
Access Control Model.
3.3. Session Requirements 3.3. Session Requirements
Some secure transports may have a notion of sessions, while other Some secure transports might have a notion of sessions, while other
secure transports might provide channels or other session-like thing. secure transports might provide channels or other session-like
Throughout this document, the term session is used in a broad sense mechanism. Throughout this document, the term session is used in a
to cover sessions, channels, and session-like things. Session refers broad sense to cover sessions, channels, and session-like mechanisms.
to an association between two SNMP engines that permits the Session refers to an association between two SNMP engines that
transmission of one or more SNMP messages within the lifetime of the permits the transmission of one or more SNMP messages within the
session. How the session is actually established, opened, closed, or lifetime of the session. How the session is actually established,
maintained is specific to a particular transport model. opened, closed, or maintained is specific to a particular Transport
Model.
Sessions are not part of the SNMP architecture described in Sessions are not part of the SNMP architecture defined in [RFC3411],
[RFC3411], but are considered desirable because the cost of but are considered desirable because the cost of authentication can
authentication can be amortized over potentially many transactions. be amortized over potentially many transactions.
It is important to note that the architecture described in [RFC3411] The architecture defined in [RFC3411] does not include a session
does not include a session selector in the Abstract Service selector in the Abstract Service Interfaces, and neither is that done
Interfaces, and neither is that done for the transport subsystem, so for the Transport Subsystem, so an SNMP application has no mechanism
an SNMP application cannot select the session except by passing a to select a session using the ASIs except by passing a unique
unique combination of transport type, transport address, combination of transportDomain, transportAddress, securityName,
securityName, securityModel, and securityLevel. securityModel, and securityLevel. Implementers, of course, might
provide non-standard mechanisms to select sessions. The
transportDomain and transportAddress identify the transport
connection to a remote network node; the securityName identifies
which security principal to communicate with at that address (e.g.,
different NMS applications), and the securityModel and securityLevel
might permit selection of different sets of security properties for
different purposes (e.g., encrypted SETs vs. non-encrypted GETs).
All transport models should discuss the impact of sessions on SNMP All Transport Models should discuss the impact of sessions on SNMP
usage, including how to establish/open a transport session (i.e., how usage, including how to establish/open a transport session (i.e., how
it maps to the concepts of session-like things of the underlying it maps to the concepts of session-like mechanisms of the underlying
protocol), how to behave when a session cannot be established, how to protocol), how to behave when a session cannot be established, how to
close a session properly, how to behave when a session is closed close a session properly, how to behave when a session is closed
improperly, the session security properties, session establishment improperly, the session security properties, session establishment
overhead, and session maintenance overhead. overhead, and session maintenance overhead.
To reduce redundancy, this document will discuss aspects that are To reduce redundancy, this document describes aspects that are
expected to be common to all transport model sessions. expected to be common to all Transport Model sessions.
3.3.1. Session Establishment Requirements 3.3.1. Session Establishment Requirements
SNMP applications must provide the transport type, transport address, SNMP applications must provide the transportDomain, transportAddress,
securityName, securityModel, and securityLevel to be used for a securityName, securityModel, and securityLevel to be used for a
session. session.
SNMP Applications typically have no knowledge of whether the session SNMP Applications might have no knowledge of whether the session that
that will be used to carry commands was initially established as a will be used to carry commands was initially established as a
notification session, or a request-response session, and SHOULD NOT notification session, or a request-response session, and SHOULD NOT
make any assumptions based on knowing the direction of the session. make any assumptions based on knowing the direction of the session.
If an administrator or transport model designer wants to If an administrator or Transport Model designer wants to
differentiate a session established for different purposes, such as a differentiate a session established for different purposes, such as a
notification session versus a request-response session, the notification session versus a request-response session, the
application can use different securityNames or transport addresses application can use different securityNames or transport addresses
(e.g., port 161 vs. port 162) for different purposes. (e.g., port 161 vs. port 162) for different purposes.
An SNMP engine containing an application that initiates An SNMP engine containing an application that initiates
communication, e.g., a Command Generator or Notification Originator, communication, e.g., a Command Generator or Notification Originator,
MUST be able to attempt to establish a session for delivery if a must be able to attempt to establish a session for delivery if a
session does not yet exist. If a session cannot be established then session does not yet exist. If a session cannot be established then
the message is discarded. the message is discarded.
Sessions are usually established by the transport model when no Sessions are usually established by the Transport Model when no
appropriate session is found for an outgoing message, but sessions appropriate session is found for an outgoing message, but sessions
may be established in advance to support features such as might be established in advance to support features such as
notifications. How sessions are established in advance is beyond the notifications. How sessions are established in advance is beyond the
scope of this document. scope of this document.
Sessions are initiated by notification originators when there is no Sessions are initiated by notification originators when there is no
currently established connection that can be used to send the currently established connection that can be used to send the
notification. For a client-server security protocol, this may notification. For a client-server security protocol, this might
require provisioning authentication credentials on the agent, either require provisioning authentication credentials on the agent, either
statically or dynamically, so the client/agent can successfully statically or dynamically, so the client/agent can successfully
authenticate to a notification receiver. authenticate to a notification receiver.
A transport model must be able to determine whether a session does or A Transport Model must be able to determine whether a session does or
does not exist, and must be able to determine which session has the does not exist, and must be able to determine which session has the
appropriate security characteristics (transport type, transport appropriate security characteristics (transportDomain,
address, securityName, securityModel, and securityLevel) for an transportAddress, securityName, securityModel, and securityLevel) for
outgoing message. an outgoing message.
A transport model implementation MAY reuse an already established A Transport Model implementation MAY reuse an already established
session with the appropriate transport type, transport address, session with the appropriate transportDomain, transportAddress,
securityName, securityModel, and securityLevel characteristics for securityName, securityModel, and securityLevel characteristics for
delivery of a message originated by a different type of application delivery of a message containing a different pduType than originally
than originally caused the session to be created. For example, an caused the session to be created. For example, an implementation
implementation that has an existing session originally established to that has an existing session originally established to receive a
receive a request may use that session to send an outgoing request MAY use that session to send an outgoing notification, and
notification, and may use a session that was originally established MAY use a session that was originally established to send a
to send a notification to send a request. Responses are expected to notification to send a request. Responses SHOULD be returned using
be returned using the same session that carried the corresponding the same session that carried the corresponding request message.
request message. Reuse of sessions is not required for conformance. Reuse of sessions is not required for conformance.
If a session can be reused for a different type of message, but a If a session can be reused for a different pduType, but a receiver is
receiver is not prepared to accept different message types over the not prepared to accept different pduTypes over the same session, then
same session, then the message MAY be dropped by the receiver. This the message MAY be dropped by the receiver.
may strongly affect the usefulness of session reuse, and transport
models should define a standard behavior for this circumstance.
3.3.2. Session Maintenance Requirements 3.3.2. Session Maintenance Requirements
A transport model can tear down sessions as needed. It may be A Transport Model can tear down sessions as needed. It might be
necessary for some implementations to tear down sessions as the necessary for some implementations to tear down sessions as the
result of resource constraints, for example. result of resource constraints, for example.
The decision to tear down a session is implementation-dependent. The decision to tear down a session is implementation-dependent.
While it is possible for an implementation to automatically tear down While it is possible for an implementation to automatically tear down
each session once an operation has completed, this is not recommended each session once an operation has completed, this is not recommended
for anticipated performance reasons. How an implementation for anticipated performance reasons. How an implementation
determines that an operation has completed, including all potential determines that an operation has completed, including all potential
error paths, is implementation-dependent. error paths, is implementation-dependent.
The elements of procedure may discuss when cached information can be The elements of procedure describe when cached information can be
discarded, and the timing of cache cleanup may have security discarded, in some circumstances, and the timing of cache cleanup
implications, but cache memory management is an implementation issue. might have security implications, but cache memory management is an
implementation issue.
If a transport model defines MIB module objects to maintain session If a Transport Model defines MIB module objects to maintain session
state information, then the transport model MUST describe what state information, then the Transport Model MUST define what SHOULD
happens to the objects when a related session is torn down, since happen to the objects when a related session is torn down, since this
this will impact interoperability of the MIB module. will impact interoperability of the MIB module.
3.3.3. Message security versus session security 3.3.3. Message security versus session security
A transport model session is associated with state information that A Transport Model session is associated with state information that
is maintained for its lifetime. This state information allows for is maintained for its lifetime. This state information allows for
the application of various security services to multiple messages. the application of various security services to multiple messages.
Cryptographic keys established at the beginning of the session SHOULD Cryptographic keys established at the beginning of the session SHOULD
be used to provide authentication, integrity checking, and encryption be used to provide authentication, integrity checking, and encryption
services for data that is communicated during the session. The services for data that is communicated during the session. The
cryptographic protocols used to establish keys for a transport model cryptographic protocols used to establish keys for a Transport Model
session SHOULD ensure that fresh new session keys are generated for session SHOULD ensure that fresh new session keys are generated for
each session. If each session uses new session keys, then messages each session. In addition sequence information might be maintained
cannot be replayed from one session to another. In addition sequence in the session which can be used to prevent the replay and reordering
information MAY be maintained in the session which can be used to of messages within a session. If each session uses new keys, then a
prevent the replay and reordering of messages within a session. cross-session replay attack will be unsuccessful; that is, an
attacker cannot successfully replay on one session a message he
observed from another session. A good security protocol will also
protect against replay attacks _within_ a session; that is, an
attacker cannot successfully replay a message observed earlier in the
same session.
A transport model session will typically have a single transport A Transport Model session will have a single transportDomain,
type, transport address, securityModel, securityName and transportAddress, securityModel, securityName and securityLevel
securityLevel associated with it. If an exchange between associated with it. If an exchange between communicating engines
communicating engines requires a different securityLevel or is on requires a different securityLevel or is on behalf of a different
behalf of a different securityName, or uses a different securityName, or uses a different securityModel, then another session
securityModel, then another session would be needed. An immediate would be needed. An immediate consequence of this is that
consequence of this is that implementations should be able to implementations SHOULD be able to maintain some reasonable number of
maintain some reasonable number of concurrent sessions. concurrent sessions.
For transport models, securityName is typically specified during For Transport Models, securityName should be specified during session
session setup, and associated with the session identifier. setup, and associated with the session identifier.
SNMPv3 was designed to support multiple levels of security, SNMPv3 was designed to support multiple levels of security,
selectable on a per-message basis by an SNMP application, because selectable on a per-message basis by an SNMP application, because,
there is not much value in using encryption for a Commander Generator for example, there is not much value in using encryption for a
to poll for non-sensitive performance data on thousands of interfaces Commander Generator to poll for potentially non-sensitive performance
every ten minutes; the encryption may add significant overhead to data on thousands of interfaces every ten minutes; the encryption
processing of the messages. might add significant overhead to processing of the messages.
Some transport models MAY support only specific authentication and Some Transport Models might support only specific authentication and
encryption services, such as requiring all messages to be carried encryption services, such as requiring all messages to be carried
using both authentication and encryption, regardless of the security using both authentication and encryption, regardless of the security
level requested by an SNMP application. A transport model MAY level requested by an SNMP application. A Transport Model may
upgrade the requested security level, i.e. noAuth/noPriv and auth/ upgrade the requested security level, i.e. noAuthNoPriv and
noPriv MAY be sent over an authenticated and encrypted session. authNoPriv MAY be sent over an authenticated and encrypted session.
4. Scenario Diagrams for the Transport Subsystem 4. Scenario Diagrams for the Transport Subsystem
RFC3411 section 4.6 provides scenario diagrams to illustrate how an RFC3411 section 4.6 provides scenario diagrams to illustrate how an
outgoing message is created, and how an incoming message is outgoing message is created, and how an incoming message is
processed. Both diagrams are incomplete, however. In section 4.6.1, processed. Both diagrams are incomplete, however. In section 4.6.1,
the diagram doesn't show the ASI for sending an SNMP request to the the diagram doesn't show an ASI for sending an SNMP request to the
network or receiving an SNMP response message from the network. In network or for receiving an SNMP response message from the network.
section 4.6.2, the diagram doesn't illustrate the interfaces required In section 4.6.2, the diagram doesn't show the ASIs to receive an
to receive an SNMP message from the network, or to send an SNMP SNMP message from the network, or to send an SNMP message to the
message to the network. network.
4.1. Command Generator or Notification Originator 4.1. Command Generator or Notification Originator
This diagram from RFC3411 4.6.1 shows how a Command Generator or This diagram from RFC3411 4.6.1 shows how a Command Generator or
Notification Originator application [RFC3413] requests that a PDU be Notification Originator application [RFC3413] requests that a PDU be
sent, and how the response is returned (asynchronously) to that sent, and how the response is returned (asynchronously) to that
application. application.
This document defines a sendMessage ASI to send SNMP messages to the
network, and a receiveMessage ASI to receive SNMP messages from the
network.
Command Dispatcher Message Security Command Dispatcher Message Security
Generator | Processing Model Generator | Processing Model
| | Model | | | Model |
| sendPdu | | | | sendPdu | | |
|------------------->| | | |------------------->| | |
| | prepareOutgoingMessage | | | | prepareOutgoingMessage | |
: |----------------------->| | : |----------------------->| |
: | | generateRequestMsg | : | | generateRequestMsg |
: | |-------------------->| : | |-------------------->|
: | | | : | | |
skipping to change at page 18, line 50 skipping to change at page 21, line 10
: |<-----------------------| | : |<-----------------------| |
| processResponsePdu | | | | processResponsePdu | | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
4.2. Command Responder 4.2. Command Responder
This diagram shows how a Command Responder or Notification Receiver This diagram shows how a Command Responder or Notification Receiver
application registers for handling a pduType, how a PDU is dispatched application registers for handling a pduType, how a PDU is dispatched
to the application after an SNMP message is received, and how the to the application after an SNMP message is received, and how the
Response is (asynchronously) send back to the network. Response is (asynchronously) sent back to the network.
This document defines the sendMessage and receiveMessage ASIs for
this purpose.
Command Dispatcher Message Security Command Dispatcher Message Security
Responder | Processing Model Responder | Processing Model
| | Model | | | Model |
| | | | | | | |
| registerContextEngineID | | | | registerContextEngineID | | |
|------------------------>| | | |------------------------>| | |
|<------------------------| | | | |<------------------------| | | |
| | Receive SNMP | | | | | Receive SNMP | | |
: | Message | | | : | Message | | |
skipping to change at page 19, line 51 skipping to change at page 22, line 51
: |--------------+ | | : |--------------+ | |
: | Send SNMP | | | : | Send SNMP | | |
: | Message | | | : | Message | | |
: | to Network | | | : | to Network | | |
: | v | | : | v | |
5. Cached Information and References 5. Cached Information and References
The RFC3411 architecture uses caches to store dynamic model-specific The RFC3411 architecture uses caches to store dynamic model-specific
information, and uses references in the ASIs to indicate in a model- information, and uses references in the ASIs to indicate in a model-
independent manner which cached information must flow between independent manner which cached information flows between subsystems.
subsystems.
There are two levels of state that may need to be maintained: the There are two levels of state that might need to be maintained: the
security state in a request-response pair, and potentially long-term security state in a request-response pair, and potentially long-term
state relating to transport and security. state relating to transport and security.
This state is maintained in caches. To simplify the elements of This state is maintained in caches. To simplify the elements of
procedure, the release of state information is not always explicitly procedure, the release of state information is not always explicitly
specified. As a general rule, if state information is available when specified. As a general rule, if state information is available when
a message being processed gets discarded, the state related to that a message being processed gets discarded, the state related to that
message should also be discarded, and if state information is message should also be discarded, and if state information is
available when a relationship between engines is severed, such as the available when a relationship between engines is severed, such as the
closing of a transport session, the state information for that closing of a transport session, the state information for that
relationship might also be discarded. relationship might also be discarded.
This document differentiates the tmStateReference from the This document differentiates the tmStateReference from the
securityStateReference. This document does not specify an securityStateReference. This document does not specify an
implementation strategy, only an abstract discussion of the data that implementation strategy, only an abstract description of the data
must flow between subsystems. An implementation MAY use one cache that flows between subsystems. An implementation might use one cache
and one reference to serve both functions, but an implementer must be and one reference to serve both functions, but an implementer must be
aware of the cache-release issues to prevent the cache from being aware of the cache-release issues to prevent the cache from being
released before a security or transport model has had an opportunity released before a security or Transport Model has had an opportunity
to extract the information it needs. to extract the information it needs.
5.1. securityStateReference 5.1. securityStateReference
From RFC3411: "For each message received, the Security Model caches From RFC3411: "For each message received, the Security Model caches
the state information such that a Response message can be generated the state information such that a Response message can be generated
using the same security information, even if the Local Configuration using the same security information, even if the Local Configuration
Datastore is altered between the time of the incoming request and the Datastore is altered between the time of the incoming request and the
outgoing response. outgoing response." To enable this, an abstract
securityStateReference data element, defined in RFC3411 section
A Message Processing Model has the responsibility for explicitly A.1.5, is passed from the Security Model to the Message Processing
releasing the cached data if such data is no longer needed. To Model.
enable this, an abstract securityStateReference data element is
passed from the Security Model to the Message Processing Model. The
cached security data may be implicitly released via the generation of
a response, or explicitly released by using the stateRelease
primitive, as described in RFC3411 section 4.5.1."
The information saved should include the model-independent parameters The information saved should include the model-independent parameters
(transportDomain, transportAddress, securityName, securityModel, and (transportDomain, transportAddress, securityName, securityModel, and
securityLevel), related security parameters, and other information securityLevel), related security parameters, and other information
needed to imatch the response with the request. The Message needed to match the response with the request. The related security
Processing Model has the responsibility for explicitly releasing the parameters may include transport-specific security information.
securityStateReference when such data is no longer needed. The
securityStateReference cached data may be implicitly released via the
generation of a response, or explicitly released by using the
stateRelease primitive, as described in RFC 3411 section 4.5.1."
If the transport model connection is closed between the time a The Message Processing Model has the responsibility for explicitly
releasing the securityStateReference when such data is no longer
needed. The securityStateReference cached data may be implicitly
released via the generation of a response, or explicitly released by
using the stateRelease ASI, as defined in RFC 3411 section 4.5.1."
If the Transport Model connection is closed between the time a
Request is received and a Response message is being prepared, then Request is received and a Response message is being prepared, then
the Response message MAY be discarded. the Response message MAY be discarded.
5.2. tmStateReference 5.2. tmStateReference
For each message or transport session, information about the message For each message or transport session, information about the message
security is stored in a cache, which may inlcude model- and security is stored in a cache, which may include model- and
mechanism-specific parameters. The tmStateReference is passed mechanism-specific parameters. The tmStateReference is passed
between subsystems to provide a handle for the cache. A transport between subsystems to provide a handle for the cache. A Transport
model may store transport-specific parameters in the cache for Model may store transport-specific parameters in the cache for
subsequent usage. Since the contents of a cache are meaningful only subsequent usage. Since the contents of a cache are meaningful only
within an implementation, and not on-the-wire, the format of the within an implementation, and not on-the-wire, the format of the
cache is implementation-specific. cache is implementation-specific.
The state referenced by tmStateReference may be saved in a Local The state referenced by tmStateReference might be saved in a Local
Configuration Datastore (LCD) to make it available across multiple Configuration Datastore (LCD) to make it available across multiple
messages, as compared to securityStateReference which is designed to messages, as compared to securityStateReference which is designed to
be saved only for the life of a request-response pair of messages. be saved only for the life of a request-response pair of messages.
It is expected that an LCD will allow lookup based on the combination It is expected that an LCD will allow lookup based on the combination
of transportDomain, transportAddress, securityName, securityModel, of transportDomain, transportAddress, securityName, securityModel,
and securityLevel, and that the cache contain these values to and securityLevel, and that the cache contain these values to
reference entries in the LCD. reference entries in the LCD.
6. Abstract Service Interfaces 6. Abstract Service Interfaces
Abstract service interfaces have been defined by RFC 3411 to describe Abstract service interfaces have been defined by RFC 3411 to describe
the conceptual data flows between the various subsystems within an the conceptual data flows between the various subsystems within an
SNMP entity. SNMP entity, and to help keep the subsystems independent of each
other except for the common parameters.
To simplify the elements of procedure, the release of state This document follows the example of RFC3411 regarding the release of
information is not always explicitly specified. As a general rule, state information, and regarding error indications.
if state information is available when a message gets discarded, the
message-state information should also be released, and if state
information is available when a session is closed, the session state
information should also be released.
An error indication may return an OID and value for an incremented 1) The release of state information is not always explicitly
counter and a value for securityLevel, and values for contextEngineID specified in a transport model. As a general rule, if state
and contextName for the counter, and the securityStateReference if information is available when a message gets discarded, the message-
the information is available at the point where the error is state information should also be released, and if state information
detected. is available when a session is closed, the session state information
should also be released.
6.1. Generating an Outgoing SNMP Message 2) An error indication in statusInformation may include an OID and
value for an incremented counter and a value for securityLevel, and
values for contextEngineID and contextName for the counter, and the
securityStateReference if the information is available at the point
where the error is detected.
This section describes the procedure followed by an RFC3411- 6.1. sendMessage ASI
compatible system whenever it generates a message containing a
management operation (such as a request, a response, a notification, The sendMessage ASI is used to pass a message from the Dispatcher to
or a report) on behalf of a user. the appropriate Transport Model for sending.
If present and valid, the tmStateReference refers to a cache
containing transport-model-specific parameters for the transport and
transport security. How the information in the cache is used is
transport-model-dependent and implementation-dependent. How a
tmStateReference is determined to be present and valid is
implementation-dependent.
This may sound underspecified, but keep in mind that a transport
model might be something like SNMP over UDP over IPv6, where no
security is provided, so it might have no mechanisms for utilizing a
securityName and securityLevel.
statusInformation =
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state
)
6.2. Other Outgoing ASIs
A tmStateReference parameter has been added to the
prepareOutgoingMessage, generateRequestMsg, and generateResponseMsg
ASIs as an OUT parameter.
statusInformation = -- success or errorIndication statusInformation = -- success or errorIndication
prepareOutgoingMessage( prepareOutgoingMessage(
IN transportDomain -- transport domain to be used IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity IN contextEngineID -- data from/at this entity
skipping to change at page 22, line 33 skipping to change at page 26, line 4
IN PDU -- SNMP Protocol Data Unit IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching IN sendPduHandle -- the handle for matching
incoming responses incoming responses
OUT destTransportDomain -- destination transport domain OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length OUT outgoingMessageLength -- its length
OUT tmStateReference -- (NEW) reference to transport state OUT tmStateReference -- (NEW) reference to transport state
) )
The tmStateReference parameter of generateRequestMsg or
generateResponseMsg is passed in the return parameters of the
Security Subsystem to the Message Processing Subsystem. If a cache
exists for a session identifiable from transportDomain,
transportAddress, securityModel, securityName, and securityLevel,
then an appropriate Security Model might create a tmStateReference to
the cache and pass that as an OUT parameter.
Note that tmStateReference has been added to this ASI. If one does not exist, the Security Model might create a cache
referenced by tmStateReference. This information might include
The IN parameters of the prepareOutgoingMessage() ASI are used to transportDomain, transportAddress, the securityModel, the
pass information from the dispatcher (from the application subsystem) securityLevel, and the securityName, plus any model or mechanism-
to the message processing subsystem. specific details. The contents of the cache may be incomplete until
the Transport Model has established a session. What information is
The abstract service primitive from a Message Processing Model to a passed, and how this information is determined, is implementation and
Security Model to generate the components of a Request message is security-model-specific.
generateRequestMsg().
The abstract service primitive from a Message Processing Model to a
Security Model to generate the components of a Response message is
generateResponseMsg().
Upon completion of processing, the Security Model returns
statusInformation. If the process was successful, the completed
message is returned. If the process was not successful, then an
errorIndication is returned.
The OUT parameters of the prepareOutgoingMessage() ASI are used to
pass information from the message processing model to the dispatcher
and on to the transport model:
6.2. Processing for an Outgoing Message The prepareOutgoingMessage ASI passes tmStateReference from the
Message Processing Subsystem to the dispatcher. How or if the
Message Processing Subsystem modifies or utilizes the contents of the
cache is message-processing-model-specific.
The sendMessage ASI is used to pass a message from the Dispatcher to This may sound underspecified, but keep in mind that a message
the appropriate transport model for sending. processing model might have access to all the information from the
cache and from the message, and have no need to call a Security Model
to do any processing; an application might choose a Security Model
such as USM to authenticate and secure the SNMP message, but also
utilize a secure transport such as that provided by the SSH Transport
Model to send the message to its destination.
statusInformation = 6.3. The receiveMessage ASI
sendMessage(
IN destTransportDomain -- transport domain to be used
IN destTransportAddress -- transport address to be used
IN outgoingMessage -- the message to send
IN outgoingMessageLength -- its length
IN tmStateReference -- reference to transport state
)
6.3. Processing an Incoming SNMP Message If one does not exist, the Transport Model might create a cache
referenced by tmStateReference. If present, this information might
include transportDomain, transportAddress, securityLevel, and
securityName, plus model or mechanism-specific details. How this
information is determined is implementation and transport-model-
specific.
6.3.1. Processing an Incoming Message This may sound underspecified, but keep in mind that a transport
model might be something like SNMP over UDP over IPv6, where no
security is provided, so it might have no mechanisms for determining
a securityName and securityLevel.
If one does not exist, the Transport Model will need to create an The Transport Model does not know the securityModel for an incoming
entry in a Local Configuration Datastore referenced by message; this will be determined by the Message Processing Model in a
tmStateReference. This information will include transportDomain, message-processing-model-dependent manner.
transportAddress, the securityModel, the securityLevel, and the
securityName, plus any model or mechanism-specific details. How this
information is determined is model-specific.
The recvMessage ASI is used to pass a message from the transport The receiveMessage ASI is used to pass a message from the Transport
subsystem to the Dispatcher. Subsystem to the Dispatcher.
statusInformation = statusInformation =
recvMessage( receiveMessage(
IN transportDomain -- origin transport domain IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address IN transportAddress -- origin transport address
IN incomingMessage -- the message received IN incomingMessage -- the message received
IN incomingMessageLength -- its length IN incomingMessageLength -- its length
IN tmStateReference -- reference to transport state IN tmStateReference -- reference to transport state
) )
6.3.2. Prepare Data Elements from Incoming Messages 6.4. Other Incoming ASIs
The abstract service primitive from the Dispatcher to a Message To support the Transport Subsystem, the tmStateReference is added to
Processing Model for a received message is: the prepareDataElements ASI (from the Dispatcher to the Message
Processing Subsystem), and to the processIncomingMsg ASI (from the
Message Processing Subsystem to the Security Model Subsystem). How
or if a Message Processing Model or Security Model uses
tmStateReference is message-processing-model-dependent and security-
model-dependent.
result = -- SUCCESS or errorIndication result = -- SUCCESS or errorIndication
prepareDataElements( prepareDataElements(
IN transportDomain -- origin transport domain IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network IN wholeMsgLength -- as received from the network
IN tmStateReference -- (NEW) from the transport model IN tmStateReference -- (NEW) from the Transport Model
OUT messageProcessingModel -- typically, SNMP version OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication OUT statusInformation -- success or errorIndication
-- error counter OID/value if error -- error counter OID/value if error
OUT stateReference -- reference to state information OUT stateReference -- reference to state information
-- to be used for possible Response -- to be used for possible Response
) )
Note that tmStateReference has been added to this ASI.
6.3.3. Processing an Incoming Message
This section describes the procedure followed by the Security Model
whenever it receives an incoming message containing a management
operation on behalf of a user from a Message Processing model.
The Message Processing Model extracts some information from the
wholeMsg. The abstract service primitive from a Message Processing
Model to the Security Subsystem for a received message is:
statusInformation = -- errorIndication or success statusInformation = -- errorIndication or success
-- error counter OID/value if error -- error counter OID/value if error
processIncomingMsg( processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message IN securityParameters -- for the received message
IN securityModel -- for the received message IN securityModel -- for the received message
IN securityLevel -- Level of Security IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire IN wholeMsgLength -- length as received on the wire
IN tmStateReference -- (NEW) from the transport model IN tmStateReference -- (NEW) from the Transport Model
OUT securityEngineID -- authoritative SNMP entity OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state OUT securityStateReference -- reference to security state
) -- information, needed for response ) -- information, needed for response
1) The securityEngineID is set to a value in a model-specific manner. The tmStateReference parameter of prepareDataElements is passed from
If the securityEngineID is not utilized by the specific model, then the dispatcher to the Message Processing Subsystem. How or if the
it should be set to the local snmpEngineID, to satisfy the SNMPv3 Message Processing Subsystem modifies or utilizes the contents of the
message processing model in RFC 3412 section 7.2 13a). cache is message-processing-model-specific.
2) Extract the value of securityName from the Local Configuration
Datastore entry referenced by tmStateReference.
3) The scopedPDU component is extracted from the wholeMsg.
4) The maxSizeResponseScopedPDU is calculated. This is the maximum The processIncomingMessage ASI passes tmStateReference from the
size allowed for a scopedPDU for a possible Response message. Message Processing Subsystem to the Security Subsystem.
5) The security data is cached as cachedSecurityData, so that a If tmStateReference is present and valid, an appropriate Security
possible response to this message can and will use the same security Model might utilize the information in the cache. How or if the
parameters. Then securityStateReference is set for subsequent Security Subsystem utilizes the information in the cache is security-
reference to this cached data. model-specific.
6) The statusInformation is set to success and a return is made to This may sound underspecified, but keep in mind that a message
the calling module passing back the OUT parameters as specified in processing model might have access to all the information from the
the processIncomingMsg primitive. cache and from the message, and have no need to call a Security Model
to do any processing. The Message Processing Model might determine
that the USM Security Model is specified in an SNMPv3 message header;
the USM Security Model has no need of values in the tmStateReference
cache to authenticate and secure the SNMP message, but an application
might have chosen to use a secure transport such as that provided by
the SSH Transport Model to send the message to its destination.
7. Security Considerations 7. Security Considerations
This document describes an architectural approach that would permit This document defines an architectural approach that permits SNMP to
SNMP to utilize transport layer security services. Each proposed utilize transport layer security services. Each proposed Transport
transport model should discuss the security considerations of the Model should discuss the security considerations of the Transport
transport model. Model.
It is considered desirable by some industry segments that SNMP It is considered desirable by some industry segments that SNMP
transport models should utilize transport layer security that Transport Models should utilize transport layer security that
addresses perfect forward secrecy at least for encryption keys. addresses perfect forward secrecy at least for encryption keys.
Perfect forward secrecy guarantees that compromise of long term Perfect forward secrecy guarantees that compromise of long term
secret keys does not result in disclosure of past session keys. The secret keys does not result in disclosure of past session keys. Each
editors recommend that each proposed transport model include a proposed Transport Model should include a discussion in its security
discussion in its security considerations of whether perfect forward considerations of whether perfect forward security is appropriate for
security is appropriate for the transport model. the Transport Model.
Since the cache and LCD will contain security-related parameters, Since the cache and LCD will contain security-related parameters,
they should be kept in protected storage. implementers should store this information (in memory or in
persistent storage) in a manner to protect it from unauthorized
disclosure and/or modification.
Care must be taken to ensure that a SNMP engine is sending packets
out over a transport using credentials that are legal for that engine
to use on behalf of that user. Otherwise an engine that has multiple
transports open might be "tricked" into sending a message through the
wrong transport.
8. IANA Considerations 8. IANA Considerations
This document requires no action by IANA. This document requires no action by IANA.
9. Acknowledgments 9. Acknowledgments
The Integrated Security for SNMP WG would like to thank the following The Integrated Security for SNMP WG would like to thank the following
people for their contributions to the process: people for their contributions to the process:
The authors of submitted security model proposals: Chris Elliot, Wes The authors of submitted Security Model proposals: Chris Elliot, Wes
Hardaker, Dave Harrington, Keith McCloghrie, Kaushik Narayan, Dave Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David
Perkins, Joseph Salowey, and Juergen Schoenwaelder. Perkins, Joseph Salowey, and Juergen Schoenwaelder.
The members of the Protocol Evaluation Team: Uri Blumenthal, The members of the Protocol Evaluation Team: Uri Blumenthal,
Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla.
WG members who committed to and performed detailed reviews: Jeffrey WG members who committed to and performed detailed reviews: Jeffrey
Hutzelman Hutzelman
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for
Indicate Requirement Levels", BCP 14, use in RFCs to Indicate
RFC 2119, March 1997. Requirement Levels",
BCP 14, RFC 2119,
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. March 1997.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58,
RFC 2578, April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, [RFC3411] Harrington, D., Presuhn,
"An Architecture for Describing Simple R., and B. Wijnen, "An
Network Management Protocol (SNMP) Management Architecture for Describing
Frameworks", STD 62, RFC 3411, December 2002. Simple Network Management
Protocol (SNMP) Management
Frameworks", STD 62,
RFC 3411, December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. [RFC3412] Case, J., Harrington, D.,
Wijnen, "Message Processing and Dispatching Presuhn, R., and B. Wijnen,
for the Simple Network Management Protocol "Message Processing and
(SNMP)", STD 62, RFC 3412, December 2002. Dispatching for the Simple
Network Management Protocol
(SNMP)", STD 62, RFC 3412,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based [RFC3414] Blumenthal, U. and B.
Security Model (USM) for version 3 of the Wijnen, "User-based
Simple Network Management Protocol (SNMPv3)", Security Model (USM) for
STD 62, RFC 3414, December 2002. version 3 of the Simple
Network Management Protocol
(SNMPv3)", STD 62,
RFC 3414, December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the [RFC3417] Presuhn, R., "Transport
Simple Network Management Protocol (SNMP)", Mappings for the Simple
STD 62, RFC 3417, December 2002. Network Management Protocol
(SNMP)", STD 62, RFC 3417,
December 2002.
10.2. Informative References 10.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. [RFC2865] Rigney, C., Willens, S.,
Simpson, "Remote Authentication Dial In User Rubens, A., and W. Simpson,
Service (RADIUS)", RFC 2865, June 2000. "Remote Authentication Dial
In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. [RFC3410] Case, J., Mundy, R.,
Stewart, "Introduction and Applicability Partain, D., and B.
Statements for Internet-Standard Management Stewart, "Introduction and
Framework", RFC 3410, December 2002. Applicability Statements
for Internet-Standard
Management Framework",
RFC 3410, December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple [RFC3413] Levi, D., Meyer, P., and B.
Network Management Protocol (SNMP) Stewart, "Simple Network
Applications", STD 62, RFC 3413, Management Protocol (SNMP)
December 2002. Applications", STD 62,
RFC 3413, December 2002.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., [RFC4366] Blake-Wilson, S., Nystrom,
Mikkelsen, J., and T. Wright, "Transport M., Hopwood, D., Mikkelsen,
Layer Security (TLS) Extensions", RFC 4366, J., and T. Wright,
April 2006. "Transport Layer Security
(TLS) Extensions",
RFC 4366, April 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple [RFC4422] Melnikov, A. and K.
Authentication and Security Layer (SASL)", Zeilenga, "Simple
RFC 4422, June 2006. Authentication and Security
Layer (SASL)", RFC 4422,
June 2006.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell [RFC4251] Ylonen, T. and C. Lonvick,
(SSH) Protocol Architecture", RFC 4251, "The Secure Shell (SSH)
January 2006. Protocol Architecture",
RFC 4251, January 2006.
[I-D.ietf-netconf-ssh] Wasserman, M. and T. Goddard, "Using the [RFC4741] Enns, R., "NETCONF
NETCONF Configuration Protocol over Secure Configuration Protocol",
Shell (SSH)", draft-ietf-netconf-ssh-06 (work RFC 4741, December 2006.
in progress), March 2006.
[I-D.ietf-isms-transport-security-model] Harrington, D., "Transport
Security Model for SNMP", d
raft-ietf-isms-transport-
security-model-02 (work in
progress), January 2007.
Appendix A. Parameter Table Appendix A. Parameter Table
Following is a CSV formatted matrix useful for tracking data flows Following is a Comma-separated-values (CSV) formatted matrix useful
into and out of the dispatcher, transport, message, and security for tracking data flows into and out of the dispatcher, Transport,
subsystems. Import this into your favorite spreadsheet or other CSV Message Processing, and Security Subsystems. This will be of most
compatible application. You will need to remove lines feeds from the use to designers of models, to understand what information is
second, third, and fourth lines, which needed to be wrapped to fit available at which points in the processing, following the RFC3411
into RFC limits. architecture (and this subsystem). Import this into your favorite
spreadsheet or other CSV compatible application. You will need to
remove lines feeds from the second, third, and fourth lines, which
needed to be wrapped to fit into RFC line lengths.
A.1. ParameterList.csv A.1. ParameterList.csv
,Dispatcher,,,,Messaging,,,Security,,,Transport, ,Dispatcher,,,,Messaging,,,Security,,,Transport,
,sendPDU,returnResponse,processPDU,processResponse, ,sendPDU,returnResponse,processPDU,processResponse,
prepareOutgoingMessage,prepareResponseMessage,prepareDataElements, prepareOutgoingMessage,prepareResponseMessage,prepareDataElements,
generateRequest,processIncoming,generateResponse, generateRequest,processIncoming,generateResponse,
sendMessage,recvMessage sendMessage,receiveMessage
transportDomain,In,,,,In,,In,,,,,In transportDomain,In,,,,In,,In,,,,,In
transportAddress,In,,,,In,,In,,,,,In transportAddress,In,,,,In,,In,,,,,In
destTransportDomain,,,,,Out,Out,,,,,In, destTransportDomain,,,,,Out,Out,,,,,In,
destTransportAddress,,,,,Out,Out,,,,,In, destTransportAddress,,,,,Out,Out,,,,,In,
messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,, messageProcessingModel,In,In,In,In,In,In,Out,In,In,In,,
skipping to change at page 29, line 35 skipping to change at page 33, line 23
securityStateReference,,,,,,,,,Out,In,, securityStateReference,,,,,,,,,Out,In,,
pduType,,,,,,,Out,,,,, pduType,,,,,,,Out,,,,,
tmStateReference,,,,,Out,Out,In,,In,,In,In tmStateReference,,,,,Out,Out,In,,In,,In,In
Appendix B. Why tmStateReference? Appendix B. Why tmStateReference?
This appendix considers why a cache-based approach was selected for This appendix considers why a cache-based approach was selected for
passing parameters. This section may be removed from subsequent passing parameters.
revisions of the document.
There are four approaches that could be used for passing information There are four approaches that could be used for passing information
between the Transport Model and an Security Model. between the Transport Model and a Security Model.
1. one could define an ASI to supplement the existing ASIs, or 1. one could define an ASI to supplement the existing ASIs, or
2. one could add a header to encapsulate the SNMP message, 2. one could add a header to encapsulate the SNMP message,
3. one could utilize fields already defined in the existing SNMPv3 3. one could utilize fields already defined in the existing SNMPv3
message, or message, or
4. one could pass the information in an implementation-specific 4. one could pass the information in an implementation-specific
cache or via a MIB module. cache or via a MIB module.
B.1. Define an Abstract Service Interface B.1. Define an Abstract Service Interface
Abstract Service Interfaces (ASIs) [RFC3411] are defined by a set of Abstract Service Interfaces (ASIs) are defined by a set of primitives
primitives that specify the services provided and the abstract data that specify the services provided and the abstract data elements
elements that are to be passed when the services are invoked. that are to be passed when the services are invoked. Defining
Defining additional ASIs to pass the security and transport additional ASIs to pass the security and transport information from
information from the transport subsystem to security subsystem has the Transport Subsystem to Security Subsystem has the advantage of
the advantage of being consistent with existing RFC3411/3412 being consistent with existing RFC3411/3412 practice, and helps to
practice, and helps to ensure that any transport model proposals pass ensure that any Transport Model proposals pass the necessary data,
the necessary data, and do not cause side effects by creating model- and do not cause side effects by creating model-specific dependencies
specific dependencies between itself and other models or other between itself and other models or other subsystems other than those
subsystems other than those that are clearly defined by an ASI. that are clearly defined by an ASI.
B.2. Using an Encapsulating Header B.2. Using an Encapsulating Header
A header could encapsulate the SNMP message to pass necessary A header could encapsulate the SNMP message to pass necessary
information from the Transport Model to the dispatcher and then to a information from the Transport Model to the dispatcher and then to a
messaging security model. The message header would be included in Message Processing Model. The message header would be included in
the wholeMessage ASI parameter, and would be removed by a the wholeMessage ASI parameter, and would be removed by a
corresponding messaging model. This would imply the (one and only) corresponding Message Processing Model. This would imply the (one
messaging dispatcher would need to be modified to determine which and only) messaging dispatcher would need to be modified to determine
SNMP message version was involved, and a new message processing model which SNMP message version was involved, and a new Message Processing
would need to be developed that knew how to extract the header from Model would need to be developed that knew how to extract the header
the message and pass it to the Security Model. from the message and pass it to the Security Model.
B.3. Modifying Existing Fields in an SNMP Message B.3. Modifying Existing Fields in an SNMP Message
[RFC3412] describes the SNMPv3 message, which contains fields to pass [RFC3412] defines the SNMPv3 message, which contains fields to pass
security related parameters. The transport subsystem could use these security related parameters. The Transport Subsystem could use these
fields in an SNMPv3 message, or comparable fields in other message fields in an SNMPv3 message, or comparable fields in other message
formats to pass information between transport models in different formats to pass information between Transport Models in different
SNMP engines, and to pass information between a transport model and a SNMP engines, and to pass information between a Transport Model and a
corresponding messaging security model. corresponding Message Processing Model.
If the fields in an incoming SNMPv3 message are changed by the If the fields in an incoming SNMPv3 message are changed by the
Transport Model before passing it to the Security Model, then the Transport Model before passing it to the Security Model, then the
Transport Model will need to decode the ASN.1 message, modify the Transport Model will need to decode the ASN.1 message, modify the
fields, and re-encode the message in ASN.1 before passing the message fields, and re-encode the message in ASN.1 before passing the message
on to the message dispatcher or to the transport layer. This would on to the message dispatcher or to the transport layer. This would
require an intimate knowledge of the message format and message require an intimate knowledge of the message format and message
versions so the Transport Model knew which fields could be modified. versions so the Transport Model knew which fields could be modified.
This would seriously violate the modularity of the architecture. This would seriously violate the modularity of the architecture.
B.4. Using a Cache B.4. Using a Cache
This document describes a cache, into which the Transport Model puts This document describes a cache, into which the Transport Model puts
information about the security applied to an incoming message, and a information about the security applied to an incoming message, and a
Security Model can extract that information from the cache. Given Security Model can extract that information from the cache. Given
that there may be multiple TM-security caches, a tmStateReference is that there might be multiple TM-security caches, a tmStateReference
passed as an extra parameter in the ASIs between the transport is passed as an extra parameter in the ASIs between the Transport
subsystem and the security subsystem, so the Security Model knows Subsystem and the Security Subsystem, so the Security Model knows
which cache of information to consult. which cache of information to consult.
This approach does create dependencies between a specific Transport This approach does create dependencies between a specific Transport
Model and a corresponding specific Security Model. However, the Model and a corresponding specific Security Model. However, the
approach of passing a model-independent reference to a model- approach of passing a model-independent reference to a model-
dependent cache is consistent with the securityStateReference already dependent cache is consistent with the securityStateReference already
being passed around in the RFC3411 ASIs. being passed around in the RFC3411 ASIs.
Appendix C. Open Issues Appendix C. Open Issues
NOTE to RFC editor: If this section is empty, then please remove this
open issues section before publishing this document as an RFC. (If
it is not empty, please send it back to the editor to resolve.
o MUST responses go back on the same session?
o How should we describe the case where a management system wants to
keep session info available for inspection after a session has
closed? see "Abstract Service Interfaces"
o Do Informs work correctly?
o How does a Transport Model know whether a message is a
notification or a request/response?
o cache contents - do we define this?
Appendix D. Change Log Appendix D. Change Log
NOTE to RFC editor: Please remove this change log before publishing NOTE to RFC editor: Please remove this change log before publishing
this document as an RFC. this document as an RFC.
Changes from revision -05- to -06-
mostly editorial changes
removed some paragraphs considered unnecessary
added Updates to header
modified some text to get the security details right
modified text re: ASIs so they are not API-like
cleaned up some diagrams
cleaned up RFC2119 language
added section numbers to citations to RFC3411
removed gun for political correctness
Changes from revision -04- to -05- Changes from revision -04- to -05-
removed all objects from the MIB module. removed all objects from the MIB module.
changed document status to "Standard" rather than the xml2rfc changed document status to "Standard" rather than the xml2rfc
default of informational. default of informational.
changed mention of MD5 to SHA changed mention of MD5 to SHA
moved addressing style to TDomain and TAddress moved addressing style to TDomain and TAddress
modified the diagrams as requested modified the diagrams as requested
removed the "layered stack" diagrams that compared USM and a removed the "layered stack" diagrams that compared USM and a
Transport Model processing Transport Model processing
removed discussion of speculative features that might exist in removed discussion of speculative features that might exist in
future transport models future Transport Models
removed openSession() and closeSession() ASIs, since those are removed openSession and closeSession ASIs, since those are model-
model-dependent dependent
removed the MIB module removed the MIB module
removed the MIB boilerplate into (this memo defines a SMIv2 MIB removed the MIB boilerplate intro (this memo defines a SMIv2 MIB
...) ...)
removed IANA considerations related to the now-gone MIB module removed IANA considerations related to the now-gone MIB module
removed security considerations related to the MIB module removed security considerations related to the MIB module
removed references needed for the MIB module removed references needed for the MIB module
changed recvMessage ASI to use origin transport domain/address changed receiveMessage ASI to use origin transport domain/address
updated Parameter CSV appendix updated Parameter CSV appendix
Changes from revision -03- to -04- Changes from revision -03- to -04-
changed title from Transport Mapping Security Model Architectural changed title from Transport Mapping Security Model Architectural
Extension to Transport Subsystem Extension to Transport Subsystem
modified the abstract and introduction modified the abstract and introduction
changed TMSM to TMS changed TMSM to TMS
changed MPSP to simply Security Model changed MPSP to simply Security Model
changed SMSP to simply Security Model changed SMSP to simply Security Model
changed TMSP to Transport Model changed TMSP to Transport Model
skipping to change at page 32, line 29 skipping to change at page 36, line 42
o changed user auth to client auth o changed user auth to client auth
o changed tmStateReference to tmSessionReference o changed tmStateReference to tmSessionReference
o modified document to meet consensus positions published by JS o modified document to meet consensus positions published by JS
o o
* authoritative is model-specific * authoritative is model-specific
* msgSecurityParameters usage is model-specific * msgSecurityParameters usage is model-specific
* msgFlags vs. securityLevel is model/implementation-specific * msgFlags vs. securityLevel is model/implementation-specific
* notifications must be able to cause creation of a session * notifications must be able to cause creation of a session
* security considerations must be model-specific * security considerations must be model-specific
* TDomain and TAddress are model-specific * TDomain and TAddress are model-specific
* MPSP changed to SMSP (Security model security processing) * MPSP changed to SMSP (Security Model security processing)
Changes from revision -01- to -02- Changes from revision -01- to -02-
o wrote text for session establishment requirements section. o wrote text for session establishment requirements section.
o wrote text for session maintenance requirements section. o wrote text for session maintenance requirements section.
o removed section on relation to SNMPv2-MIB o removed section on relation to SNMPv2-MIB
o updated MIB module to pass smilint o updated MIB module to pass smilint
o Added Structure of the MIB module, and other expected MIB-related o Added Structure of the MIB module, and other expected MIB-related
sections. sections.
o updated author address o updated author address
skipping to change at page 34, line 7 skipping to change at page 39, line 7
International University Bremen International University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
Phone: +49 421 200-3587 Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 163 change blocks. 
697 lines changed or deleted 800 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/