Chapter 13. Monitoring IPsec VPNs
Introduction to Monitoring
Configuring IPsec VPNs can be seen by some as a cumbersome process. In many instances, once an IPsec VPN is configured it is monitored by the IP connectivity that runs within the overlay network, protected by the VPN. This isn’t the only method to determine if the VPN has been successfully created and is working correctly. This chapter describes the method to monitor each process that is performed when establishing an IPsec Security Association using IKEv2. This chapter is structured so that the method used to monitor each function that is used to establish an IPsec session is described in an ordered fashion. Each function builds on the previous one; for example, IP connectivity must exist between the source and destination of each peer before the IKE exchange can occur.
When the IPsec architecture is monitored, the overall process can be separated into control-plane and data-plane processes. The control-plane processes are used to establish and build the IPsec Security Association. Data-plane monitoring is used to gain insight into the traffic and services that passes over the IPsec Security Association.
The telemetry that is generated by Cisco IOS can be viewed locally in the case of syslog or local NetFlow statistics. For the majority of enterprise architectures, a Security Information Event Management (SIEM) system is used to correlate logging and monitoring information to determine security related events. This chapter will describe how to generate this telemetry but not how to operate a SIEM.
The following protocols are used in the monitoring of IPsec VPNs.
Authentication. Authentication identifies users; its mechanisms include login and password dialog, challenge and response, messaging support, and, depending on the security protocol that you select, encryption.
In the context of IKEv2, authentication is the service that verifies the identity of the user or device within the IKE_AUTH exchange. Authentication is based on the IKE ID and PSK or certificate, or EAP identity and authentication method (password/certificate). AAA on Cisco IOS devices allows you to perform local authentication (using the local lookup database) or remote authentication (using one or more RADIUS servers).
Authorization. Authorization is the service that describes the attributes as to what the user is authorized to perform. Authorization is provided by attributes that are obtained from a AAA server or locally. Attribute-Value (AV) pairs are used to contain the specific rights of the appropriate user.
Accounting. Accounting provides the service for collecting information, logging the information locally, and sending the information to the AAA server for auditing and reporting purposes.
The accounting service tracks and maintains a log of every session used to access the VPN headend.
NetFlow
NetFlow comes in a number of varieties; Flexible NetFlow has many benefits over the traditional Cisco NetFlow functionality that has been available for years in Cisco hardware and software.
Flexible NetFlow is integral part of Cisco IOS software that collects and measures data allowing all routers or switches in the network to become a source of telemetry and a monitoring device. Flexible NetFlow provides extremely granular and accurate traffic measurements and high-level aggregated traffic collection.
NetFlow allows users to monitor a wide range of packet information including packet headers and details of flows. These values are user configurable, allowing for customized traffic identification and the ability to focus and monitor specific network behavior.
Data is sent from flow exporters to flow collectors. The flow collectors can then be queried by analysis applications to give insight into traffic profiling.
NetFlow is generally used to gain insight into the traffic traversing within the IPsec Security Association. Hence this is a data-plane monitoring. This can be achieved by applying the NetFlow policy to the tunnel interface. In this instance details of all flows that are sent within the IPsec Security Association will be captured. The flow data will contain details of the specified information such as client to server IP addresses, protocols, and ports.
When the NetFlow policy is applied to the tunnel source interface, IKE traffic and encrypted traffic are monitored. The concept of viewing details of the IKE traffic is classified as control-plane monitoring. When NetFlow is applied to the source of the tunnel interface, telemetry about the encapsulated and protected traffic can be gathered. In this case, the flow data will only contain details of the IKE and IPsec flows and hence there will be far fewer flows than when a NetFlow policy is applied to the tunnel interface.
Simple Network Management Protocol
Simple Network Management Protocol (SNMP) is an application layer protocol that supports communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.
The SNMP framework is composed of the following three components:
SNMP Manager. An SNMP manager is the system used to control and monitor the activities of network hosts using SNMP. The most common managing system is called a Network Management System (NMS). The term NMS can be applied to either a dedicated device used for network management, or the applications used on such a device.
SNMP Agent. The SNMP agent is the software component within the managed device that maintains the data for the device and reports the data, as needed, to managing systems. The agent and MIB reside on the routing device (router, access server, or switch). To enable the SNMP agent on a Cisco routing device, you must define the relationship between the manager and the agent.
Management Information Base (MIB). The MIB is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB, there are collections of related objects, defined in MIB modules. MIB modules are written in the SNMP MIB module language, as defined in RFC 2578, RFC 2579, and RFC 2580.
The SNMP agent contains MIB variables whose values the SNMP manager can request or change through get or set operations. A manager can get a value from an agent or store a value into that agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to manager requests to get or set data. The agent can send unsolicited data using a trap or inform operation.
Three different versions of SNMP can be configured:
SNMPv1. SNMPv1 utilizes a community-based security mechanism and is widely considered to be insecure.
SNMPv2c. SNMPv2c utilizes a community-based security mechanism and is nearly identical to SNMPv1 in many instances. The counters are set to 64 bits, compared to 32 bits within v1.
SNMPv3. SNMPv3 integrated a number of security features (known as security models) to overcome the weaknesses present in v1 and v2c. SNMPv3 provides authentication, encryption, and message integrity.
SNMP uses the UDP protocol over port 161 for listening to get or set requests and sends trap or inform requests to port 162.
SNMP messages are relatively computationally expensive to produce because of ASN.1 encoding. SNMP should not be used when normal conditions may generate a large amount of messages because it could incur an excessive load . SNMP is better suited for alerts when abnormal conditions occur.
VRF-Aware SNMP
Cisco IOS allows for a number of MIBs to be VRF aware. VRF-aware SNMP allows for a MIB interface linked to a MIB to reside in one VRF; however, the generated trap can be sent to a SNMP server that resides in a separate VRF.
This architecture allows a FVRF to be used to generate IKE and IPsec related information. This can be sent to a SNMP server that resides in the management VRF (or any VRF that is separate to the FVRF).
The following example illustrates how to configure VRF-aware SNMP for a VRF-aware IPsec deployment.
1. An SNMP context is created.
snmp-server context SNMP-WAN
2. A VRF is created with the associated SNMP context.
vrf definition wan
address-family ipv4
snmp context SNMP-WAN
exit-address-family
3. An SNMP group is created and associated with the SNMP context.
snmp-server group wan-grp v3 auth context SNMP-WAN
4. A SNMP user is assigned to a group.
snmp-server user wan-user wan-grp v3 auth sha cisco123
5. The SNMP server is defined, using the user account created previously.
snmp-server host 10.10.10.1 vrf mgmt version 3 auth wan-user
Using this configuration, traps can be generated for events that occur within the FVRF, or the IVRF, but they will be sent to an SNMP server.
Syslog
RFC 3164, “The BSD syslog Protocol” describes the syslog protocol, which provides a transport mechanism to allow a machine to send event notification messages across IP networks to event message collectors, also known as syslog servers.
Each message will contain a severity value; Table 13-1 illustrates these levels and the meaning of each.
The syslog server will run a syslog daemon, which commonly listens on UDP port 514 or TCP port 601 when a reliable syslog configuration is used. The syslog sender will send a message of 1KB or less. Because it is a connectionless protocol, UDP does not provide acknowledgments to the sender or receiver. Additionally, at the application layer, syslog servers do not send acknowledgments back to the sender for receipt of syslog messages. Consequently, the sending device generates syslog messages without knowing whether the syslog server has received the messages. In fact, the sending devices will send messages even if the syslog server does not exist; these messages get lost in the network.
A syslog message seen on the wire has three distinct parts: the PRI (priority), HEADER, and MSG (message).
The total length of the packet cannot exceed 1024 bytes. There is no minimum length.
A syslog service can be verbose in nature, so it must be implemented precisely. Adequate thresholds and filters must be defined to generate actionable alerts based on the syslog messages. Critical syslog messages should be prioritised easily, resulting in benign messages not alerting staff to non-critical events. The generation of a large number of syslog messages can cause excessive control-plane activity.
Monitoring Methodology
When a methodology is applied to monitoring IPsec VPNs, a structured approach can be taken to ensure that untoward activities are identified and subsequently rectified in a timely manner.
Understanding the conditions that occur when an IPsec VPN is correctly functioning and the conditions that occur when an IPsec is not functioning correctly is the key to success when deploying a monitoring solution. Knowing that an IPsec Security Association has not been created successfully is as critical as knowing when an IPsec Security Association is functioning correctly.
The ideal monitoring solution would give enough information to monitor what is considered normal activity; however, when abnormal activity occurs more verbose telemetry would be generated.
Table 13-2 illustrates the functions that are used to establish an IPsec Security Association, the corresponding protocol, and the method that can be used when monitoring connectivity.
When a monitoring architecture is deployed, attention should be paid to components that can cause the critical functions to fail. For example, if an IPsec headend is being used for remote access connections that uses EAP with a backend RADIUS server, should connectivity fail to the RADIUS server, all new user sessions will fail to authenticate. This is in contrast to the same architecture, however should the attributes of a single user fail to be retrieved only the user session will fail. This will have considerably less impact to the overall system than a failure condition that affects all users such as loss of connectivity to the RADIUS server.
Whenever possible, automated monitoring should occur. By this we mean that an automated mechanism should issue an alert if critical components fail and the alert should be sent with meaningful data. If possible, verbose logging should occur only when a critical component fails, for this minimizes the impact that logging can have on the CPU, available bandwidth, and storage. It is also prudent to alert only when critical events occur that will cause major impact. It would be unwise to page an on-call engineer at 02:00 a.m. because a single IKE session failed to authenticate for a noncritical system. However, should a major component fail that will affect all users of a service, such as CRL retrieval if revocation is enabled or loss of connectivity to a RADIUS server when EAP is in use, then a critical event should be generated.
Any data that is generated by monitoring can be useful; in many instances it is the only evidence after an event has occurred.
Please be mindful of enabling extremely verbose logging, in many instances this can generate a large amount of CPU cycles. There have been numerous cases where a large number of syslog servers were configured in conjunction with verbose logging. The result was constant high CPU as many syslog messages were sent to the numerous syslog servers.
For any messages that are generated locally and include a timestamp, Network Time Protocol (NTP) should be used to ensure accurate time reporting. Time should be synchronized from a trusted source with authentication enabled.
The following example illustrates enabling timestamps for logging and debugging messages, in addition to setting the time zone. This will ensure that all messages can be accurately identified in a timely fashion.
service timestamps debug datetime localtime show-timezone
service timestamps log datetime localtime show-timezone
clock timezone GMT 0
IP Connectivity
Before IP connectivity can occur, the interface that is sending and receiving data must be in the up state. This means that correct cabling must be present and that there is an active line protocol. Issues that could cause an interface to not be in the up state include misconfigured cabling, broken fibers, and hardware issues with network interface cards (NIC).
Knowing if the interface that is acting as the source of a tunnel is flapping (going up and down), or even changed state can be critical in helping to determine connectivity issues. The following example illustrates the logging messages that are generated when an interface changes state.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
Interfaces that are critical for the functionality of the system should be monitored for any indication of flapping. For interfaces that do not require monitoring, the no logging event link-status command can be configured on the interface to turn off the generation of messages when the state changes.
SNMP can be used to monitor when state of physical interfaces change. The following example illustrates the SNMP configuration required to enable traps when interfaces change between up and down states.
snmp-server enable traps snmp linkup linkdown
The following example shows a SNMP debug message generated when a physical interface changes state.
SNMP: V1 Trap, ent snmpTraps, addr 10.10.10.1, gentrap 2, spectrap 0
ifIndex.1 = 1
ifDescr.1 = Ethernet0/0
ifType.1 = 6
lifEntry.20.1 = administratively down
In most situations, the transport network will require a routing protocol to operate. If this is the case, then the neighbor adjacency should be monitored to ensure that there is no loss of connectivity with the routing peer, which results in the loss of routes for the IPsec peer.
The following example illustrates EIGRP and BGP logging messages that are generated when a neighbor is removed.
%DUAL-5-NBRCHANGE: IP-EIGRP 109: Neighbor 10.1.1.1 (GigabitEthernet1/2) is
down: peer restarted
%DUAL-5-NBRCHANGE: IP-EIGRP 109: Neighbor 10.1.1.1 (GigabitEthernet1/2) is
down: interface down
%DUAL-5-NBRCHANGE: IP-EIGRP 109: Neighbor 10.1.1.1 (GigabitEthernet1/2) is up:
new adjacency
%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down BGP Notification sent
%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up
SNMP can be used to indicate routing neighborships changing. The example below shows the configuration to enable traps for EIGRP, and it also illustrates the SNMP message that is generated when a EIGRP neighbor changes.
snmp-server enable traps eigrp
SNMP can be used to alert on
SNMP: Queuing packet to 10.10.10.1
SNMP: V1 Trap, ent ciscoEigrpMIB, addr 10.10.10.1, gentrap 6, spectrap 3
cEigrpPeerAddr.0.1.0 = 10.10.50.8
cEigrpPeerAddrType.0.1.0 = 1
Other routing protocols, such as BGP or OSPF, can be configured using SNMP to alert when connectivity changes. These are configured using the snmp-server enable traps command, similar to the command in the previous example; however, their configuration will use the bgp or ospf keywords instead of eigrp.
Knowing that a routing peer was lost does not help when a device loses reachability for the prefix that contains the tunnel destination. In this scenario, dead peer detection will activate, bringing the IKE session down and the corresponding tunnel into the down state.
Should a routing protocol be running over the IPsec Security Association, the same method can be used for monitoring. However, it should be noted that in this case the overlay network is being monitored and not the transport network.
VPN Tunnel Establishment
When an IKEv2 session is successfully created, SNMP or syslog messages can be used to send an alert.
Cisco IPsec Flow Monitor MIB
When SNMP is used to monitor IKE or IPsec, it is advisable to use the Cisco-IPsec-Flow-Monitor-MIB. This is based on the IETF draft-ietf-ipsec-flow-monitoring-mib-01 but is updated to reflect IKEv2. For monitoring, the MIB consists of notifications types, which contains objects. The updates consist of new objects, such as email address or Distinguished Name (DN) for the IKE ID, which is described in the notification cikeTunLocalType. The cikeNegMode notification, which in IKEv1 previously contained objects for aggressive mode and main mode, has been updated to include an object for IKEv2.
This is generally considered to be the de-facto MIB when VPNs are used. The MIB is structured for monitoring, trending, and troubleshooting IPsec connections. Data gained by this MIB can be used to identify trends and failure events. The MIB is split into two components: IKE (versions 1 and 2) is covered with cike, and IPsec with cipsec.
The MIB was designed based on specific requirements from service providers who wanted to offer an outsourced VPN service to customers. The main focus was the provision of services in such a way that would satisfy a Service Level Agreement (SLA).
SNMP with IKEv2
SNMP traps can be configured to alert when an IKE session starts with the command shown in the following example.
snmp-server enable traps ike tunnel start
This will generate a notification that contains the local and remote addresses and the lifetime of the tunnel. The following example illustrates a message generated when the IKE session is started. The local address is shown as the IKE identity, along with the IP address, which is shown as hex 0x0A0A0A02, which is 10.10.10.2 in decimal.
SNMPv2-MIB::snmpTrapOID.0 = OID: CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunnelStart
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerLocalAddr.9."hostname=router1.cisco.com".9
"hostname=router2.cisco.com".9 = Hex-STRING: 0A 0A 0A 02
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerRemoteAddr.9."hostname=router1.cisco.com".9
"hostname=router2.cisco.com"9 = Hex-STRING: 0A 0A 0A 01
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunLifeTime.9 = INTEGER: 86400 seconds
SNMP notifications can be enabled when an IKE session is removed. This is achieved using the command shown in the following example. The notification ikeTunnelStop contains objects to describe the local and remote IKE identities, the termination reason, and the lifetime of the IKE SA.
snmp-server enable traps ike tunnel stop
This will generate a notification that contains the local and remote addresses, the reason the IKE session was removed, and the lifetime of the IKE SA.
The following example illustrates a SNMP notification generated when an IKE session is deleted. The local address is shown as the IKE identity, along with the IP address. The tunnel active time shows the lifetime of the tunnel and the reason for deletion.
SNMPv2-MIB::snmpTrapOID.0 = OID: CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunnelStop
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerLocalAddr.9."hostname=router1.cisco.com".9
"hostname=router2.cisco.com".9 = Hex-STRING: 0A 0A 0A 02
CISCO-IPSEC-FLOW-MONITOR-MIB::cikePeerRemoteAddr.9."hostname=router1.cisco.com".9
"hostname=router2.cisco.com"9 = Hex-STRING: 0A 0A 0A 01
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunActiveTime.3 = INTEGER: 11
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeTunHistTermReason.3 = INTEGER: other(1)
Details of IKE sessions are stored within the MIB and can be obtained by using SNMP or locally by using the show crypto mib ike flowmib command, as the following example illustrates.
Router#show crypto mib ike flowmib ?
failure Shows ike mib failure table
global Shows ike mib global statistics
history Shows ike mib history table
peer Shows ike mib peer info
tunnel Shows ike mib tunnel info
For previous sessions the history keyword can be used to show statistics such as the transmitted octets and number of packets, along with the authentication method and cryptographic algorithms used.
The global keyword can be used to display statistics pertaining to global IKE sessions that have occurred on the device.
By default the details of 200 sessions are stored locally. This value can be changed with the command illustrated in the following example.
crypto mib ipsec flow history tunnel size <2-200>
The following example illustrates the IKE SNMP objects within the MIB.
Router#show snmp mib | i cike
cikeGlobalActiveTunnels
cikeGlobalPreviousTunnels
cikeGlobalInOctets
cikeGlobalInPkts
cikeGlobalInDropPkts
cikeGlobalInNotifys
cikeGlobalInP2Exchgs
cikeGlobalInP2ExchgInvalids
cikeGlobalInP2ExchgRejects
cikeGlobalInP2SaDelRequests
Table 13-3 lists the SNMP trap commands that enable message generation when an IKE SA is created or terminated. The notification type is listed, along with the objects contained within this.
Note that with SNMP statistics for IKE, these are global for both IKEv1 and IKEv2. There is no differentiation between the values for each protocol.
Syslog
It is possible to activate syslog messages to report on events that are related to the creation and deletion of IKEv2 SAs. The following example illustrates the command to enable the generation of syslog messages in relation to IKEv2.
Router(config)#crypto logging ikev2
If syslog messages are enabled, when a IKEv2 SA is created the message shown in the following example is generated.
%IKEV2-5-SA_UP: SA UP
When syslog messages are enabled, when an IKEv2 SA is deleted the message shown in the following example is generated.
%IKEV2-5-SA_DOWN: SA DOWN
It is possible to enable syslog messages for the creation or deletion of a crypto session. The following example illustrates enabling the generation of crypto session messages.
Router(config)#crypto logging session
The following example illustrates the message generated when an IKEv2 session is created.
%CRYPTO-5-IKEV2_SESSION_STATUS: Crypto tunnel v2 is UP. Peer 10.10.10.1:500
Id: hostname=Router.cisco.com
The following example illustrates the message generated when an IKEv2 session is deleted.
%CRYPTO-5-IKEV2_SESSION_STATUS: Crypto tunnel v2 is DOWN. Peer 10.10.10.1:500
Id: hostname=Router1.cisco.com
Most syslog messages related to IKEv2 are generated with a severity level of 5, which indicates a notification; however, if a negotiation aborted message is generated, the severity level is 3. When a cookie challenge is sent, the severity level is 1. Table 13-4 illustrates the IKEv2 messages and the corresponding syslog severity level. Having a minimum severity of 5 requires the logging level to be set to 5 or above for the messages to be generated and seen.
When IKEv2 syslog logging is enabled, if an IKE session fails to be established, a syslog message will be generated. The following example illustrates a typical message that is generated; however, the exact message will vary depending on the nature of the cause. This will require further examination to determine the specific peer and the reason for the authentication failure.
%IKEV2-3-NEG_ABORT: Negotiation aborted due to ERROR: Auth exchange failed
%IKEV2-3-NEG_ABORT: Negotiation aborted due to ERROR: Received no proposal chosen
notify
Pre-Shared Key Authentication
AAA accounting allows for session information to be generated, indicating when the session starts and when it stops. In addition, session identity information and session usage information will be passed to the RADIUS server via RADIUS attributes and VSA (vendor-specific attributes). RADIUS accounting is used to record user activity for auditing purposes in many large-scale networks, and its use is suitable when a historic record of VPN sessions is required.
When PSK is used as the authentication mechanism, accounting can be enabled to report on successful authentication and creation of the IPsec Security Association. On creation of this event, IKE makes a call to AAA to start an accounting record. This request is sent to the AAA server and contains the calling-station-id, which is the source IP address of the peer. The user-name is the IKE identity.
The following example illustrates the accounting data generated when an IKE session is created.
AAA/ACCT/EVENT/(00000011): CALL START
AAA/ACCT/EVENT/(00000011): IPSEC TNL UP
AAA/ACCT/IPSEC-TUNNEL(00000011): Queueing record is START
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Accounting start request sent successfully
RADIUS(00000011): Send Accounting-Request to 172.16.1.3:1646 id 1646/9, len 256
RADIUS: authenticator 6A 7A 8F EA 4E 10 E9 CE - 8C C9 EC A8 C4 70 C7 9F
RADIUS: Acct-Session-Id [44] 10 "00000007"
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 60
RADIUS: Cisco AVpair [1] 54 "audit-session-id=L2L4AC1G102ZO2L4AC1G101Z
I1F401F4ZO8"
RADIUS: Vendor, Cisco [26] 40
RADIUS: Cisco AVpair [1] 34 "isakmp-phase1-id=Router1.Domain1"
RADIUS: Vendor, Cisco [26] 37
RADIUS: Cisco AVpair [1] 31 "isakmp-initator-ip=172.16.1.1"
RADIUS: User-Name [1] 17 "Router1.Domain1"
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Acct-Status-Type [40] 6 Start [1]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS: Acct-Delay-Time [41] 6 0
The accounting stop record is sent after the IKE/IPsec session is deleted. The accounting stop record includes the calling-station-id, which contains the peer IP address, and the username-name, which contains the peer IKE identity. The lifetime of the session is included, and the amount of incoming and outgoing octets and packets. This information can be used to determine how long a session lasted for and how much data was transmitted.
There was a customer case where an IPsec profile was configured to use Perfect Forward Secrecy (PFS); however certain clients did not support PFS and would fail rekey. Users reported a degraded service. When the AAA accounting data was examined, it became apparent that the lifetime of sessions that users reported as degraded would only last a maximum of one hour before PFS would be attempted when a rekey occurred, at this point the rekey would fail and the session be torn down.
The following example illustrates the accounting data generated when a IKE session is torn down.
AAA/ACCT/EVENT/(00000011): IPSEC TNL DOWN
IKEv2:in_octets 13020, out_octets 17640
IKEv2:in_packets 105, out_packets 105
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Accounting stop request sent successfully
AAA/ACCT/EVENT/(00000011): CALL STOP
AAA/ACCT/IPSEC-TUNNEL(00000011): STOP
RADIUS(00000011): Send Accounting-Request to 172.16.1.3:1646 id 1646/10, len 324
RADIUS: authenticator 6E 18 B4 4F E0 B5 C0 09 - 9F B9 FC 01 5A D4 69 6F
RADIUS: Acct-Session-Id [44] 10 "00000007"
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 60
RADIUS: Cisco AVpair [1] 54 "audit-session-id=L2L4AC1G102ZO2L4AC1G101Z
I1F401F4ZO8"
RADIUS: Vendor, Cisco [26] 40
RADIUS: Cisco AVpair [1] 34 "isakmp-phase1-id=Router1.Domain1"
RADIUS: Vendor, Cisco [26] 37
RADIUS: Cisco AVpair [1] 31 "isakmp-initator-ip=172.16.1.1"
RADIUS: User-Name [1] 17 "Router1.Domain1"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Session-Time [46] 6 34
RADIUS: Acct-Input-Octets [42] 6 13020
RADIUS: Acct-Output-Octets [43] 6 17640
RADIUS: Acct-Input-Packets [47] 6 105
RADIUS: Acct-Output-Packets [48] 6 105
RADIUS: Acct-Terminate-Cause[49] 6 none [0]
RADIUS: Vendor, Cisco [26] 32
RADIUS: Cisco AVpair [1] 26 "disc-cause-ext=No Reason"
RADIUS: Acct-Status-Type [40] 6 Stop [2]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS: Acct-Delay-Time [41] 6 0
PKI Authentication
When authentication occurs using PKI, the PKI subsystem is generally called by the IKE subsystem, and the IKE subsystem will generally generate informational messages.
There are a number of syslog messages generated by PKI when error conditions occur. These messages pertain to issues encountered with certificates, such as the peer certificate not being within the validity period, revoked, or expired.
In many instances the cause of PKI failures is an incorrect time setting, which results in certificate validity errors being generated.
There are a number of syslog messages generated by the PKI subsystem. The following example illustrates some of the syslog PKI messages that can be generated that contain certificate-related conditions.
The following lists illustrate error messages that are generated for PKI-related events: specifically, certificate error messages, CA-related error messages, and renewal error messages.
PKI certificate error messages
%PKI-3-CERTIFICATE_INVALID:
%PKI-3-CERTIFICATE_INVALID_EXPIRED:
%PKI-3-CERTIFICATE_INVALID_NOT_YET_VALID:
%PKI-3-CERTIFICATE_REVOKED:
PKI CA-related error messages
%PKI-3-GETCARACERT:
%PKI-3-POLLCACERT:
%PKI-3-POLLROUTERCERT:
%PKI-3-SOCKETSELECT:
%PKI-3-SOCKETSEND:
PKI certificate renewal error messages
%PKI-4-CRL_LDAP_QUERY:
%PKI-4-CS_PUBLISH_STORAGE:
%PKI-4-NOAUTOSAVE:
%PKI-4-NOCONFIGAUTOSAVE:
%PKI-4-NOSHADOWAUTOSAVE:
%PKI-6-AUTOENROLL_KEY_LOCKED:
%PKI-6-AUTOSAVE:
%PKI-6-CERTFAIL:
%PKI-6-CERT_FATAL_ERR:
%PKI-6-CERTIFSRECV:
%PKI-6-CERTIFSSEND:
%PKI-6-CERTPENDING:
%PKI-6-CERTREJECT:
%PKI-6-CERTRET:
%PKI-6-CONFIGAUTOSAVE:
AAA accounting can be enabled for PKI authentication. The following example illustrates the configuration used to create the accounting information.
aaa new-model
aaa group server radius RA-AUTHC-SG-1
server-private 172.16.100.100 auth-port 1812 key Cisco123
aaa accounting network RA-ACCC-LIST-1 start-stop group RA-AUTHC-SG-1
crypto ikev2 profile ALL-SPOKES
match certificate certmap
identity local dn
authentication remote rsa-sig
authentication local rsa-sig
pki trustpoint MYCERT
aaa accounting cert RA-ACCC-LIST-1
virtual-template 1
The following example shows an accounting request that was generated for an incoming successful authentication. The IKE identity can be seen in addition to the source IP address, which will be the post-NAT address of the peer (if NAT was used on the transport network).
RADIUS(00000016): Send Accounting-Request to 172.16.100.100:1646 id 1646/17,
len 284
RADIUS: authenticator 1D C9 AB 28 97 97 98 D7 - 01 F1 35 3D 79 F1 53 16
RADIUS: Acct-Session-Id [44] 10 "0000000A"
RADIUS: Calling-Station-Id [31] 11 "209.1.1.2"
RADIUS: Vendor, Cisco [26] 62
RADIUS: Cisco AVpair [1] 56 "audit-session-id=L2L4C8010102ZO2L4D101010
2ZI1F401F4ZOE"
RADIUS: Vendor, Cisco [26] 54
RADIUS: Cisco AVpair [1] 48 "isakmp-phase1-id=hostname=Spoke-1.cisco
.com"
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "isakmp-initator-ip=209.1.1.2"
RADIUS: User-Name [1] 31 "hostname=Spoke-1.cisco.com"
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Acct-Status-Type [40] 6 Start [1]
Hub-1(config-ikev2-profile)#
RADIUS: NAS-IP-Address [4] 6 172.16.0.1
RADIUS: Acct-Delay-Time [41] 6 0
RADIUS(00000016): Sending a IPv4 Radius Packet
RADIUS(00000016): Started 5 sec timeout
The following example shows an accounting request that was generated for the termination of a PKI-authenticated session The IKE identity can be seen, in addition to the source IP address (post-NAT if NAT was used) of the peer and the traffic sent and session duration.
RADIUS(00000016): Send Accounting-Request to 172.16.100.100:1646 id 1646/26,
len 352
RADIUS: authenticator D2 06 49 A8 79 F8 77 04 - E3 58 B9 4F D5 66 5E E8
RADIUS: Acct-Session-Id [44] 10 "0000000A"
RADIUS: Calling-Station-Id [31] 11 "209.1.1.2"
RADIUS: Vendor, Cisco [26] 62
RADIUS: Cisco AVpair [1] 56 "audit-session-id=L2L4C8010102ZO2L4D101010
2ZI1F401F4ZOE"
RADIUS: Vendor, Cisco [26] 54
RADIUS: Cisco AVpair [1] 48 "isakmp-phase1-id=hostname=Spoke-1.cisco
.com"
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "isakmp-initator-ip=209.1.1.2"
RADIUS: User-Name [1] 31 "hostname=Spoke-1.cisco.com"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Session-Time [46] 6 39
RADIUS: Acct-Input-Octets [42] 6 15222
RADIUS: Acct-Output-Octets [43] 6 15641
RADIUS: Acct-Input-Packets [47] 6 22
RADIUS: Acct-Output-Packets [48] 6 17
RADIUS: Acct-Terminate-Cause[49] 6 none [0]
RADIUS: Vendor, Cisco [26] 32
RADIUS: Cisco AVpair [1] 26 "disc-cause-ext=No Reason"
RADIUS: Acct-Status-Type [40] 6 Stop [2]
RADIUS: NAS-IP-Address [4] 6 172.16.0.1
RADIUS: Acct-Delay-Time [41] 6 0
RADIUS(00000016): Sending a IPv4 Radius Packet
EAP Authentication
Like the other authentication methods, EAP can generate accounting data when a session is successfully created or destroyed.
The following example illustrates the configuration used to create the accounting information.
aaa new-model
aaa group server radius RA-AUTHC-SG-1
server-private 172.16.100.100 auth-port 1812 key Cisco123
aaa authentication login RA-AUTHC-LIST-1 group RA-AUTHC-SG-1
aaa authorization network RA-AUTHZ-LIST-1 local
aaa accounting network RA-ACCC-LIST-1 start-stop group RA-AUTHC-SG-1
crypto ikev2 profile RA-CLIENT
match identity remote address 0.0.0.0
identity local dn
authentication remote eap query-identity
authentication local rsa-sig
pki trustpoint MYCERT
aaa authentication eap RA-AUTHC-LIST-1
aaa authorization group eap list RA-AUTHZ-LIST-1 RA-LOCAL-POLICY-1
aaa accounting eap RA-ACCC-LIST-1
virtual-template 10
The same attributes, such as Calling-Station-Id, are used to record the source IP address used, along with the IKE identity, which is defined using isakmp-phase1-id, and the isakmp-initator-ip value is the source IP address. The username presented can be seen by the value user-name, and the framed-ip-address shows the IP address allocated via the local IP pool.
The following example illustrates the accounting data generated when an IKE session is created.
RADIUS/ENCODE: Best Local IP-Address 172.16.0.1 for Radius-Server 172.16.100.100
RADIUS(00000014): Send Accounting-Request to 172.16.100.100:1646 id 1646/1, len
256
RADIUS: authenticator 50 3B BC 65 EB 53 6A 91 - 44 13 F0 FE 6D 06 01 2F
RADIUS: Calling-Station-Id [31] 14 "209.1.10.100"
RADIUS: Vendor, Cisco [26] 63
RADIUS: Cisco AVpair [1] 57 "audit-session-id=L2L4C8010102ZO2L4D1010A6
4ZH11941194ZO6"
RADIUS: Vendor, Cisco [26] 37
RADIUS: Cisco AVpair [1] 31 "isakmp-phase1-id=209.1.10.100"
RADIUS: Vendor, Cisco [26] 39
RADIUS: Cisco AVpair [1] 33 "isakmp-initator-ip=209.1.10.100"
RADIUS: Framed-IP-Address [8] 6 172.16.101.10
RADIUS: Acct-Session-Id [44] 10 "00000006"
RADIUS: User-Name [1] 7 "user1"
RADIUS: Vendor, Cisco [26] 36
Hub-1#
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Acct-Status-Type [40] 6 Start [1]
RADIUS: NAS-IP-Address [4] 6 172.16.0.1
RADIUS: Acct-Delay-Time [41] 6 0
The following example illustrates the accounting data generated when an IKE session is torn down. The information about the session can be seen, with User-Name denoting the EAP username used to identify the session.
RADIUS(00000014): Send Accounting-Request to 172.16.100.100:1646 id 1646/6, len 324
RADIUS: authenticator B5 59 09 6E F0 A5 8D F0 - 37 1B 64 53 C5 AC 00 91
RADIUS: Calling-Station-Id [31] 14 "209.1.10.100"
RADIUS: Vendor, Cisco [26] 63
RADIUS: Cisco AVpair [1] 57 "audit-session-id=L2L4C8010102ZO2L4D1010A6
4ZH11941194ZO6"
RADIUS: Vendor, Cisco [26] 37
RADIUS: Cisco AVpair [1] 31 "isakmp-phase1-id=209.1.10.100"
RADIUS: Vendor, Cisco [26] 39
RADIUS: Cisco AVpair [1] 33 "isakmp-initator-ip=209.1.10.100"
RADIUS: Framed-IP-Address [8] 6 172.16.101.10
RADIUS: Acct-Session-Id [44] 10 "00000006"
RADIUS: User-Name [1] 7 "user1"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Session-Time [46] 6 51
RADIUS: Acct-Input-Octets [42] 6 7577
RADIUS: Acct-Output-Octets [43] 6 3064
RADIUS: Acct-Input-Packets [47] 6 91
RADIUS: Acct-Output-Packets [48] 6 23
RADIUS: Acct-Terminate-Cause[49] 6 none [0]
RADIUS: Vendor, Cisco [26] 32
RADIUS: Cisco AVpair [1] 26 "disc-cause-ext=No Reason"
RADIUS: Acct-Status-Type [40] 6 Stop [2]
RADIUS: NAS-IP-Address [4] 6 172.16.0.1
RADIUS: Acct-Delay-Time [41] 6 0
Authorization Using RADIUS-Based AAA
RADIUS combines authentication and authorization into a single function. The Access-Accept packet sent by the RADIUS server to the client contains authorization information, which may create difficultly when attempting to decouple authentication and authorization.
The authorization policy used can be determined from enabling debugging on the VPN gateway itself. This does not scale for large-scale deployments, so it is more prudent to enable this only when it is specifically required.
The following example illustrates the logging messages pertaining to authorization from IKE and AAA. These were enabled using the debug crypto ikev2 and debug aaa authorization commands.
IKEv2:Using mlist default and username service1 for group author request
AAA/BIND(0000004E): Bind i/f
AAA/AUTHOR (0x4E): Pick method list 'default'
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorisation request sent
IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorisation response
When RADIUS is used, an alternative to enabling debugging is to obtain data pertaining to authorization events by viewing the logs on the RADIUS server itself. The requested authorization policy can usually be viewed in a log message that contains the Access-Accept information.
Data Encryption: SNMP with IPsec
SNMP can be used for generating notifications when an IPsec Security Association is created or destroyed. The following example illustrates the command that enables traps to be generated when an IPsec tunnel is created.
snmp-server enable traps ipsec tunnel start
The following example illustrates the command that enables traps to be generated when an IPsec tunnel is destroyed.
snmp-server enable traps ipsec tunnel start
The IPsec SNMP trap contains a great deal of information, including the tunnel source and destination IP addresses, lifetime, tunnel protocol, and the reason for the tunnel’s termination. The following example illustrates a trap when an IPsec tunnel is removed; the source and destination IP addresses are seen in hexadecimal (0A 0A 0A 01 representing 10.10.10.1 in decimal). The protocol is 47, indicating GRE. The tunnel is being terminated because the peer was lost.
SNMPv2-MIB::snmpTrapOID.0 = OID: CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunnelStop
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunActiveTime.13 = INTEGER: 301032
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHistActiveTime.13 = INTEGER: 301032
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHistLifeTime.13 = INTEGER: 3600 Seconds
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHistLifeSize.13 = INTEGER: 4608000 KBytes
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHistTermReason.13 = INTEGER: peerLost (5)
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistLocalType.13 = INTEGER:
singleIpAddr(1)
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistRemoteType.13 = INTEGER:
singleIpAddr(1)
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistLocalAddr1.13 = Hex-STRING: 0A 0A
0A 01
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistLocalAddr2.13 = Hex-STRING: 0A 0A
0A 01
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistRemoteAddr1.13 = Hex-STRING: 0A 0A
0A 02
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistRemoteAddr2.13 = Hex-STRING: 0A 0A
0A 02
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistLocalProtocol.13 = INTEGER: 47
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecEndPtHistLocalPort.13 = INTEGER: 0
Similar to IKE, the SNMP information is stored within the MIB. The following example illustrates how to view the SNMP objects.
Router#show snmp mib | i cipSec
cipSecMibLevel
cipSecGlobalActiveTunnels
cipSecGlobalPreviousTunnels
cipSecGlobalInOctets
cipSecGlobalHcInOctets
cipSecGlobalInOctWraps
cipSecGlobalInDecompOctets
cipSecGlobalHcInDecompOctets
cipSecGlobalInDecompOctWraps
Table 13-5 illustrates the SNMP trap commands used to enable message generation when an IPsec Security Association is created. The notification type is listed, along with the objects contained within the notification.
Overlay Routing
If a routing protocol is being used over the created IPsec Security Association, this should be monitored. The best tools to monitor a routing protocol are either SNMP or syslog, both of which were covered within the earlier section on IP connectivity. The same concepts can be used again for overlay routing. If logs for both overlay and transport routing are used, care should be taken to ensure that there is a distinct differentiation between them.
When IKEv2 routing is used, specific focus can be used to monitor the addition and deletion of virtual-access interfaces. The following example illustrates the command that enables traps when a virtual-access interface is created.
snmp-server enable traps snmp linkdown linkup
The following example illustrates the SNMP trap generated when a virtual-access interface is created and removed. The virtual-access interface number can be seen, as well as the state of the tunnel (Tunnel Up or Tunnel Down).
ifIndex.24 = 24
ifDescr.24 = Virtual-Access1
ifType.24 = 131
lifEntry.20.24 = Tunnel Up
ifIndex.24 = 24
ifDescr.24 = Virtual-Access1
ifType.24 = 131
lifEntry.20.24 = Tunnel Down
If IKEv2 routing is used, when information about IP addresses is sent via a configuration payload, the local Routing Information Base (RIB) is updated. If this information is required to enable generation of information that pertains to local static routing, logging can be enabled by turning on debugging for static routing. The following example illustrates enabling static routing debugging. IKEv2 logging was also enabled to show the session being created and then the relevant IP address being assigned.
Router#debug ip routing static detail
%CRYPTO-5-IKEV2_SESSION_STATUS: Crypto tunnel v2 is UP. Peer 10.10.60.6:500
f_vrf: OUTSIDE i_vrf: OUTSIDE Id: hostname=Router.cisco.com
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to
up
IP-ST(default): updating same distance on 192.168.2.37/32
IP-ST(default): 192.168.2.37/32 [1], Virtual-Access3 Path =, add succeed, active
state
Manual verification can ensure that the IP address that was assigned to the peer is reachable via the virtual-access interface.
Router#show ip route 192.168.2.36
Routing entry for 192.168.2.36/32
Known via "static", distance 1, metric 0 (connected)
Tag 1
Routing Descriptor Blocks:
* directly connected, via Virtual-Access1, permanent
Route metric is 0, traffic share count is 1
Route tag 1
Data Usage
Statistics on the amount of data sent over a tunnel interface can be obtained from SNMP or AAA accounting. Knowing what sort of data is traveling within the tunnel can be useful for policy or billing purposes. For this requirement, NetFlow can be used to record all flows that have occurred over the tunnel interface. Tunnel interfaces or virtual-access interfaces can have NetFlow configuration applied to them to record details of flows prior to encapsulation and encryption.
There are a number of reasons why details about flows are needed. NetFlow provides a very lightweight form of network monitoring, in which network traffic can be visualized in almost real time. Applications can be monitored, along with profiles, which allows for the allocation of capacity and the monitoring of usage policy . Information from all flows traversing an IPsec Security Association can be stored; these can be warehoused for later analysis via data mining or similar processes for marketing or security purposes.
The following example illustrates the configuration that enables NetFlow data to be gathered from a virtual-access interface that is spawned from a virtual-template interface.
The exporter is configured, which is where the NetFlow data will be sent. The export protocol is configured as ipfix; NetFlow version 9 or 5 can also be configured.
flow exporter exp-1
destination 10.10.10.100
export-protocol ipfix
A flow record is created (using the match command), with details of the source and destination IP addresses, protocols, ports, and TOS value. Each of these attributes is matched to create a unique record, with the total bytes and packets sent for the flow being collected (using the collect command).
flow record v4_r1
match ipv4 tos
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
A flow monitor is created, which uses the record created earlier and exports this to the exporter configured earlier.
flow monitor f-monitor-1
record v4_r1
exporter exp-1
exit
The flow monitor is applied to the virtual-template interface. This will then record any outgoing or incoming flows over the IPsec Security Associations associated with the cloned virtual-access interfaces.
interface Virtual-Template2 type tunnel
ip unnumbered Loopback2
ip flow monitor f-monitor-1 input
ip flow monitor f-monitor-1 output
When a virtual-access interface is spawned from the virtual template, it will inherit the relevant configuration. The following example illustrates the virtual-access interface with the configuration applied.
Router#show derived-config interface virtual-access 2
Building configuration...
Derived configuration : 421 bytes
interface Virtual-Access2
ip unnumbered Loopback2
ip flow monitor f-monitor-1 input
ip flow monitor f-monitor-1 output
Any traffic flows traversing the tunnel interface will be sent to the NetFlow exporter. The following example illustrates a flow recorded in the cache; the source and destination IP addresses can be seen, along with the ports. Counters relating to the flow are also recorded.
Router#show flow monitor f-monitor-1 cache
Cache type: Normal
Cache size: 4096
Current entries: 1
High Watermark: 3
Flows added: 8
Flows aged: 7
- Active timeout ( 1800 secs) 0
- Inactive timeout ( 15 secs) 7
- Event aged 0
- Watermark aged 0
- Emergency aged 0
IPV4 SOURCE ADDRESS: 192.168.2.4
IPV4 DESTINATION ADDRESS: 192.168.2.1
TRNS SOURCE PORT: 38658
TRNS DESTINATION PORT: 23
IP TOS: 0xC0
IP PROTOCOL: 6
counter bytes long: 1545
counter packets long: 37
Router#show flow exporter statistics
Flow Exporter exp-1:
Packet send statistics (last cleared 00:20:18 ago):
Successfully sent: 4 (438 bytes)
Client send statistics:
Client: Flow Monitor f-monitor-1
Records added: 3
- sent: 3
Bytes added: 90
- sent: 90
Note
The preceding examples all used IPv4; it is also possible to use IPv6 flows if they are required.
Summary
Because many components are used to construct an IPsec VPN, there are many components that can be monitored for errors or abnormal conditions.
An IPsec Security Association that uses IKEv2 will be constructed using a number of protocols and methods. Each component can be monitored in a layered fashion, just as the protocols operate in a layered fashion.
Protocols such as SNMP, netflow, and syslog can be used to alert on event pertaining to the creation or deletion of an IKE or IPsec Security Association. RADIUS and AAA events can be used to provide alerts when AAA conditions occur.
Care should be taken when any monitoring solution is employed that uses debug statements, for these generally create a very large amount of data and can put pressure on other resources; in addition, they can generate a vast amount of noise. Monitoring should be designed so that only critical events cause alerts that require human intervention.
Knowing the behavior of a correctly functioning system and what telemetry is generated will ensure that monitored events create alerts when the system is malfunctioning.
References
https://tools.ietf.org/html/rfc1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis
https://tools.ietf.org/html/3164 The BSD syslog Protocol
https://tools.ietf.org/html/rfc3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
https://tools.ietf.org/html/rfc3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
https://tools.ietf.org/html/rfc3413 Simple Network Management Protocol (SNMP) Applications
https://tools.ietf.org/html/rfc3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
https://tools.ietf.org/html/rfc3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
https://tools.ietf.org/html/rfc3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
https://tools.ietf.org/html/rfc3417 Transport Mappings for the Simple Network Management Protocol (SNMP)
https://tools.ietf.org/html/rfc3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)