Secure Your Network
1.2
Front-End Proxy
1.2.1
Features of Front-End Proxy
1.2.1.1 SNMP Protocol
Conversion
1.2.1.2 Transport Protocol
Conversions
1.2.2 The
Proxy Agent Option
1.2.3
Applications for Front-End Proxy
1.2.3.1 Secure Management of a
Remote Network
1.2.3.2 Multiplexing Incoming SNMP
Requests
1.3
Back-End Proxy
1.3.1
Native Agent Adapter
1.3.2
Native Subagent Adapter
The term proxy has historically been used very loosely, with multiple different meanings. RFC1208 provides a simple, starting definition for proxy.
Proxy: the mechanism whereby one system "fronts for" another system in responding to protocol requests. RFC2273 identifies three popular concepts to which the term proxy has been ascribed.
(1) the forwarding of SNMP requests to other SNMP entities without regard for what managed object types are being accessed; for example, in order to forward an SNMP request from one transport domain to another, or to translate SNMP requests of one version into SNMP requests of another version;This document refers to this category of proxy as "front-end" proxy. Section 1.1.1 provides an illustration of this kind of proxy operation. Section 1.2 describes this kind of proxy operation in more detail.
(2) the translation of SNMP requests into operations of some non-SNMP management protocol;This document refers to this category of proxy as "back-end" proxy. Section 1.1.1 provides an illustration of this kind of proxy operation. Section 1.3 describes this kind of proxy operation in more detail.
(3) support for aggregated managed objects where the value of one managed object instance depends upon the values of multiple other (remote) items of management information.A discussion of this kind of proxy is beyond the scope of this document. However, SNMP Research has a product called the Mid-Level Manager, which provides this kind of proxy mechanism.
This section presents an illustration that may assist the reader to understand the operational differences between the two concepts of proxy discussed in this document.
The terms "front-end" proxy and "back-end" proxy are derived from the mental representation of an SNMP agent as a building with two doors. The front door faces the network. The back door faces the application. Inside the building, the agent's SNMP engine directs the flow of SNMP packets.
When an SNMP packet arrives from the network (through the front door), the engine begins to "unwrap" (parse) the packet. If the packet's secret information is recognized, then the engine can proceed; otherwise, the packet is rejected. The engine proceeds by unwrapping the SNMP message some more, but just enough to determine the context. If the context indicates that the request should be handled somewhere else, then the engine quits unwrapping the packet. The SNMP engine looks up the address of another building (i.e., another SNMP agent) to which it should forward the SNMP packet. The packet is "rewrapped" with a new destination address and with new secret information, and it is directed to go out the front door, into the network, and on to its final destination. This is front-end proxy.
If the context of the arriving packet indicates that the request should be handled locally, the SNMP engine finishes unwrapping the packet, and the SNMP request is scrutinized according to local access control and MIB view restrictions. If the secret information in the packet is recognized, and if the requested operation is permitted to occur, the packet's VarBinds are sent into a back room of the building (method routines) for processing. What happens in the back room of the building is determined by the application which is being managed.
The application possesses registers, e.g.,
which contain MIB data. If the application's registers are not directly accessible from the back room, then a trip must be made out the back door of the building to where ever the registers are located; e.g.,
This is back-end proxy.
If the application's registers are directly accessible from the back room of the building, e.g.,
The management request can be carried out without ever leaving the building. When this is the case, the operation is NOT considered a proxy operation at all. From the perspective of RFC 2273, the "back room" is a command responder application.
The following sections in this document provide details about the various kinds of front-end proxy and back-end proxy.
The front-end proxy mechanism can be described as per-packet multiplexing. This is because the proxy operation occurs before the SNMP packet has been completely parsed and before any of the VarBinds are examined. Each SNMP message is forwarded in its entirety1 to a new destination determined by the context of the request.
Context is an attribute of an SNMP request that was created after the community string. In SNMPv3 (which does not use community strings), the context is specified separately from the authentication secret. In SNMPv1 and SNMPv2c, the community string serves a dual role as the authentication secret and as the context.
A standards-track definition of the front-end proxy mechanism is provided by RFC 2273. This document describes a proxy forwarder application, which is a feature of any SNMP entity that implements the front-end proxy mechanism. RFC 2273 also provides a MIB document (called theSNMP-PROXY-MIB) to allow proxy relationships to be configured remotely.
The specific features of front-end proxy are described in detail in the following sections.
The front-end proxy mechanism can be used to convert management requests from one version of SNMP to another version of SNMP. This can be useful when a management station that is programmed to use one version of the SNMP protocol needs to communicate with an agent that uses a different version of the SNMP protocol. Figure 1.1 depicts several SNMP protocol conversions, and others are possible.
Figure 1.1: SNMP protocol conversion through front-end proxy
The front-end proxy mechanism can be used to provide protocol translations to alternate transport mechanisms. For example, an SNMP request that originates on a UDP/IP transport can be translated to another transport, such as IPX. Figure 1.2 depicts the transport protocol conversion feature.
Figure 1.2: Transport protocol conversion through front-end
proxy
SNMP Research's agent products do not support the front-end proxy mechanism by default. However, this feature is available in SNMP Research's agent products on selected operating systems through the Proxy Agent Option. The Proxy Agent Option adds to the agent implementation some additional programming which allows the agent to correctly process non-local context values and to forward packets to other SNMP entities.
When the Proxy Agent Option is added to SNMP Research's binary agent products, the only available feature is SNMP protocol conversion.
When the Proxy Agent Option is added to SNMP Research source code agent products, transport protocol conversions (Section 1.2.1.2) can also be supported. The source code, which is provided, can correctly send and receive SNMP packets (raw data) on an IP transport. Hooks are provided in the source code for other transports, but it is a task left to the developer to provide the functions that are necessary to send and receive raw data on other transports.
BackThis section describes two examples of how the features of the Proxy Agent Option can be used.
BackSNMPv1 has been used to manage devices since 1990, and many companies possess large networks containing devices that have an SNMPv1 agent within them. The increasing need to manage devices securely over the Internet has given rise to the development of SNMPv3 and security, and someday, the installed base of SNMPv1-managed devices will be replaced with SNMPv3-managed devices. Until all of these devices are replaced, front-end proxy can provide a layer of security to the existing devices.
In this example, a site contains a particular number of SNMPv1-managed devices.2 This site is logically remote (maybe physically remote) to the Network Operations Center (NOC). A secure, private network is not guaranteed to exist between the NOC and the remote site, so a firewall is installed to isolate the SNMPv1-managed devices from the unsecured internet. This company desires to use SNMPv3 to securely manage the remote devices from the NOC.
At the NOC, each SNMPv1 Network Management Station (NMS) is replaced by an SNMPv3 NMS, or the capability of each NMS is enhanced to support SNMPv3.3
On the firewall at the remote site, an Agent containing the Proxy Agent Option is installed, and the firewall is configured to accept SNMPv3 packets (on UDP port 161).
The front-end proxy agent executing on the firewall host receives SNMPv3 packets containing management requests from the NOC. Strong authentication between the network management stations and the proxy agent ensures that only authorized requests are forwarded to the SNMPv1 agents that are behind the firewall. Once authenticated, the proxy agent forwards the SNMP message to the protected SNMP agents as an SNMPv1 packet.4 Figure 1.3 depicts this firewall application of the front-end proxy agent.
It may be desirable to architect a service such that several users can access several SNMP-managed devices, databases, etc., but to make it so that all of the users can send their management requests to a single, well-known network address; i.e., at host1.yourcompany.com. In this example, a company offers a service as described above, and this company has decided to implement the management using a front-end proxy agent.
On the host with the well-known network address, an SNMP Research SNMP Agent containing the Proxy Agent Option is installed. Each subscriber to the service receives unique SNMPv1 or SNMPv2c community strings to access the proxy agent.5 These "secrets" are configured into the proxy agent, and each is mapped to a particular service host with a particular level of access control.
When a subscriber sends an SNMP request to the well-known network address, the Proxy Agent Option authenticates the requests and performs access control checks. Based on the context of the request, the SNMP request is routed to another host, which is actually providing a service to the subscriber. In this way, the proxy agent acts as an SNMP multiplexer, which is depicted in Figure 1.4.
Figure 1.4: Multiplexing requests sent to a single host through
front-end proxy
The back-end proxy mechanism can be described as per-VarBind multiplexing. This is because the proxy operation occurs after the SNMP packet has been completely parsed and while the VarBinds are being processed individually. The "fronting" occurs at the point where the SNMP agent would normally exchange data directly with the application's data registers.
Information is normally exchanged between the application's data registers and the SNMP agent within functions called system dependent method routines. The following is an example of a fully functional system dependent method routine (the application is a thermometer).
thermometer_t *
k_thermometer_get(serialNum, contextInfo, nominator)
int serialNum;
ContextInfo *contextInfo;
int nominator;
{
static thermometer_t thermometerData;
thermometerData.thrmTemperature = check_thermometer();
thermometerData.thrmUnits = get_thermometer_units();
SET_ALL_VALID(thermometerData.valid);
return(&thermometerData);
}
In this function, the value returned by the function check_thermometer() is assigned to the thrmTemperature field of the SNMP Research data structure thermometerData. Likewise, the value returned by get_thermometer_units() is assigned to the thrmUnits field of the same structure. The functions check_thermometer() and get_thermometer_units() are functions provided by the application to access the data registers; they are not functions provided by SNMP Research. By calling these functions, application data is retrieved by the SNMP agent directly from the application's data registers. This is shown in Figure 1.5(a). Remember that this operation is not considered to be a proxy operation by SNMP Research, but it is simply the function of a "regular" SNMP agent.
If the thermometer's data registers can not be accessed directly, then the implementation of the SNMP agent would have to involve a proxy operation. Instead of calling a simple function like check_thermometer(), the method routine may have to call several functions; e.g., to open a serial port, send a command to the thermometer, listen for data from the thermometer, and then copy the data into thrmTemperature. This is shown in Figure 1.5(b).
It may be true that the thermometer is a separate device which is already sophisticated enough to have an embedded SNMP agent inside of it. In this case, the back-end proxy operation requires that the method routine initiate an SNMP Get request to retrieve the data.6 This shown in Figure 1.5(c).
In the thermometer example just presented, the last method routine retrieved the temperature by sending an SNMP Get request to the thermometer, which was a separate device containing an embedded SNMP agent. In that instance, the back-end proxy was not a native agent adapter, because it was talking to an SNMP agent on a different machine.
The purpose of a native agent adapter is to allow a user to easily integrate an EMANATE® Master Agent into a system that already possesses an SNMP agent. EMANATE is a run-time extensible SNMP agent from SNMP Research. The agent, which is already present on the system, is called the native agent.
Typically, a native agent will implement MIB objects in the mib_2 subtree. MIB-II support is also provided by EMANATE, so if only MIB-II objects are provided by the native agent, it is typically not necessary to use a native agent adapter. The native agent can simply be replaced by EMANATE.
Occasionally, a native agent may implement the system vendor's private enterprise MIB document. In this case, it may not be desirable to remove the native agent from the system, because the vendor's MIB objects will no longer be available. This is the case when a native agent adapter should be employed.
The EMANATE Master Agent displaces the native agent. By default, the native agent binds to UDP port 161. First, the native agent is reconfigured so that it binds to a different UDP port; e.g., 8161. Then, the EMANATE Master Agent is launched, and it binds to UDP port 161. Finally, the native agent adapter is configured with the port number of the native agent, and it is told which MIB objects can be retrieved by communicating with the native agent. When the native agent adapter is launched, the private MIB objects in the native agent are available through the EMANATE Master Agent.
SNMP Research implements a general-purpose native agent adapter, which can be configured to support any MIB objects contained in a native agent. Figure 1.6 depicts the Native Agent Adapter, which is available from SNMP Research for a variety of operating systems.
The purpose of a native subagent adapter is to allow a user to easily integrate an EMANATE Master Agent into a system that already possesses a different SNMP agent that is also based on the Master Agent/Subagent paradigm. Some examples are Microsoft, SMUX, and DPI-II. The Master Agent that is already present on the system is called the native Master Agent, and the Subagents which are already present on the system are called native Subagents.
Typically, a native Master Agent will implement no important MIB objects, so it can be replaced by the EMANATE Master Agent without any special steps. Simply halt the native Master Agent to free up UDP port 161. Then launch the EMANATE Master Agent.
A native Subagent executable program will typically initiate some kind of interprocess communication (IPC) to connect to its Master Agent. The job of the native subagent adapter in this case is to respond to this communication in the same way as the native Master Agent.
A native Subagent that is implemented as a shared library will lie dormant until it is loaded. The job of the native subagent adapter in this case is to locate and load the native Subagent in the same way that the native Master Agent would.
SNMP Research has created a variety of native subagent adapters, each available on a number of operating systems. Figure 1.7 depicts the native subagent adapters that are currently available.
1 Note that a
different SNMP wrapper may be used when forwarding the message.
Back
2 SNMPv2c-managed devices are as
vulnerable as SNMPv1-managed devices. For simplicity, this
example focuses on SNMPv1-managed devices. However, the same
front-end proxy agent in this example could also be configured to
forward SNMPv2c packets to SNMPv2c-managed devices.
Back
3 For example, using the
Distributed SNMP Security Pack
from SNMP Research. Back
4 Or as an SNMPv2c packet as
appropriate.
Back
5 For simplicity, security
considerations are ignored in this example. A subscriber who
needs secure access to the SNMP-managed devices or databases
could instead receive SNMPv3 usernames, passwords, and contexts.
Back
6 This can be done easily with a product
from SNMP Research called
BRASSTM. BRASS includes a library
(called the Asynchronous Request
Library) which contains high-level functions for sending and
receiving SNMP requests. Back
For more information, please call +1 865 579-3311, or send email to info@snmp.com. You can also fill out a Sales Query and one of our sales people will respond to your request quickly.
Licensing terms are available from info@snmp.com.