Additional Managed Objects for Network Address
Translators (NAT)Viagénie246 AberdeenQuébecQCG1R 2E1Canada+1 418 656 9254simon.perreault@viagenie.cahttp://viagenie.caHuawei Technologies (USA)2330 Central ExpresswaySanta ClaraCA95050USA+1 408 330 4424tina.tsou.zouting@huawei.comCisco Systems7100-8 Kit Creek RoadResearch Triangle ParkNorth Carolina27709USA+1 919 392 5158ssenthil@cisco.comThis memo defines a portion of the Management Information Base (MIB)
for devices implementing Network Address Translator (NAT) function.
This MIB module may be used for monitoring of a device capable of NAT
function.This memo defines a portion of the Management Information Base (MIB)
for devices implementing NAT function. This MIB module may be used for
monitoring of a device capable of NAT function. Using it for
configuration is deprecated. NAT types and their characteristics are
defined in . Traditional NAT function, in
particular is defined in . This MIB does not
address the firewall functions and must not be used for configuring or
monitoring these. provides references to the SNMP
management framework, which was used as the basis for the MIB module
definition. provides an overview of the MIB
features. Lastly, has the complete NAT MIB
definition.For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
.Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in , and .All objects defined in have been marked with
"STATUS deprecated" for the following reasons:
Experience with NAT has shown that
implementations vary tremendously. The NAT algorithms and data
structures have little in common across devices, and this results
in wildly incompatible configuration parameters. Therefore, few
implementations were ever able to claim full compliance.Lesson learned: the MIB should be read-only as much as
possible.Even in read-only
mode, many configuration parameters were exposed by (e.g. timeouts). Since implementations vary
wildly in their sets of configuration parameters, few
implementations could claim even basic compliance.Lesson learned: the NAT MIB's purpose is not to expose
configuration parameters.Objects from tie
NAT state with interfaces (e.g. the interface table, the way map
entries are grouped by interface). Many NAT implementations either
never keep track of the interface or associate a mapping to a set
of interfaces. Since interfaces are at the core of , many NAT devices were unable to have a
proper implementation.Lesson learned: NAT is a logical function that may be independent
of interfaces. Do not tie NAT state with interfaces. used four
categories of NAT service: basicNat, napt, bidirectionalNat,
twiceNat. These are ill-defined and many implementations either
use different categories or do not use categories at all.Lesson learned: do not try to categorize NAT types.The set of transport
protocols was defined as: other, icmp, udp, tcp.
Furthermore, the numeric values corresponding to those labels were
arbitrary, without relation to the actual standard protocol
numbers. This meant that NAT implementations were limited to those
protocols and were unable to expose information about DCCP, SCTP,
etc.Lesson learned: use standard transport protocol numbers.New features in this module are as follows:
Many new counters are introduced. Most of them
are available in two variants: global and per-transport protocol.A few limits on the quantity of state data
stored by the NAT device. Some of them can trigger
notifications.Pools of external addresses and
ports are often used in enterprise and ISP settings. Pools are
listed in a table, each with its range of addresses and ports. It is
possible to inspect each pool's usage, to set limits, and to receive
notifications when thresholds are crossed.NATs that have an "IP address pooling"
behavior of "Paired" maintain a mapping
from internal address to external address. This module allows
inspection of this mapping table.It is often
necessary to determine the internal address that is mapped to a
given external address and port. This MIB provides this table with
an index to accomplish this efficiently, without having to iterate
over all mappings.See .Mapping table entries indicate
the mapping behavior, the filtering behavior, and the address
pooling behavior that were used to create the mapping.With the advent of CGN deployment,
a set of subscriber specific counters, limits and parameters are added.Current NAT devices commonly allow the internal and external parts of
a mapping to come from different realms. The meaning of "realm" is
implementation-dependent. On some implementations it can be equivalent
to the name of a VPN Routing and Forwarding table (VRF). On others it
is simply the numeric index of a virtual routing table. Note that this
usage of "realm" is completely different from the one in .This MIB allows the realm to be indicated where it makes sense. The
format is an SnmpAdminString. On platforms that identify realms with
integers, the string representation of the integer is used instead.
The empty string has special meaning: it refers to the default realm.Note that many MIBs implicitly support realms in one form or another
by using SNMPv3 contexts. See for example the OSPFv2 MIB . This method cannot be used for the NAT MIB
because mapppings can belong to two realms simultaneously: the
internal part can be in one realm while the external part is in
another. In such cases the NAT function acts like a "wormhole" between
two realms. Using contexts would implicitly impose the restriction
that all objects would have to belong to the same realm.This MIB module IMPORTs objects from , , and .
Unauthorized access to the write-able objects could
cause a denial of service and/or widespread network disturbance.
Hence, the support for SET operations in a non-secure environment
without proper protection can have a negative effect on network
operations.
At this writing, no security holes have been identified beyond those
that SNMP Security is itself intended to address. These relate
primarily to controlled access to sensitive information and the
ability to configure a device - or which might result from operator
error, which is beyond the scope of any security architecture.
There are a number of managed objects in this MIB that may contain
information that may be sensitive from a business perspective, in
that they may represent NAT state information. Various objects can
reveal the identity of private hosts that
are engaged in a session with external end nodes. A curious outsider
could monitor these to assess the number of private hosts
being supported by the NAT device. Further, a disgruntled former
employee of an enterprise could use the
information to break into specific private hosts by intercepting the
existing sessions or originating new sessions into the host. There
are no objects that are sensitive in their own right, such as
passwords or monetary amounts. It may even be important to control
GET access to these objects and possibly to encrypt the values of
these objects when they are sent over the network via SNMP. Not all
versions of SNMP provide features for such a secure environment.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework (see , section
8), including full support for the SNMPv3 cryptographic mechanisms
(for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
IANA has assigned object identifier 123 to the natMIB module, with
prefix iso.org.dod.internet.mgmt.mib-2 in the Network
Management Parameters registry.