draft-ietf-netconf-beep-09.txt   draft-ietf-netconf-beep-10.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: September 4, 2006 K. Crozier Expires: September 7, 2006 K. Crozier
March 3, 2006 March 6, 2006
Using the NETCONF Protocol over Blocks Extensible Exchange Protocol Using the NETCONF Protocol over Blocks Extensible Exchange Protocol
(BEEP) (BEEP)
draft-ietf-netconf-beep-09 draft-ietf-netconf-beep-10
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 35
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 September 4, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies an application protocol mapping for the This document specifies an application protocol mapping for the
NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4
2.1. NETCONF Session Establishment . . . . . . . . . . . . . . 4 2.1. NETCONF Session Establishment . . . . . . . . . . . . . . 4
2.2. Starting a Channel for NETCONF . . . . . . . . . . . . . . 5 2.2. Starting a Channel for NETCONF . . . . . . . . . . . . . . 5
2.3. NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6 2.3. NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6
2.4. NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6 2.4. NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6
2.5. BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 7 2.5. BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The NETCONF protocol [1] defines a simple mechanism through which a The NETCONF protocol [1] defines a simple mechanism through which a
network device can be managed. NETCONF is designed to be usable over network device can be managed. NETCONF is designed to be usable over
a variety of application protocols. This document specifies an a variety of application protocols. This document specifies an
application protocol mapping for NETCONF over the Blocks Extensible application protocol mapping for NETCONF over the Blocks Extensible
Exchange Protocol (BEEP) [7] . Exchange Protocol (BEEP) [7] .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 20 skipping to change at page 8, line 20
Configuration information often times contains passwords, user names, Configuration information often times contains passwords, user names,
service descriptions, and topological information, all of which are service descriptions, and topological information, all of which are
sensitive. A NETCONF application protocol, therefore, must minimally sensitive. A NETCONF application protocol, therefore, must minimally
support options for both confidentiality and authentication. support options for both confidentiality and authentication.
The BEEP mapping described in this document addresses both The BEEP mapping described in this document addresses both
confidentiality and authentication in a flexible manner through the confidentiality and authentication in a flexible manner through the
use of TLS and SASL profiles. Confidentiality is provided via the use of TLS and SASL profiles. Confidentiality is provided via the
TLS profile, and is used as discussed above. In addition, the server TLS profile, and is used as discussed above. In addition, the server
certificate shall serve as the server's authentication to the client. certificate shall serve as the server's authentication to the client.
The client MUST be prepared to recognize a valid server certificate. The client MUST be prepared to recognize and validate a server
While distribution of such certificates is beyond the scope of this certificate, and SHOULD by default reject invalid certificates.
document, the implementor is cautioned to be aware of any
interdependencies that may be placed on the network infrastructure In order to validate a certificate the client must be able to access
through the use of protocols that validate trust anchors. a trust anchor. While such validation methods are beyond the scope
of this document, they will depend on the type of device and
circumstance. Both the implementor and the administrator are
cautioned to be aware of any circular dependencies various methods
may introduce. For instance, OCSP servers may not be available in a
network cold start scenario, and would be ill advised for core
routers to depend on to receive configuration at boot.
For client-side authentication there are several options. The client For client-side authentication there are several options. The client
MAY provide a certificate during the initiation phase of TLS, in MAY provide a certificate during the initiation phase of TLS, in
which case the subject of that certificate shall be considered which case the subject of that certificate shall be considered
principle for authentication purposes. Once again, server principle for authentication purposes. Once again, server
implementors should be aware of any interdependencies that could be implementors should be aware of any interdependencies that could be
created through protocols used to validate trust anchors. created through protocols used to validate trust anchors.
TLS endpoints may be authorized based on subject name or certificate
authority (CA), depending on circumstances. For instance, it would
be unwise for a core internet router to allow a netconf agent
connection simply based on a valid certificate signed by a common CA,
but not unreasonable to allow a connection from an agent with a
particular distinguished name. On the other hand, it might be
desirable for enterprises to trust certificates signed by CAs of
their network operations team.
In the case where the client has not authenticated through TLS, the In the case where the client has not authenticated through TLS, the
server SHOULD advertise one or more SASL profiles, from which the server SHOULD advertise one or more SASL profiles, from which the
client will choose. In the singular case where TLS is established client will choose. In the singular case where TLS is established
the minimum profile MAY be PLAIN. Otherwise, implementations MUST the minimum profile MAY be PLAIN. Otherwise, implementations MUST
support the DIGEST-MD5 profile as described in [6], and they MAY support the DIGEST-MD5 profile as described in [6], and they MAY
support other profiles such as OTP.[10] support other profiles such as OTP.[10]
Different environments may well allow different rights prior to and Different environments may well allow different rights prior to and
then after authentication. An authorization model is not specified then after authentication. An authorization model is not specified
in this document. When an operation is not properly authorized then in this document. When an operation is not properly authorized then
 End of changes. 6 change blocks. 
17 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/