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:
-
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.
Feedback