Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

in Index   Prev   Next
in Index   Prev   Next  Group: ~nat

RFC 7659

Definitions of Managed Objects for Network Address Translators (NATs)

Pages: 84
Proposed STD
Part 4 of 4 – Pages 74 to 84
First   Prev   None

Top   ToC   Page 74   prevText
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;

   o  the set of NAT instances running on the device, identified by NAT
      instance index and name;
Top   ToC   Page 75
   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

   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
Top   ToC   Page 76
   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.
Top   ToC   Page 77
   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

   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.
Top   ToC   Page 78
   [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;
Top   ToC   Page 79
      *  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

   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.
Top   ToC   Page 80
      *  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
Top   ToC   Page 81
   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 in the SMI Numbers registry

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,

   [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,

   [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,

   [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,

   [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,

   [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,
Top   ToC   Page 82
   [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,

   [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "Textual Conventions for Internet Network
              Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005,

   [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, <>.

   [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,

   [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, <>.

   [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,

8.2.  Informative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <>.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,

   [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,
Top   ToC   Page 83
   [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,

   [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,

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,

   [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,

   [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,

              IANA, "Structure of Management Information (SMI) Numbers
              (MIB Module Registrations)",
Top   ToC   Page 84
Authors' Addresses

   Simon Perreault
   Jive Communications
   Quebec, QC


   Tina Tsou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129


   Senthil Sivakumar
   Cisco Systems
   7100-8 Kit Creek Road
   Research Triangle Park, North Carolina  27709
   United States

   Phone: +1 919 392 5158

   Tom Taylor
   PT Taylor Consulting