NETCONF Access for Configurations over BEEP

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.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

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.

Prerequisites for NETCONF Access for Configurations over BEEP

NETCONF over BEEP listeners require Simple Authentication and Security layer (SASL) to be configured.

Restrictions for NETCONF Access for Configurations over BEEP

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

NETCONF over BEEP Overview

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.

NETCONF over BEEP and SASL

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.

NETCONF over BEEP and TLS

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.

NETCONF over BEEP and Access Lists

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:

  1. Creating an access list by specifying an access list number or name and access conditions.

  2. 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

Configuring an SASL Profile

To enable NETCONF over BEEP using SASL, you must first configure an SASL profile, which specifies which users are allowed access into the device.

SUMMARY STEPS

  1. enable
  2. configure terminal
  3. sasl profile profile-name
  4. mechanism di gest-md5
  5. server user-name password password
  6. exit

DETAILED STEPS

  Command or Action Purpose
Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

sasl profile profile-name

Example:


Device(config)# sasl profile beep

Configures an SASL profile and enters SASL profile configuration mode.

Step 4

mechanism di gest-md5

Example:


Device(config-SASL-profile)# mechanism digest-md5

Configures the SASL profile mechanism.

Step 5

server user-name password password

Example:


Device(config-SASL-profile)# server user1 password password1

Configures an SASL server.

Step 6

exit

Example:


Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Enabling NETCONF over BEEP

Before you begin

  • 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

  • A minimum of four concurrent NETCONF sessions must be configured.
  • A maximum of 16 concurrent NETCONF sessions can be configured.

SUMMARY STEPS

  1. enable
  2. configure terminal
  3. crypto key generate rsa general-keys
  4. crypto pki trustpoint name
  5. enrollment url url
  6. subject-name name
  7. revocation-check method1 [method2 [method3 ]]
  8. exit
  9. crypto pki authenticate name
  10. crypto pki enroll name
  11. netconf lock-time seconds
  12. line vty line-number [ending-line-number ]
  13. netconf max-sessions session
  14. netconf beep initiator {hostname | ip-address } port-number user sasl-user password sasl-password [encrypt trustpoint ] [reconnect-time seconds ]
  15. netconf beep listener [port-number ] [acl access-list-number ] [sasl sasl-profile ] [encrypt trustpoint ]
  16. exit

DETAILED STEPS

  Command or Action Purpose
Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

crypto key generate rsa general-keys

Example:


Device(config)# crypto key generate rsa general-keys

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:


Device(config)# crypto pki trustpoint my_trustpoint

Declares the trustpoint that your router should use and enters ca-trustpoint configuration mode.

Step 5

enrollment url url

Example:


Device(ca-trustpoint)# enrollment url http://10.2.3.3:80

Specifies the enrollment parameters of a certification authority (CA).

Step 6

subject-name name

Example:


Device(ca-trustpoint)# subject-name CN=dns_name_of_host.com

Specifies the subject name in the certificate request.

Note 

The subject name should be the Domain Name System (DNS) name of the device.

Step 7

revocation-check method1 [method2 [method3 ]]

Example:


Device(ca-trustpoint)# revocation-check none

Checks the revocation status of a certificate.

Step 8

exit

Example:


Device(ca-trustpoint)# exit

Exits ca-trustpoint configuration mode and returns to global configuration mode.

Step 9

crypto pki authenticate name

Example:


Device(config)# crypto pki authenticate my_trustpoint

Authenticates the certification authority (by getting the certificate of the CA).

Step 10

crypto pki enroll name

Example:


Device(config)# crypto pki enroll my_trustpoint

Obtains the certificate or certificates for your router from CA.

Step 11

netconf lock-time seconds

Example:


Device(config)# netconf lock-time 60

(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:


Device(config)# line vty 0 15

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:


Device(config)# netconf max-sessions 16

(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:


Device(config)# netconf beep initiator host1 23 user user1 password password1 encrypt 23 reconnect-time 60

(Optional) Specifies BEEP as the transport protocol for NETCONF sessions and configures a peer as the BEEP initiator.

Note 

Perform this step to configure a NETCONF BEEP initiator session. You can also optionally configure a BEEP listener session.

Step 15

netconf beep listener [port-number ] [acl access-list-number ] [sasl sasl-profile ] [encrypt trustpoint ]

Example:


Device(config)# netconf beep listener 26 acl 101 sasl profile1 encrypt 25

(Optional) Specifies BEEP as the transport protocol for NETCONF and configures a peer as the BEEP listener.

Note 

Perform this step to configure a NETCONF BEEP listener session. You can also optionally configure a BEEP initiator session.

Step 16

exit

Example:


Device(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Configuration Examples for NETCONF Access for Configurations over BEEP

Example: Enabling NETCONF 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

Additional References for NETCONF Access for Configurations over BEEP

Related Documents

Related Topic

Document Title

Cicso IOS Commands

Cisco IOS Master Commands List, All Releases

NETCONF commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples

Cisco IOS Cisco Networking Services Command Reference

Standards and RFCs

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)

Technical Assistance

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.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for NETCONF Access for Configurations over BEEP

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.
Table 1. Feature Information for NETCONF Access for Configurations over BEEP

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 .