Definitions of Managed Objects for Network Address Translators (NATs)
RFC 7659
| Document | Type |
RFC
- Proposed Standard
(October 2015)
Errata
Was
draft-perrault-behave-natv2-mib
(individual in tsv area)
|
|
|---|---|---|---|
| Authors | Simon Perreault , Tina Tsou (Ting ZOU) , Senthil Sivakumar , Tom Taylor | ||
| Last updated | 2019-04-26 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | Spencer Dawkins | |
| Send notices to | (None) |
RFC 7659
quot;
REFERENCE
"DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses)
and 6.6 (on the need to have the IPv6 tunnel address in
the NAT mapping tables)."
::= { natv2AddressMapEntry 10 }
natv2AddressMapExternalPoolIndex OBJECT-TYPE
SYNTAX Natv2PoolIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Index of the address pool in the external realm from which
the mapped external address given in
natv2AddressMapExternalAddress was taken. Zero if the
implementation does not support address pools but has chosen
to support this object or if no pool was configured for the
given external realm."
::= { natv2AddressMapEntry 11 }
Perreault, et al. Standards Track [Page 64]
RFC 7659 NAT MIB October 2015
natv2AddressMapSubscriberIndex OBJECT-TYPE
SYNTAX Natv2SubscriberIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Index of the subscriber to which this address mapping
applies, or zero if no subscribers are configured on
this NAT instance."
::= { natv2AddressMapEntry 12 }
-- natv2PortMapTable
natv2PortMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF Natv2PortMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table of port map entries indexed by the NAT instance,
protocol, and external realm and address. A port map entry
associates an internal upper-layer protocol endpoint with an
endpoint for the same protocol in the given external realm.
By definition, this is a snapshot of NAT instance state at
a given moment. The table provides the basic mapping
information.
In the case of DS-Lite (RFC 6333), the table provides the
internal IPv6 tunnel source address in
natv2PortMapInternalRealmAddress and the IPv4 source address
of the encapsulated packet that is actually translated in
natv2PortMapInternalMappedAddress. In the general (non-DS-
Lite) case, those two objects will have the same value."
REFERENCE
"RFC 7659, Section 3.3.9.
DS-Lite: RFC 6333, Sections 5.7
(for well-known addresses) and 6.6 (on the need to have the
IPv6 tunnel address in the NAT mapping tables)."
::= { natv2MIBInstanceObjects 6 }
natv2PortMapEntry OBJECT-TYPE
SYNTAX Natv2PortMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A single NAT mapping."
INDEX { natv2PortMapInstanceIndex,
natv2PortMapProtocol,
natv2PortMapExternalRealm,
natv2PortMapExternalAddressType,
Perreault, et al. Standards Track [Page 65]
RFC 7659 NAT MIB October 2015
natv2PortMapExternalAddress,
natv2PortMapExternalPort }
::= { natv2PortMapTable 1 }
Natv2PortMapEntry ::=
SEQUENCE {
natv2PortMapInstanceIndex Natv2InstanceIndex,
natv2PortMapProtocol ProtocolNumber,
natv2PortMapExternalRealm SnmpAdminString,
natv2PortMapExternalAddressType InetAddressType,
natv2PortMapExternalAddress InetAddress,
natv2PortMapExternalPort InetPortNumber,
natv2PortMapInternalRealm SnmpAdminString,
natv2PortMapInternalAddressType InetAddressType,
natv2PortMapInternalAddress InetAddress,
natv2PortMapInternalMappedAddressType InetAddressType,
natv2PortMapInternalMappedAddress InetAddress,
natv2PortMapInternalPort InetPortNumber,
natv2PortMapExternalPoolIndex Natv2PoolIndexOrZero,
natv2PortMapSubscriberIndex Natv2SubscriberIndexOrZero
}
natv2PortMapInstanceIndex OBJECT-TYPE
SYNTAX Natv2InstanceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index of the NAT instance that created this port map entry."
::= { natv2PortMapEntry 1 }
natv2PortMapProtocol OBJECT-TYPE
SYNTAX ProtocolNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The map entry's upper-layer protocol number."
::= { natv2PortMapEntry 2 }
natv2PortMapExternalRealm OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The realm to which natv2PortMapExternalAddress belongs."
::= { natv2PortMapEntry 3 }
natv2PortMapExternalAddressType OBJECT-TYPE
SYNTAX InetAddressType
Perreault, et al. Standards Track [Page 66]
RFC 7659 NAT MIB October 2015
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Address type for the external realm. A value other
than ipv4(1) or ipv6(2) would be unexpected."
::= { natv2PortMapEntry 4 }
natv2PortMapExternalAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (0..16))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The mapping's assigned external address. (This address is
taken from the address pool identified by
natv2PortMapExternalPoolIndex, if the implementation
supports address pools and pools are configured for the
given external realm.) This is the source address for
translated outgoing packets. The address type is given
by natv2PortMapExternalAddressType."
::= { natv2PortMapEntry 5 }
natv2PortMapExternalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The mapping's assigned external port number. This is the
source port for translated outgoing packets. If the internal
port number given by natv2PortMapInternalPort is zero, this
value MUST also be zero. Otherwise, this MUST be a non-zero
value."
::= { natv2PortMapEntry 6 }
natv2PortMapInternalRealm OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The realm to which natv2PortMapInternalRealmAddress belongs.
In the general case, this realm contains the address that is
being translated. In the DS-Lite (RFC 6333) case, this realm
defines the IPv6 address space from which the tunnel source
address is taken. The realm of the encapsulated IPv4 address
is restricted in scope to the tunnel, so there is no point
in identifying it separately."
REFERENCE
"DS-Lite: RFC 6333."
Perreault, et al. Standards Track [Page 67]
RFC 7659 NAT MIB October 2015
::= { natv2PortMapEntry 7 }
natv2PortMapInternalAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Address type for addresses in the realm identified by
natv2PortMapInternalRealm."
::= { natv2PortMapEntry 8 }
natv2PortMapInternalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Source address for packets received under this mapping on
the internal side of the NAT instance. In the general case,
this address is the same as the address given in
natv2PortMapInternalMappedAddress. In the DS-Lite case,
natv2PortMapInternalAddress is the IPv6 tunnel source
address. The address type is given
by natv2PortMapInternalAddressType."
REFERENCE
"DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses)
and 6.6 (on the need to have the IPv6 tunnel address in
the NAT mapping tables)."
::= { natv2PortMapEntry 9 }
natv2PortMapInternalMappedAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Internal address type actually translated by this mapping.
Any value other than ipv4(1) or ipv6(2) would be unexpected.
In the general case, this is the same as given by
natv2AddressMapInternalAddressType. In the DS-Lite
case, the address type is ipv4(1)."
REFERENCE
"DS-Lite: RFC 6333."
::= { natv2PortMapEntry 10 }
natv2PortMapInternalMappedAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Perreault, et al. Standards Track [Page 68]
RFC 7659 NAT MIB October 2015
"Internal address actually translated by this mapping. In the
general case, this is the same as
natv2PortMapInternalRealmAddress. The address type is given
by natv2PortMapInternalMappedAddressType.
In the case of DS-Lite (RFC 6333), this is the source
address of the encapsulated IPv4 packet, normally selected
from the well-known range 192.0.0.0/29. The mapping in this
case is considered to be from the external address to the
combination of the IPv6 tunnel source address
natv2PortMapInternalRealmAddress and the well-known IPv4
inner source address natv2PortMapInternalMappedAddress."
REFERENCE
"DS-Lite: RFC 6333, Sections 5.7 (for well-known addresses)
and 6.6 (on the need to have the IPv6 tunnel address in
the NAT mapping tables)."
::= { natv2PortMapEntry 11 }
natv2PortMapInternalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The mapping's internal port number. If this is zero, ports
are not translated (i.e., the NAT instance is a pure NAT
rather than a Network Address and Port Translator (NAPT))."
::= { natv2PortMapEntry 12 }
natv2PortMapExternalPoolIndex OBJECT-TYPE
SYNTAX Natv2PoolIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Identifies the address pool from which the external address
in this port map entry was taken. Zero if the implementation
does not support address pools but has chosen to support
this object or if no pools are configured for the given
external realm."
::= { natv2PortMapEntry 13 }
natv2PortMapSubscriberIndex OBJECT-TYPE
SYNTAX Natv2SubscriberIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Subscriber using this map entry. Zero if the implementation
does not support subscribers but has chosen to support
this object."
Perreault, et al. Standards Track [Page 69]
RFC 7659 NAT MIB October 2015
::= { natv2PortMapEntry 14 }
-- Conformance section. Specifies three cumulatively more extensive
-- applications: basic NAT, pooled NAT, and carrier-grade NAT.
natv2MIBConformance OBJECT IDENTIFIER ::= { natv2MIB 3 }
natv2MIBCompliances OBJECT IDENTIFIER ::= { natv2MIBConformance 1 }
natv2MIBGroups OBJECT IDENTIFIER ::= { natv2MIBConformance 2 }
natv2MIBBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the basic NAT
application of NATV2-MIB."
MODULE -- this module
MANDATORY-GROUPS { natv2BasicNotificationGroup,
natv2BasicInstanceLevelGroup
}
::= { natv2MIBCompliances 1 }
natv2MIBPooledNATCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the pooled NAT
application of NATV2-MIB."
MODULE -- this module
MANDATORY-GROUPS { natv2BasicNotificationGroup,
natv2BasicInstanceLevelGroup,
natv2PooledNotificationGroup,
natv2PooledInstanceLevelGroup
}
::= { natv2MIBCompliances 2 }
natv2MIBCGNCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the
carrier-grade NAT application of NATV2-MIB."
MODULE -- this module
MANDATORY-GROUPS { natv2BasicNotificationGroup,
natv2BasicInstanceLevelGroup,
natv2PooledNotificationGroup,
natv2PooledInstanceLevelGroup,
natv2CGNNotificationGroup,
natv2CGNDeviceLevelGroup,
natv2CGNInstanceLevelGroup
}
Perreault, et al. Standards Track [Page 70]
RFC 7659 NAT MIB October 2015
::= { natv2MIBCompliances 3 }
-- Groups
natv2BasicNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
natv2NotificationInstanceAddressMapEntriesHigh,
natv2NotificationInstancePortMapEntriesHigh
}
STATUS current
DESCRIPTION
"Notifications that MUST be supported by all NAT
applications."
::= { natv2MIBGroups 1 }
natv2BasicInstanceLevelGroup OBJECT-GROUP
OBJECTS {
-- from natv2InstanceTable
natv2InstanceAlias,
natv2InstancePortMappingBehavior,
natv2InstanceFilteringBehavior,
natv2InstanceFragmentBehavior,
natv2InstanceAddressMapEntries,
natv2InstancePortMapEntries,
natv2InstanceTranslations,
natv2InstanceAddressMapCreations,
natv2InstanceAddressMapEntryLimitDrops,
natv2InstanceAddressMapFailureDrops,
natv2InstancePortMapCreations,
natv2InstancePortMapEntryLimitDrops,
natv2InstancePortMapFailureDrops,
natv2InstanceFragmentDrops,
natv2InstanceOtherResourceFailureDrops,
natv2InstanceDiscontinuityTime,
natv2InstanceThresholdAddressMapEntriesHigh,
natv2InstanceThresholdPortMapEntriesHigh,
natv2InstanceNotificationInterval,
natv2InstanceLimitAddressMapEntries,
natv2InstanceLimitPortMapEntries,
natv2InstanceLimitPendingFragments,
-- from natv2ProtocolTable
natv2ProtocolPortMapEntries,
natv2ProtocolTranslations,
natv2ProtocolPortMapCreations,
natv2ProtocolPortMapFailureDrops,
-- from natv2AddressMapTable
natv2AddressMapExternalRealm,
natv2AddressMapExternalAddressType,
Perreault, et al. Standards Track [Page 71]
RFC 7659 NAT MIB October 2015
natv2AddressMapExternalAddress,
-- from natv2PortMapTable
natv2PortMapInternalRealm,
natv2PortMapInternalAddressType,
natv2PortMapInternalAddress,
natv2PortMapInternalPort
}
STATUS current
DESCRIPTION
"Per-instance objects that MUST be supported by
implementations of all NAT applications."
::= { natv2MIBGroups 2 }
natv2PooledNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
natv2NotificationPoolUsageLow,
natv2NotificationPoolUsageHigh
}
STATUS current
DESCRIPTION
"Notifications that MUST be supported by pooled and
carrier-grade NAT applications."
::= { natv2MIBGroups 3 }
natv2PooledInstanceLevelGroup OBJECT-GROUP
OBJECTS {
-- from natv2InstanceTable
natv2InstancePoolingBehavior,
-- from natv2PoolTable
natv2PoolRealm,
natv2PoolAddressType,
natv2PoolMinimumPort,
natv2PoolMaximumPort,
natv2PoolAddressMapEntries,
natv2PoolPortMapEntries,
natv2PoolAddressMapCreations,
natv2PoolPortMapCreations,
natv2PoolAddressMapFailureDrops,
natv2PoolPortMapFailureDrops,
natv2PoolDiscontinuityTime,
natv2PoolThresholdUsageLow,
natv2PoolThresholdUsageHigh,
natv2PoolNotifiedPortMapEntries,
natv2PoolNotifiedPortMapProtocol,
natv2PoolNotificationInterval,
-- from natv2PoolRangeTable
natv2PoolRangeBegin,
natv2PoolRangeEnd,
Perreault, et al. Standards Track [Page 72]
RFC 7659 NAT MIB October 2015
-- from natv2AddressMapTable
natv2AddressMapExternalPoolIndex,
-- from natv2PortMapTable
natv2PortMapExternalPoolIndex
}
STATUS current
DESCRIPTION
"Per-instance objects that MUST be supported by
implementations of the pooled and carrier-grade
NAT applications."
::= { natv2MIBGroups 4 }
natv2CGNNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
natv2NotificationSubscriberPortMappingEntriesHigh
}
STATUS current
DESCRIPTION
"Notification that MUST be supported by implementations
of the carrier-grade NAT application."
::= { natv2MIBGroups 5 }
natv2CGNDeviceLevelGroup OBJECT-GROUP
OBJECTS {
-- from table natv2SubscriberTable
natv2SubscriberInternalRealm,
natv2SubscriberInternalPrefixType,
natv2SubscriberInternalPrefix,
natv2SubscriberInternalPrefixLength,
natv2SubscriberAddressMapEntries,
natv2SubscriberPortMapEntries,
natv2SubscriberTranslations,
natv2SubscriberAddressMapCreations,
natv2SubscriberPortMapCreations,
natv2SubscriberAddressMapFailureDrops,
natv2SubscriberPortMapFailureDrops,
natv2SubscriberDiscontinuityTime,
natv2SubscriberLimitPortMapEntries,
natv2SubscriberThresholdPortMapEntriesHigh,
natv2SubscriberNotificationInterval
}
STATUS current
DESCRIPTION
"Device-level objects that MUST be supported by the
carrier-grade NAT application."
::= { natv2MIBGroups 6 }
natv2CGNInstanceLevelGroup OBJECT-GROUP
Perreault, et al. Standards Track [Page 73]
RFC 7659 NAT MIB October 2015
OBJECTS {
-- from natv2InstanceTable
natv2InstanceSubscriberActiveLimitDrops,
natv2InstanceLimitSubscriberActives,
-- from natv2AddressMapTable
natv2AddressMapInternalMappedAddressType,
natv2AddressMapInternalMappedAddress,
natv2AddressMapSubscriberIndex,
-- from natv2PortMapTable
natv2PortMapInternalMappedAddressType,
natv2PortMapInternalMappedAddress,
natv2PortMapSubscriberIndex
}
STATUS current
DESCRIPTION
"Per-instance objects that MUST be supported by the
carrier-grade NAT application."
::= { natv2MIBGroups 7 }
END
5. Operational and Management Considerations
This section covers two particular areas of operations and
management: configuration requirements and transition from or
coexistence with the MIB module in [RFC4008].
5.1. Configuration Requirements
This MIB module assumes that the following information is configured
on the NAT device by means outside the scope of the present document
or is imposed by the implementation:
o the set of address realms to which the device connects;
o for the CGN application, per-subscriber information including
subscriber index, address realm, assigned prefix or address, and
(possibly) policies regarding address pool selection in the
various possible address realms to which the subscriber may
connect. In the particular case of DS-Lite [RFC6333] access, as
well as the assigned outer-layer (IPv6) prefix or address, the
subscriber information will include an inner (IPv4) source
address, usually 192.0.0.2;
o the set of NAT instances running on the device, identified by NAT
instance index and name;
Perreault, et al. Standards Track [Page 74]
RFC 7659 NAT MIB October 2015
o the port mapping, filtering, pooling, and fragment behavior for
each NAT instance;
o the set of protocols supported by each NAT instance;
o for the pooled NAT and CGN applications, address pool information
for each NAT instance, including for each pool the pool index,
address realm, address type, minimum and maximum port number, the
address ranges assigned to that pool, and policies for access to
that pool's resources;
o static address and port map entries.
As described in previous sections, this MIB module does provide read-
write objects for control of notifications (see especially
Section 3.1.2) and limiting of resource consumption (Section 3.1.1).
This document is written in advance of any practical experience with
the setting of these values and can thus provide only general
principles for how to set them.
By default, the MIB module definition disables notifications until
they are explicitly enabled by the operator, using the associated
threshold value to do so. To make use of the notifications, the
operator may wish to take the following considerations into account.
Except for the low address pool utilization notification, the
notifications imply that some sort of administrative action is
required to mitigate an impending shortage of a particular resource.
The choice of value for the triggering threshold needs to take two
factors into account: the volatility of usage of the given resource,
and the amount of time the operator needs to mitigate the potential
overload situation. That time could vary from almost immediate to
several weeks required to order and install new hardware or software.
To give a numeric example, if average utilization is going up 1% per
week but can vary 10% around that average in any given hour, and it
takes two weeks to carry through mitigating measures, the threshold
should be set to 88% of the corresponding limit (two weeks' growth
plus 10% volatility margin). If mitigating measures can be carried
out immediately, this can rise to 90%. For this particular example,
that change is insignificant, but in other cases the difference may
be large enough to matter in terms of reduced load on the management
plane.
The notification rate-limit settings really depend on the operator's
processes but are a tradeoff between reliably reporting the notified
condition and not having it overload the management plane.
Reliability rises in importance with the importance of the resource
Perreault, et al. Standards Track [Page 75]
RFC 7659 NAT MIB October 2015
involved. Thus, the default notification intervals defined in this
MIB module range from 10 seconds (high reliability) for the address
and port map entry thresholds up to 60 seconds (lower reliability)
for the per-subscriber port entry thresholds. Experience may suggest
better values.
The limits on number of instance-level address map and port map
entries and held fragments relate directly to memory allocations for
these tables. The relationship between number of map entries or
number of held fragments and memory required will be implementation-
specific. Hence it is up to the implementor to provide specific
advice on the setting of these limits.
The limit on simultaneous number of active subscribers is indirectly
related to memory consumption for map entries, but also to processor
usage by the NAT instance. The best strategy for setting this limit
would seem to be to leave it disabled during an initial period while
observing device processor utilization, then to implement a trial
setting while observing the number of blocked packets affected by the
new limit. The setting may vary by NAT instance if a suitable
estimator of likely load (e.g., total number of hosts served by that
instance) is available.
5.2. Transition from and Coexistence with NAT-MIB (RFC 4008)
A manager may have to deal with a mixture of devices supporting the
NAT-MIB module [RFC4008] and the NATV2-MIB module defined in the
present document. It is even possible that both modules are
supported on the same device. The following discussion brings out
the limits of comparability between the two MIB modules. A first
point to note is that NAT-MIB is primarily focused on configuration,
while NATV2-MIB is primarily focused on measurements.
To summarize the model used by [RFC4008]:
o The basic unit of NAT configuration is the interface.
o An interface connects to a single realm, either "private" or
"public". In principle that means there could be multiple
instances of one type of realm or the other, but the number is
physically limited by the number of interfaces on the NAT device.
o Before the NAT can operate on a given interface, an "address map"
has to be configured on it. The address map in [RFC4008] is
equivalent to the pool tables in the present document. Since just
one "address map" is configured per interface, this is the
equivalent of a single address pool per interface.
Perreault, et al. Standards Track [Page 76]
RFC 7659 NAT MIB October 2015
o The address binding and port binding tables are roughly equivalent
to the address map and port map tables in the present document in
their content, but they can be either unidirectional or
bidirectional. The model in [RFC4008] shows the address binding
and port binding as alternative precursors to session
establishment, depending on whether the device does address
translation only or address and port translation. In contrast,
NATV2-MIB assumes a model where bidirectional port mappings are
based on bidirectional address mappings that have conceptually
been established beforehand.
o The equivalent to an [RFC4008] session in NATV2-MIB would be a
pair of port map entries. The added complexity in [RFC4008] is
due to the modeling of NAT service types as defined in [RFC3489]
(the symmetric NAT in particular) instead of the more granular set
of behaviors described in [RFC4787]. (Note: [RFC3489] has been
obsoleted by [RFC5389].)
With regard to that last point, the mapping between [RFC3489] service
types and [RFC4787] NAT behaviors is as follows:
o A full cone NAT exhibits endpoint-independent port mapping
behavior and endpoint-independent filtering behavior.
o A restricted cone NAT exhibits endpoint-independent port mapping
behavior, but address-dependent filtering behavior.
o A port restricted cone NAT exhibits endpoint-independent port
mapping behavior, but address-and-port-dependent filtering
behavior.
o A symmetric NAT exhibits address-and-port-dependent port mapping
and filtering behaviors.
Note that these NAT types are a subset of the types that could be
configured according to the [RFC4787] behavioral classification used
in NATV2-MIB, but they include the two possibilities (full and
restricted cone NAT) that satisfy requirements REQ-1 and REQ-8 of
[RFC4787]. Note further that other behaviors defined in [RFC4787]
are not considered in [RFC4008].
Having established a context for discussion, we are now in a position
to compare the outputs provided to management from the [RFC4008] and
NATV2-MIB modules. This comparison relates to the ability to compare
results if testing with both MIBs implemented on the same device
during a transition period.
Perreault, et al. Standards Track [Page 77]
RFC 7659 NAT MIB October 2015
[RFC4008] provides three counters: incoming translations, outgoing
translations, and discarded packets, at the granularities of
interface, address map, and protocol, and incoming and outgoing
translations at the levels of individual address bind, address port
bind, and session entries. Implementation at the protocol and
address map levels is optional. NATV2-MIB provides a single total
(both directions) translations counter at the instance, protocol
within instance, and subscriber levels. Given the differences in
granularity, it appears that the only comparable measurement of
translations between the two MIB modules would be through aggregation
of the [RFC4008] interface counters to give a total number of
translations for the NAT instance.
NATV2-MIB has broken out the single discard counter into a number of
different counters reflecting the cause of the discard in more
detail, to help in troubleshooting. Again, with the differing levels
of granularity, the only comparable statistic would be through
aggregation to a single value of total discards per NAT instance.
Moving on to state variables, [RFC4008] offers counts of number of
"address map" (i.e., address pool) entries used (excluding static
entries) at the address map level and number of entries in the
address bind and address and port bind tables, respectively.
Finally, [RFC4008] provides a count of the number of sessions
currently using each entry in the address and port bind table. None
of these counts are directly comparable with the state values offered
by NATV2-MIB, because of the exclusion of static entries at the
address map level, and because of the differing models of the
translation tables between [RFC4008] and the NATV2-MIB.
6. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write. Such objects may be
considered sensitive or vulnerable in some network environments. The
support for SET operations in a non-secure environment without proper
protection opens devices to attack. These are the tables and objects
and their sensitivity/vulnerability:
Limits: An attacker setting a very low or very high limit can easily
cause a denial-of-service situation.
* natv2InstanceLimitAddressMapEntries;
* natv2InstanceLimitPortMapEntries;
* natv2InstanceLimitPendingFragments;
Perreault, et al. Standards Track [Page 78]
RFC 7659 NAT MIB October 2015
* natv2InstanceLimitSubscriberActives;
* natv2SubscriberLimitPortMapEntries.
Notification thresholds: An attacker setting an arbitrarily low
threshold can cause many useless notifications to be generated
(subject to the notification interval). Setting an arbitrarily
high threshold can effectively disable notifications, which could
be used to hide another attack.
* natv2InstanceThresholdAddressMapEntriesHigh;
* natv2InstanceThresholdPortMapEntriesHigh;
* natv2PoolThresholdUsageLow;
* natv2PoolThresholdUsageHigh;
* natv2SubscriberThresholdPortMapEntriesHigh.
Notification intervals: An attacker setting a low notification
interval in combination with a low threshold value can cause many
useless notifications to be generated.
* natv2InstanceNotificationInterval;
* natv2PoolNotificationInterval;
* natv2SubscriberNotificationInterval.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
Objects that reveal host identities: 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. If nothing else, unauthorized monitoring of these
objects will violate individual subscribers' privacy.
Perreault, et al. Standards Track [Page 79]
RFC 7659 NAT MIB October 2015
* entries in the natv2SubscriberTable;
* entries in the natv2AddressMapTable;
* entries in the natv2PortMapTable.
Other objects that reveal NAT state: Other managed objects in this
MIB may contain information that may be sensitive from a business
perspective, in that they may represent NAT capabilities, business
policies, and state information.
* natv2SubscriberLimitPortMapEntries;
* natv2InstancePortMappingBehavior;
* natv2InstanceFilteringBehavior;
* natv2InstancePoolingBehavior;
* natv2InstanceFragmentBehavior;
* natv2InstanceAddressMapEntries;
* natv2InstancePortMapEntries.
There are no objects that are sensitive in their own right, such as
passwords or monetary amounts.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
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 module.
Implementations SHOULD provide the security features described by the
SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
MAY also provide support for the Transport Security Model (TSM)
[RFC5591] in combination with a secure transport such as SSH
[RFC5592] or TLS/DTLS [RFC6353].
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
Perreault, et al. Standards Track [Page 80]
RFC 7659 NAT MIB October 2015
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
7. IANA Considerations
IANA has assigned an object identifier to the natv2MIB module, with
prefix iso.org.dod.internet.mgmt.mib-2 in the SMI Numbers registry
[SMI-NUMBERS].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>.
[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2",
STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
<http://www.rfc-editor.org/info/rfc2580>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<http://www.rfc-editor.org/info/rfc3411>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414,
DOI 10.17487/RFC3414, December 2002,
<http://www.rfc-editor.org/info/rfc3414>.
Perreault, et al. Standards Track [Page 81]
RFC 7659 NAT MIB October 2015
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826,
DOI 10.17487/RFC3826, June 2004,
<http://www.rfc-editor.org/info/rfc3826>.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005,
<http://www.rfc-editor.org/info/rfc4001>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
<http://www.rfc-editor.org/info/rfc5591>.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June
2009, <http://www.rfc-editor.org/info/rfc5592>.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
<http://www.rfc-editor.org/info/rfc6353>.
8.2. Informative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410,
DOI 10.17487/RFC3410, December 2002,
<http://www.rfc-editor.org/info/rfc3410>.
Perreault, et al. Standards Track [Page 82]
RFC 7659 NAT MIB October 2015
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
DOI 10.17487/RFC3489, March 2003,
<http://www.rfc-editor.org/info/rfc3489>.
[RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and
C. Wang, "Definitions of Managed Objects for Network
Address Translators (NAT)", RFC 4008,
DOI 10.17487/RFC4008, March 2005,
<http://www.rfc-editor.org/info/rfc4008>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC7658] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
"Deprecation of MIB Module NAT-MIB: Managed Objects for
Network Address Translators (NATs)", RFC 7658,
DOI 10.17487/RFC7658, October 2015,
<http://www.rfc-editor.org/info/rfc7658>.
[SMI-NUMBERS]
IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<http://www.iana.org/assignments/smi-number>.
Perreault, et al. Standards Track [Page 83]
RFC 7659 NAT MIB October 2015
Authors' Addresses
Simon Perreault
Jive Communications
Quebec, QC
Canada
Email: sperreault@jive.com
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
China
Email: tina.tsou.zouting@huawei.com
Senthil Sivakumar
Cisco Systems
7100-8 Kit Creek Road
Research Triangle Park, North Carolina 27709
United States
Phone: +1 919 392 5158
Email: ssenthil@cisco.com
Tom Taylor
PT Taylor Consulting
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
Perreault, et al. Standards Track [Page 84]