Last Modified: 2004-05-26
Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanims or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses.
The Netconf Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics:
- Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications
The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures.
The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the Netconf protocol, such as:
- identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines
It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s).
The initial work will be restricted to the following items:
- Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements.
- Netconf over
The working group will take the XMLCONF Configuration Protocol
Goals and Milestones:
Done Working Group formed Done Submit initial Netconf Protocol draft Done Submit initial Netconf over (transport-TBD) draft Dec 03 Begin Working Group Last Call for the Netconf Protocol draft Jan 04 Begin Working Group Last Call for the Netconf over
(transport-TBD) draft Mar 04 Submit final version of the Netconf Protocol draft to the IESG Apr 04 Submit final version of the Netconf over (transport-TBD) draft
to the IESG Internet-Drafts:
No Request For Comments
Current Meeting Report
OPS Area
NETCONF WG Meeting Minutes
IETF #60
August 5, 2004
Minutes by Sharon Chisholm, Eliot Lear, and Andy Bierman
Chairs
------
Andy Bierman <abierman@cisco.com>
Simon Leinen <simon@switch.ch>
Review Material
---------------
NETCONF Configuration Protocol
<draft-ietf-netconf-prot-03.txt>
BEEP Application Protocol Mapping for NETCONF
<draft-ietf-netconf-beep-01.txt>
NETCONF Over SOAP
<draft-ietf-netconf-soap-02.txt>
Using the NETCONF Configuration Protocol over Secure Shell (SSH)
<draft-ietf-netconf-ssh-01.txt>
Agenda
------
- Report on NETMOD BOF (Sharon Chisholm, 15 min)
- Security Issues (Wes Hardaker, 15 min)
- Discussion of WG Documents (50 min)
- Next Steps (10 min)
Minutes
-------
0) Agenda bashing
There was some minor agenda bashing, and as a result, the Security Issues discussion was held first.
1) Netconf Protocol: Security Considerations
Wes Hardaker presented some issues related to authentication and access control. Refer to the slides and the jabber logs for more details.
1.1) Access Control Requirements
There is language in the protocol document that implies (or requires) that the access control must be the same for CLI and NETCONF. The Editor needs to clarify the relevant text. The WG must decide how strong a requirement is needed (MUST be the same, SHOULD be the same, MUST be mappable, etc.,).
1.2) Global Locking
A lesser-privileged user can obtain a lock and hold it, which can be a denial-of-service attack against higher-priveleged users. The WG has already discussed this issue in the past and decided that partial locking requires canonical object and instance naming across all access modes (SNMP, CLI, etc.), and this is an issue the NETMOD WG should address.
1.3) Netconf Protocol Chaining
Some NETCONF protocol operations work on remote datasets (e.g., copy-config and URL based edit-config). This is not a new issue, but the Editors need to make sure acceptable protocol type values (e.g., ftp, http) for URL based operations are documented in the Security Considerations section.
1.4) Exposure Through Error Messages
There is a concern that error messages produced for operations such as <validate> should not expose any configuration details for portions of the data model that the user invoking the operation does not have access rights to view.
1.5) NETCONF Usage Proposal
There was a proposal that "Netconf 1.0 MUST NOT be used in restricted-role environments". The WG did not agree to this proposal. Security considerations should explain the potential risks for various types of usage. Granular locking will be considered in the future.
2) NETMOD BOF Report
Sharon Chisholm presented a summary of the NETCONF Data Modelling BOF (NETMOD). Refer to the slides and the jabber logs for more details.
NETMOD web page is http://standards.nortelnetworks.com/netconf Mailing list is netconfmodel@lyris.nortelnetworks.com to subscribe, lyris@lists.nortelnetworks.com
The NETCONF WG is not chartered to standardize a data modelling language or domain-specific data models. The proposed NETMOD WG charter would address this "content" layer. Some of the issues in the problem statement:
- what are common ways of specifying compliance?
- backwards compatibility
- how do we deal with access control?
- how do we describe relationships?
The NETMOD WG will look at W3C XML schema
two initial drafts
one is SMI for NETCONF
some sort of meta model or abstract data model will drive
There were four presentations and lots of discussion at the NETMOD BOF. Refer to the proceedings for details. There is strong interest in leveraging existing technologies, but not so much agreement on which technologies. Some evaluation needs to be done in this area. The group refined the proposed charter text and also discussed the need for volunteers in various areas of expertise. People interested in participating should contact Sharon Chisholm (see NETMOD WEB page above).
There is some potential impact on the NETCONF protocol document, related to the NETMOD work:
- Removal of Section 7 of the protocol draft (move the XML usage restrictions into another place)
- syntactic naming and identification
- move netconf-state data model to a different document To put this stuff in the protocol draft would be presumptuous, but would otherwise delay the protocol
The WG needs to decide what changes to make to the protocol draft related to the proposed NETMOD work. It is proposed that these sections are not removed. Instead, a warning in each section will be added to explain that a NETCONF data modelling standard document is expected to supercede this text at some time in the future.
3) Protocol Document Open Issues
Andy Bierman presented a list of open issues with the NETCONF protocol document. Refer to the slides and the jabber logs for more details.
3.1) Retrieval filtering
The group discussed the need for a mandatory-to-implement retrieval filtering mechanism. The WG is considering either "subtree filtering" (currently in the protocol specification examples) and "Xpath subset" (currently in an email proposal). The operator requirements document requires the ability to manage both full and partial configuration files, so some choice has to be made.
The group discussed the pros and cons of each approach (again), and then made some decisions:
- full (but optional) implementation of Xpath will be supported in NETCONF, indicated by the #xpath capability
- the "subtree filtering" will be the mandatory-to-implement retrieval filtering mechanism (show of hands: none - 0; subtree 18 - 20; XPATH subset 4)
3.2) Rollback
The WG agreed to address rollback and retrieval filtering at IETF 59. There is a need to sometimes undo edits or commits to the running configuration. The email proposal from Andy Bierman was explained (see slides for details) and discussed by the group.
The rollback proposal includes an optional "per session ring buffer", although each private snapshot (ring buffer entry) is a copy of the entire <running> configuration. The <rollback> operation restores the entire <running> configuration to previous state. This is not a per-session restore operation.
The group discussed issues related to locking, shared databases, transactions, access control, error reporting, and feature complexity. Afterwards, some decisions were made:
- The rollback feature will not be added to the protocol document (show of hands: yes - 10; no - 6; No consensus to change the document - leave it out)
- The issue will go back to the WG mailing list for new proposals. (However, time is running out on additions; the document updates will not be held up for this feature.)
3.3) Default Edit Operation
The protocol draft does not properly support scoped edit-config operations, because "merge" is always the default edit operation. The possible values for a default operation are "merge", "none", and "replace".
Sometimes the default operation needs to be "none":
- modify a node in the data model without touching any of its ancestors
- tells the agent that I better find an exact match or this operation should fail
Sometimes the default operation needs to be "replace":
- useful for loading previously saved configuration data as an opaque XML block
The email proposal from Andy Bierman was discussed (see slides for details). This includes a new parameter for the <edit-config> operation that specifies the default operation in the event the "operation" attribute is not present within a data model element. The group then made some decisions:
- the <edit-config> operation will be changed to support a user-specified default operation
- the new <edit-config> parameter will be called "operation"
- the document needs to be clarified to indicate exactly how the default operation is applied to the <config> parameter, and how the "operation" attribute within a data model element overrides the default operation.
3.4) Default Configuration Target
The XSD does not support different default values, depending on the presence of the #candidate capability. Therefore, instead of <running> as a default value, affected operations (e.g., <lock>) should have no default specified. There were no objections to this change.
4) Application Mapping Documents: Open Issues
Andy Bierman presented a list of open issues with the application mapping documents. Refer to the slides and the jabber logs for more details.
4.1) General Issues
The titles of the application mapping documents need to be more consistent. The authors will work out the details between themselves and propose new document titles (2 of the 3 will need to change). The new document titles will be proposed to the WG. Also, all acronyms need to be spelled out in the titles (e.g., SOAP).
4.2) NETCONF over SOAP
There is concern that this document is too HTTP-centric. The intent is that the document define how NETCONF maps to SOAP, and different SOAP documents define how SOAP maps to the substrate protocol (e.g., HTTP, BEEP). There is interest is running NETCONF over SOAP over BEEP, which is not directly supported by the NETCONF over SOAP document.
The WG discussed these issues and made some decisions:
- The document should be made as SOAP-generic as possible
- SOAP over BEEP should be supported
- Any HTTP or BEEP specific text should be identified and put in separate sections
5) Next Steps
The authors have been asked to produce "final updates" as soon as possible (2 week deadline already past!). After these documents are posted, WG Last Calls can begin.
Slides
Agenda
Netconf Protocol: Security Considerations
Netmod BOF Report