Minutes - IETF #40 Washington, D.C.
------------------------------------
WG: DISMAN
Area: OPS
Meetings: 10dec97 1930-2200
12dec97 0900-1130
WG Chair: Randy Presuhn
Minutes: Andy Bierman
Summary
-------
The DISMAN WG met at this meeting to advance the documents in progress.
Most of the meeting time was used addressing difficult security issues.
Many aspects of script and expression configuration and operation
within a secure SNMPv3/VACM environment were discussed, and a great
deal of progress was made in this area.
Agenda
------
1. Administrative issues
1.1 Review of agenda & adjustments
1.2 Mailing List Information
1.3 Charter Updates - yes the revised charter
has been submitted to our area directors.
1.4 Allocation of time for discussions
2. Technical Presentations
none currently scheduled, please let the chair
know in advance so time can be budgeted
3. General Technical Discussion
3.1 Impact of SNMPv3 work
3.1.1 terminology
3.1.2 application types
3.1.3 access control implications
3.2 Framework issues
3.2.1 Do we still need it?
3.2.2 Alignment with SNMPv3 work
3.3 Target MIB
3.3.1 Editor's overview of changes
3.3.2 Alignment with SNMPv3 work
3.4 Script MIB issues
3.4.1 Editor's overview of changes
3.4.2 Alignment with SNMPv3 work
3.4.2.1 Naming
3.4.2.2 Access Control
3.5 Expression evaluation MIB issues
3.5.1 implementation experience
3.5.2 impact of SNMPv3 support
3.6 Notification MIB
3.7 Common issues
3.7.1 integration with other mibs
3.7.2 conformance issues
3.7.3 representing ownership
3.7.4 security considerations
3.7.5 implementability
3.7.6 deployability
3.7.7 internationalization
4. Future work
5. Closing
5.1 Review of action items
5.2 Planning for possible interim meeting
5.3 Discussion of next meeting
Reading Material
----------------
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-event-mib-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-express-mib-02.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-framework-00.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-mgt-target-mib-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notify-mib-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-script-mib-01.txt
1) Technical Presentations
--------------------------
Several of the document authors gave presentations on specific
issues relating to the DISMAN work.
1.1) David Levi -- Trap Forwarding Application
The SNMPv3 framework does not allow a trap receiver
application to receive all information related to a
given trap PDU, particularly the original source address,
if that trap was received via at least one trap forwarder.
The 'ContextSNMPEngineId' (where info came from), doesn't
change from hop to hop, but 'AuthSNMPEngineId' does change
from hop to hop. It is not possible with the Proxy MIB to
determine the original source address.
A proposal was made for proxied traps, to add a varbind
in the trap identifying the original source address.
The WG decided to defer the issue to the SNMPv3 working
group for resolution.
1.2) Bob Stewart -- Expression MIB Implementation Experience
Implementing the Expression MIB is non-trivial. Many people
were involved in the agent implementation effort, which
took approximately 18 person-months to complete.
This implementation experience resulted in many clarifications,
reflected in the latest draft.
Status of the new draft:
* A new object has been added to indicate if an
expression object is identified with a partial OID
(and should be 'wildcard-expanded'), or if the OID is complete
(and should not be 'wildcard-expanded').
* Access control issues need to be resolved. New comments
in the MIB are needed to clarify access control.
* A 'changedElement' expression operator was added. This is
needed to flag a changed object value, which can't be done
with arithmetic operators for all object types (e.g., OID).
Operation of integer deltas does not change.
* The Editor needs to finish the Event MIB to fully support
the Expression MIB.
* A change to the Event MIB was made to use Notifications
to log errors.
* Event MIB error handling needs some clarifications
* Expression MIB needs an overview, and more front-end prose
describing NMS constraints and usage guidelines.
The WG discussed the merits of these changes and the Expression
MIB in general. The use of notifications to flag expression
errors is controversial. It was noted that work on
universal logging is being done in two other working groups.
The new draft will be discussed further on the mailing list.
1.3) Juergen Schoenwaelder -- Security Issues & Terms
Security profiles control configuration and execution access
to scripts and expressions, and a script needs to be restricted
to specific services on the runtime system.
The security profile of the script installer (script owner)
is used to specify who can run the script and which 'execution
security profiles' may be used (by which users) to execute the
script. The installer profile may be different than the
execution profile.
The VACM MIB is used to control configuration and execution access.
The WG agreed that a description of how to use VACM to secure a
DISMAN system should be added to the document.
A unix-like "SETUID" capability is needed to allow a third party to
start a script, running under security profile of the script owner,
not the script invoker. During the course of the meetings, a great
deal of discussion focused on the security details of many such
configuration and execution scenarios.
The DISMAN MIB(s) should not assume that a particular security model
is used, which means the security profile information must be
available in the MIB(s).
The WG should establish guidelines for configuring user names,
and a 'mapping table' indicating context name to local user/group
name on the execution target. Mappings for 'owner-to-local-user'
and 'invoker-to-local-user' are needed.
1.4) Steve Waldbusser -- Framework Terminology Issues
A distributed system can be modeled as three logical components:
+-----------+ +----------------+ +------------------+
| |+ disman | |+ target | |+
| Higher || user | Distributed || user | Target Agent ||
| Layer || ------> | Manager || ------> | or Network Host ||
| Mgmt || | [users] || | [users] ||
| App || | [scripts/exprs]|| | [scripts/exprs] ||
| || ++---------------+| | [managed system] ||
++----------+| +----------------+ ++-----------------+|
+-----------+ +------------------+
Each of these logical components can be physically located on the same
machine or different machines.
The "disman user" and "target user" are identified by more than a user ID:
- disman user: SNMP Security Model, Security Name & Key;
allowed to install and manage disman functionality on specific
distributed managers
- target user: SNMP Security Model, Security Name & Key;
allowed to invoke specific DISMAN functions on specific targets
Tokens are used to describe all necessary information needed to
perform particular operations on behalf of the disman user.
SNMPv3 makes it clear what these objects are;
- securityModel
- securityName;
- set of targets;
- set of access rights for those targets
There may be a set of tokens per target user of each script
or expression. Invocation properties of a script or expression
must be attached to the invocation button, not the configuration
of the control rows.
A script installer may wish to limit the set of tokens that
a particular script invoker may use (for that script)
Token subsets are constant subsets, and to create a different
set of credentials, new tokens must be created.
To utilize a DISMAN system, first a disman user configures
a Distributed Manager by installing some scripts, some
user names, some security tokens, and then associating
scripts to tokens, based on the functional requirements
of the script, and the profile of each target user.
Remaining Issues:
a) After a script is configured, a Script Invoker
can start the script running. Is the 'Script Invocation
Identity' the ID of the owner or the invoker?
b) The Expression MIB has notion of invoker and owner as well.
The WG needs to develop one VACM-based DISMAN security
architecture. What changes to the various MIBs are needed?
c) There may be several tokens available per user per script.
How do you tell which tokens to use? Care should be taken
to avoid an explosion of configuration rows needed on each
Distributed Manager (e.g., one token per target-user,
per target, per target-context, per target-MIB-view).
d) What if User A installs a script; user B wants to reuse the
script with his/her own tokens? Should this be supported?
e) How do you tell which tokens are used, if different values
of contextName are needed to access a given MIB object on
a target system?
f) How should the combinations of credentials be supported?
- owner
- subset of owner
- invoker
- union of owner and invoker
1.5) David Levi & Juergen Schoenwaelder -- Session Control
The Script MIB needs to support some forms of script scheduling:
one-shot -- invoked once when 'invoke button' is pressed
periodically -- like unix 'cron' command
time-of-day -- like unix 'at' command
A new table to support the time-based scheduling will be added
to the Script MIB.
The WG decided not to support script invocation based on
reception of an SNMP notification. Instead, a script
may listen for notifications in a platform-specific,
proprietary way. It is likely that only one script will
be able to listen for notifications on some platforms.
This issue may be addressed in a future version of the
Framework document.
2) Issues List Follow-up
------------------------
After all presentations, the WG Chair led a discussion of
issues related to all documents in progress. The topics
were ordered, based on complexity:
- Quick List (2.1 .. 2.10)
- Tough List (2.11 .. 2.17)
2.1) Framework draft
The Framework draft has expired and needs to be updated.
Action Item (Steve Waldbusser): Align terms in FW draft with
the new terminology tentatively accepted by the WG. Add
detailed example of configuring VACM and the script MIB to
maintain security and usefulness.
2.2) UTF-8
The WG should examine all strings for proper application of
UTF-8 based strings. It should be used for true internationalization,
not localization, since many options make communication more difficult,
not easier.
2.3) Event MIB Terminology
The terminology in the Event MIB (and possibly the Expression MIB) needs
to be aligned with the (new) terminology in the Framework draft.
2.4) Script Return Status Codes
The script return codes are defined with inline syntax, as opposed
to the use of a textual convention to identify the status codes.
This should be declared as a TC only if it is appropriate
to ever export them for use in another MIB module. Since this
is likely to occur in the long-term, due to the augmentation
of the Script MIB, it may be better to move the return code
definitions to a TC definition now.
2.5) Script Download Compliance
The Script MIB compliance statements need to be refined to allow:
- 'push' downloading of scripts (via SNMP) is optional
- 'pull' downloading of scripts (via URL) is optional to support
a special class of disman agent with only pre-defined read-only
scripts
2.6) Suspend/Resume Commands
Should the Script MIB support suspend/resume 'script states', and
therefore allow (or require) a script to support these commands?
This issue was hotly debated, and WG consensus for this feature has
not yet been established.
It was noted that these commands require 'signals' between the
DISMAN platform and a running instance of a script, and that the
suspend and resume signals are just two on a list of possible
signals that a user may wish to send to a running script instance.
A DISMAN implementation must send such signals to scripts
in a platform-specific way.
If a script to chooses to suspend or optionally ignore the
signal, how does an NMS know the suspend command worked or not?
The response to the SetPDU will probably indicate success, even if
the script instance actually ignored the signal.
2.7) SmCodeTable Line Numbers
Should the smCodeTable allow non-contiguous line numbers during
a sequence of smCodeTable SetPDU, i.e., script line insertions.
Resolution -- relax the rule requiring line numbers to be
contiguous, but do not allow the insertion of lines, i.e.
smCodeTable insertions must be in ascending order in successive
SetPDUs.
2.8) Process IDs (PIDs)
A unique invocation identifier is needed for each instance of
all scripts, regardless of running state.
The DISMAN platform should provide an automatic PID generator,
i.e., the NMS must not be involved in the PID generation,
but the PID value should be available via the Script MIB.
The agent should allow smLaunchStart to be set to zero, which
indicated that the system assigns the PID. [ed. - open issue:
does this mean the agent has to support NMS PID generation,
or is it optional, or completely disallowed?]
2.9) smLanguageIndex
Should the smLanguageIndex be a table column instead of an
INDEX component, and allowed to be zero?
[ed. - It's not clear which tables are affected by this change;
could be the smScriptEntry, smCodeEntry, smExecEntry, and
smRunEntry.
The WG agreed that the script language should be indicated in
a column rather than an INDEX. If the column value equals
zero, then a hardcoded script language is implied and there
is no need to specify it. This feature was debated, since
the default language must be specified in the smLanguageTable
anyway. Allowing the value zero means that another MIB object
will be required to indicate the mapping between the default (0),
and some language in the smLanguageTable. It's better to
conserve MIB objects and make the language identifier
reference a real smLanguageTable entry.
This issue will be discussed further on the mailing list.
2.10) Deferment of NV-Storage
A feature will be added to the Script MIB, to allow an agent
implementation to defer NV storage of a script until all the
code lines are downloaded. This will be dome by adding an
editing state to the scriptStatus. This feature also allows
the agent to determine the actual NV-storage size, instead
of wasting resources writing partial scripts to NV-storage.
2.11) Script Results
Can the valueTable in the Expression MIB be used to make script
results visible? This MIB uses a discriminated union of MIB object
results instead of a string result.
This issue will be discussed further on the mailing list.
2.12) Logging MIB Status
Should these features be developed or dropped from the first release
of DISMAN documents:
- error logging feature
- notification log
This issue will be discussed further on the mailing list.
[ed. - end of day 1; start day 2]
2.14) Naming Scope
A suggestion was made to use naming scope to isolate each user of the
scripting capability, instead of providing a multitude of launchpad
buttons for each script. There were objections to this approach,
based on available tools and experience (e.g., RepeaterID).
Resolution: The namingScope (contextName) will not be used to
isolate each user's view of the Script MIB or Expression MIB.
2.15 Script MIB Discussion
The WG discussed the MIB structures required to implement the
desired script/expression VACM-based access control/security
features. The following is a summary of the MIB components:
* table of scripts
- INDEX script-id, scriptOwner
- script.*.owner -> r/w (for group of owner)
* launch pads
- many buttons to the same script allowed
- launch.*.owner -> r/w (for group of owner)
- launch.start-button.owner -> r/w (for some others) [optional]
* smRunTable
- one per running script
- run.*.owner -> r/w for that owner
- run.*.owner -> r/w for others (optional)
(also applies to tokens : token.*.owner)
* tokens
- associated with the launch pad, not the script
- INDEX - owner, launchpadId, tokenInstanceId
- tokens used on individual targets
- script to launchpad mapping must be restricted to the
same group
- public-launchpad:
issue is restricting the tokens used with the script instance
- combining privileges
needed to save rows?
combining privileges may produce security holes & unexpected
privileges; already behind schedule 9 months, perhaps add
this in a later release.
* mapping: owner --> 'local tokens'
- needed to execute local operations
- mapping:
owner --> local tokens
SecurityLevel
SecurityName
For expressions, this recorded at row-create-time, i.e.,
whoever activates the row that evaluates the expression.
* tokenTable
- MIB objects:
INDEX [tokenOwner, tokenIndex];
tokenOwner string
tokenIndex int
tokenSecurityName string
tokenSecurityLevel int
tokenSecurityModel int
tokenSecurityKey string
- used to limit the list of target systems
- why do we need this?
don't have a way to delegate write access to the SNMPv3
targetTable (targetTable == an access right on a given system).
- can the SNMPv3 targetTable be used instead of a DISMAN token
table? V3 needed for trap destinations;
Issues raised:
- Does the requirements for proxy cover the requirements of DISMAN?
- Does admin for proxy cover the admin requirements of DISMAN?
- Resolution: use the SNMPv3 target tables; use the tags feature
to subset the target list.
2.16) Expression MIB
To support the VACM-based DISMAN security features, the expression owner
needs to be part of the expression index. The details of this
change were not explored, but this discussion will continue
on the mailing list.
2.17) Document Complexity
There was concern expressed about the complexity of the DISMAN
technology, and conveying that complexity to users in the documents.
More examples are needed, starting with simple applications
and then introducing more complex applications.
The Expression MIB needs examples written which show how the main
features are used, with both simple and complex expressions.
3) Conclusions
3.1) Action Items
* The deferred issues (mentioned throughout the minutes)
will be discussed on the mailing list.
* The DISMAN drafts will be updated to reflect the changes
agreed upon at this meeting.
* The (currently expired) Framework document will be resubmitted.
3.2) Interim Meeting
A possible interim meeting was discussed again. Location was not
an issue, but the proposed locations are all in the USA:
- San Jose, CA
- Chicago, IL
- Houston, TX
There is not strong interest in an interim meeting at this time.
Many principal members of the working group met twice before the
IETF meeting to discuss the documents in detail. This interim
meeting approach may be repeated again before the next IETF meeting
in Los Angeles, CA.