Prerequisites for NETCONF Access for Configurations over BEEP
NETCONF over BEEP listeners require Simple Authentication and Security layer (SASL) to be configured.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
You can use the Network Configuration Protocol (NETCONF) over Blocks Extensible Exchange Protocol (BEEP) feature to send notifications of any configuration change over NETCONF. A notification is an event indicating that a configuration change has happened. The change can be a new configuration, deleted configuration, or changed configuration. The notifications are sent at the end of a successful configuration operation as one message showing the set of changes, rather than individual messages for each line in the configuration that is changed.
BEEP can use the Simple Authentication and Security Layer (SASL) profile to provide simple and direct mapping to the existing security model. Alternatively, NETCONF over BEEP can use the transport layer security (TLS) to provide a strong encryption mechanism with either server authentication or server and client-side authentication.
NETCONF over BEEP listeners require Simple Authentication and Security layer (SASL) to be configured.
You must be running a crypto image in order to configure BEEP using transport layer security (TLS).
Information About NETCONF Access for Configurations over BEEP
The NETCONF Access for Configurations over BEEP feature allows you to enable BEEP as the transport protocol to use during NETCONF sessions. Using NETCONF over BEEP, you can configure either the NETCONF server or the NETCONF client to initiate a connection, thus supporting large networks of intermittently connected devices, and those devices that must reverse the management connection where there are firewalls and Network Address Translators (NATs).
BEEP is a generic application protocol framework for connection-oriented, asynchronous interactions. It is intended to provide the features that traditionally have been duplicated in various protocol implementations. BEEP typically runs on top of Transmission Control Protocol (TCP) and allows the exchange of messages. Unlike HTTP and similar protocols, either end of the connection can send a message at any time. BEEP also includes facilities for encryption and authentication and is highly extensible.
The BEEP protocol contains a framing mechanism that permits simultaneous and independent exchanges of messages between peers. These messages are usually structured using XML. All exchanges occur in the context of a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. This binding forms a channel; each channel has an associated profile that defines the syntax and semantics of the messages exchanged.
The BEEP session is mapped onto the NETCONF service. When a session is established, each BEEP peer advertises the profiles it supports. During the creation of a channel, the client (the BEEP initiator) supplies one or more proposed profiles for that channel. If the server (the BEEP listener) creates the channel, it selects one of the profiles and sends it in a reply. The server may also indicate that none of the profiles are acceptable, and decline creation of the channel.
BEEP allows multiple data exchange channels to be simultaneously in use.
Although BEEP is a peer-to-peer protocol, each peer is labeled according to the role it is performing at a given time. When a BEEP session is established, the peer that awaits new connections is the BEEP listener. The other peer, which establishes a connection to the listener, is the BEEP initiator. The BEEP peer that starts an exchange is the client, and the other BEEP peer is the server. Typically, a BEEP peer that acts in the server role also performs in the listening role. However, because BEEP is a peer-to-peer protocol, the BEEP peer that acts in the server role is not required to also perform in the listening role.
The SASL is an Internet standard method for adding authentication support to connection-based protocols. SASL can be used between a security appliance and an Lightweight Directory Access Protocol (LDAP) server to secure user authentication.
BEEP listeners require SASL to be configured.
The TLS is an application-level protocol that provides for secure communication between a client and server by allowing mutual authentication, the use of hash for integrity, and encryption for privacy. TLS relies upon certificates, public keys, and private keys.
Certificates are similar to digital ID cards. They prove the identity of the server to clients. Each certificate includes the name of the authority that issued it, the name of the entity to which the certificate was issued, the entity’s public key, and time stamps that indicate the certificate’s expiration date.
Public and private keys are the ciphers used to encrypt and decrypt information. Although the public key is shared, the private key is never given out. Each public-private key pair works together. Data encrypted with the public key can be decrypted only with the private key.
You can optionally configure access lists for use with NETCONF over SSHv2 sessions. An access list is a sequential collection of permit and deny conditions that apply to IP addresses. The Cisco software tests addresses against the conditions in an access list one by one. The first match determines whether the software accepts or rejects the address. Because the software stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the software rejects the address.
The two main tasks involved in using access lists are as follows:
Creating an access list by specifying an access list number or name and access conditions.
Applying the access list to interfaces or terminal lines.
For more information about configuring access lists, see “IP Access List Overview” and “Creating an IP Access List and Applying It to an Interface” modules in Security Configuration Guide: Securing the Data Plane.
How to Configure NETCONF Access for Configurations over BEEP
To enable NETCONF over BEEP using SASL, you must first configure an SASL profile, which specifies which users are allowed access into the device.
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
Step 3 |
sasl profile profile-name Example:
|
Configures an SASL profile and enters SASL profile configuration mode. |
Step 4 |
mechanism di gest-md5 Example:
|
Configures the SASL profile mechanism. |
Step 5 |
server user-name password password Example:
|
Configures an SASL server. |
Step 6 |
exit Example:
|
Exits global configuration mode and returns to privileged EXEC mode. |
There must be at least as many vty lines configured as there are concurrent NETCONF sessions.
If you configure NETCONF over BEEP using SASL, you must first configure an SASL profile.
![]() Note |
|
Command or Action | Purpose | |||
---|---|---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
||
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
||
Step 3 |
crypto key generate rsa general-keys Example:
|
Generates Rivest, Shamir, and Adelman (RSA) key pairs and specifies that the general-purpose key pair should be generated. Perform this step only once. |
||
Step 4 |
crypto pki trustpoint name Example:
|
Declares the trustpoint that your router should use and enters ca-trustpoint configuration mode. |
||
Step 5 |
enrollment url url Example:
|
Specifies the enrollment parameters of a certification authority (CA). |
||
Step 6 |
subject-name name Example:
|
Specifies the subject name in the certificate request.
|
||
Step 7 |
revocation-check method1 [method2 [method3 ]] Example:
|
Checks the revocation status of a certificate. |
||
Step 8 |
exit Example:
|
Exits ca-trustpoint configuration mode and returns to global configuration mode. |
||
Step 9 |
crypto pki authenticate name Example:
|
Authenticates the certification authority (by getting the certificate of the CA). |
||
Step 10 |
crypto pki enroll name Example:
|
Obtains the certificate or certificates for your router from CA. |
||
Step 11 |
netconf lock-time seconds Example:
|
(Optional) Specifies the maximum time a NETCONF configuration lock is in place without an intermediate operation. The valid value range for the seconds argument is 1 to 300 seconds. The default value is 10 seconds. |
||
Step 12 |
line vty line-number [ending-line-number ] Example:
|
Identifies a specific virtual terminal line for remote console access. You must configure the same number of vty lines as maximum NETCONF sessions. |
||
Step 13 |
netconf max-sessions session Example:
|
(Optional) Specifies the maximum number of concurrent NETCONF sessions allowed. |
||
Step 14 |
netconf beep initiator {hostname | ip-address } port-number user sasl-user password sasl-password [encrypt trustpoint ] [reconnect-time seconds ] Example:
|
(Optional) Specifies BEEP as the transport protocol for NETCONF sessions and configures a peer as the BEEP initiator.
|
||
Step 15 |
netconf beep listener [port-number ] [acl access-list-number ] [sasl sasl-profile ] [encrypt trustpoint ] Example:
|
(Optional) Specifies BEEP as the transport protocol for NETCONF and configures a peer as the BEEP listener.
|
||
Step 16 |
exit Example:
|
Exits global configuration mode and returns to privileged EXEC mode. |
Configuration Examples for NETCONF Access for Configurations over BEEP
Device# configure terminal
Device(config)# crypto key generate rsa general-keys
Device(ca-trustpoint)# crypto pki trustpoint my_trustpoint
Device(ca-trustpoint)# enrollment url http://10.2.3.3:80
Device(ca-trustpoint)# subject-name CN=dns_name_of_host.com
Device(ca-trustpoint)# revocation-check none
Device(ca-trustpoint)# crypto pki authenticate my_trustpoint
Device(ca-trustpoint)# crypto pki enroll my_trustpoint
Device(ca-trustpoint)# line vty 0 15
Device(ca-trustpoint)# exit
Device(config)# netconf lock-time 60
Device(config)# netconf max-sessions 16
Device(config)# netconf beep initiator host1 23 user my_user password my_password encrypt my_trustpoint reconnect-time 60
Device(config)# netconf beep listener 23 sasl user1 encrypt my_trustpoint
Related Topic |
Document Title |
---|---|
Cicso IOS Commands |
|
NETCONF commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples |
Cisco IOS Cisco Networking Services Command Reference |
Standard/RFC |
Title |
---|---|
RFC 2222 |
Simple Authentication and Security Layer (SASL) |
RFC 3080 |
The Blocks Extensible Exchange Protocol Core |
RFC 4741 |
NETCONF Configuration Protocol |
RFC 4744 |
Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) |
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature Name |
Releases |
Feature Information |
---|---|---|
NETCONF Access for Configurations over BEEP |
Cisco IOS XE Release 2.1 12.2(33)SB 12.2(33)SRB 12.2(33)SXI 12.4(9)T |
The NETCONF over BEEP feature allows you to enable either the NETCONF server or the NETCONF client to initiate a connection, thus supporting large networks of intermittently connected devices and those devices that must reverse the management connection where there are firewalls and network address translators (NATs). The following commands were introduced or modified by this feature: netconf beep initiator , netconf beep listener . |