One document matched: draft-perreault-opsawg-natmib-bis-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" ipr="trust200902" obsoletes="4008" docName="draft-perreault-opsawg-natmib-bis-00">
<front>
<title abbrev="NAT-MIB-bis">Definitions of Managed Objects for Network Address Translators (NAT)</title>
<author initials="S." surname="Perreault" fullname="Simon Perreault">
<organization>Viagenie</organization>
<address>
<postal>
<street>2875 boul. Laurier, suite D2-630</street>
<city>Quebec</city>
<country>Canada</country>
</postal>
<phone>+1-418-656-9254</phone>
<email>simon.perreault@viagenie.ca</email>
</address>
</author>
<author initials="T." surname="Tsou" fullname="Tina Tsou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<country>USA</country>
</postal>
<phone>+1-408-330-4424</phone>
<email>tena@huawei.com</email>
</address>
</author>
<date year="2011"/>
<abstract>
<t>This 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 configuration as well as monitoring of a
device capable of NAT function. This memo is a revision of the previous
NAT-MIB <xref target="RFC4008"/> to take into account new types of
NAT.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This memo defines a portion of the Management Information Base (MIB)
for devices implementing NAT function. This MIB module may be used for
configuration and monitoring of a device capable of NAT function. NAT
types and their characteristics are defined in <xref target="RFC2663"/>.
Traditional NAT function, in particular is defined in <xref
target="RFC3022"/>. This MIB does not address the firewall functions
and must not be used for configuring or monitoring these. <xref
target="framework"/> provides references to the SNMP management
framework, which was used as the basis for the MIB module definition.
<xref target="terminology"/> describes the terms used throughout the
document. <xref target="overview"/> provides an overview of the key
objects, their inter-relationship, and how the MIB module may be used to
configure and monitor a NAT device. Lastly, <xref target="mib"/> has
the complete NAT MIB definition.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Changes from RFC4008">
<t>TODO: Move this section to an appendix after initial reviews.</t>
<t>
<list style="symbols">
<t>Address pools can now be shared between multiple interfaces. This
change makes this MIB applicable to DS-Lite's AFTR <xref
target="RFC6333"/>. See [draft-schoenw-behave-nat-mib-bis-00] for
rationale.</t>
<t>TODO: Merge CGN stuff from draft-jpdionne-behave-cgn-mib.</t>
<t>TODO: Merge NAT64 stuff from draft-jpdionne-behave-nat64-mib.</t>
<t>TODO: Update to RFC 4787 terminology for describing NAT
behavior.</t>
<t>TODO: Support protocols other than UDP and TCP.</t>
<t>TODO: Add support to limit and/or throttle binding allocations.</t>
<t>TODO: Clarify existing notifications (e.g., natPacketDiscard) and
add any additional notifications that may be needed for binding
limits / binding throttling.</t>
<t>TODO: Are we missing anything for PCP support? (time-limited static
entries)</t>
<t>TODO: Include (for example in an appendix) a description plus
examples how the revised NAT-MIB can be used by NAT64
implementations, CGNs, and DS- Lite implementations.</t>
</list>
</t>
</section>
<section title="The Internet-Standard Management Framework" anchor="framework">
<t>For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of <xref target="RFC3410"/>.</t>
<t>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 STD 58, RFC 2578 <xref target="RFC2578"/>, STD 58, RFC 2579 <xref target="RFC2579"/> and STD 58, RFC 2580 <xref target="RFC2580"/>.</t>
</section>
<section title="Terminology" anchor="terminology">
<t>
[To be Reviewed]
</t>
<t>
Definitions for a majority of the terms used throughout the document may be found in <xref target="RFC2663"/>. Additional terms that further
classify NAPT implementations are defined in <xref target="RFC3489"/>. Listed below are terms used in this document.
</t>
<t>
Address realm - An address realm is a realm of unique network
addresses that are routable within the realm. For example, an
enterprise address realm could be constituted of private IP addresses
in the ranges specified in <xref target="RFC1918"/>, which are routable
within the enterprise, but not across the Internet. A public realm
is constituted of globally unique network addresses.
</t>
<t>
Symmetric NAT - Symmetric NAT, as defined in <xref target="RFC3489"/>, is a
variation of Network Address Port Translator (NAPT). Symmetric NAT
does not use port bind for translation across all sessions
originating from the same private host. Instead, it assigns a new
public port to each new session, irrespective of whether the new
session used the same private end-point as before.
</t>
<t>
Bind or Binding - Several variations of the term 'Bind' (or
'Binding') are used throughout the document. Address Bind (or
Address Binding) is a tuple of (Private IP address, Public IP
Address) used for translating an IP address end-point in IP packets. Port Bind (or, Port Binding, or Address Port Bind, or Address Port
Binding) is a tuple of (transport protocol, Private IP address,
Private port, Public IP Address, Public port) used for translating a port end-point tuple of (transport protocol, IP address, port). Bind is used to refer to either Address Bind or Port Bind. Bind Mode
identifies whether a bind is Address Bind or Port Bind.
</t>
<t>
NAT Session - A NAT session is an association between a session as
seen in the private realm and a session as seen in the public realm,
by virtue of NAT translation. If a session in the private realm were
to be represented as (PrivateSrcAddr, PrivateDstAddr,
TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same
session in the public realm were to be represented as (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the
NAT session will provide the translation glue between the two session
representations. NAT sessions in the document are restricted to
sessions based on TCP and UDP only. In the future, NAT sessions may
be extended to be based on other transport protocols such as SCTP,
UDP-lite and DCCP.
</t>
<t>
The terms 'local' and 'private' are used interchangeably throughout
the document when referring to private networks, IP addresses, and
ports. Likewise, the terms 'global' and 'public' are used
interchangeably when referring to public networks, IP addresses, and
ports.
</t>
</section>
<section title="Overview" anchor="overview">
<t>
NAT MIB is configurable on a per-interface basis and depends in
several parts on the IF-MIB <xref target="RFC2863"/>.
</t>
<t>
NAT MIB requires that an interface for which NAT is configured be
connected to either a private or a public realm. The realm
association of the interface plays an important role in the
definition of address maps for the interface. An address map entry
identifies the orientation of the session (inbound or outbound to the
interface) for which the entry may be used for NAT translation. The
address map entry also identifies the end-point of the session that
must be subject to translation. An SNMP Textual-Convention
'NatTranslationEntity' is defined to capture this important
characteristic that combines session orientation and applicable
session endpoint for translation.
</t>
<t>
An address map may consist of static or dynamic entries. NAT creates
static binds from a static address map entry. Each static bind has a
direct one-to-one relationship with a static address map entry. NAT
creates dynamic binds from a dynamic address map entry upon seeing
the first packet of a new session.
</t>
<t>
The following subsections define the key objects used in NAT MIB,
their inter-relationship, and how to configure a NAT device using the
MIB module.
</t>
<section title="natInterfaceTable" anchor="natInterfaceTable">
<t>
[To be reviewed]
</t>
<t>
natInterfaceTable is defined in the MIB module to configure interface
specific realm type and the NAT services enabled for the interface.
natInterfaceTable is indexed by ifIndex and also includes interface
specific NAT statistics.
</t>
<t>
The first step for an operator in configuring a NAT device is
determining the interface over which NAT service is to be configured.
When NAT service is operational, translated packets traverse the NAT
device by ingressing on a private interface and egressing on a public
interface or vice versa. An operator may configure the NAT service
on either the public interface or the private interface in the
traversal path.
</t>
<t>
As the next step, the operator must identify the NAT service(s)
desired for the interface. The operator may configure one or more
NAT services on the same interface. The MIB module identifies four
types of NAT services: Basic NAT, NAPT, twice NAT and bidirectional
NAT. These are NAT varieties as defined in <xref target="RFC2663"/>. Note
that <xref target="RFC3489"/> further classifies NAPT implementations based
on the behavior exhibited by the NAPT devices from different vendors.
However, the MIB module does not explicitly distinguish between the
NAPT implementations. NAPT implementations may be distinguished
between one another by monitoring the BIND and NAT Session objects
generated by the NAT device as described in section <xref target="napt"/>.
</t>
</section>
<section title="natAddrMapTable" anchor="natAddrMapTable">
<t>
[To be reviewed]
</t>
<t>natAddrMapTable is defined in the MIB module to configure address
maps on a per-interface basis. natAddrMapTable is indexed by the
tuple of (ifIndex, natAddrMapIndex). The same table is also used to
collect Statistics for the address map entries. Address maps are key
to NAT configuration. An operator may configure one or more address
map entries per interface. NAT looks up address map entries in the
order in which they are defined to determine the translation function
at the start of each new session traversing the interface. An address
map may consist of static or dynamic entries. A static address map
entry has a direct one-to-one relationship with binds. NAT will
dynamically create binds from a dynamic address map entry.</t>
<t>The operator must be careful in selecting address map entries for an
interface based on the interface realm-type and the type of NAT
service desired. The operator can be amiss in the selection of
address map entries when not paying attention to the associated
interface characteristics defined in natInterfaceTable (described in
section 4.1). For example, say the operator wishes to configure a
NAPT map entry on an interface of a NAT device. If the operator
chooses to configure the NAPT map entry on a public interface (i.e.,
interface realm-type is public), the operator should set the
TranslationEntity of the NAPT address map entry to be
outboundSrcEndPoint. On the other hand, if the operator chooses to
configure the NAPT map entry on a private interface (i.e., interface
realm-type is private), the operator should set the TranslationEntity
of the NAPT address map entry to be InboundSrcEndPoint.</t>
</section>
<section title="Default Timeouts, Protocol Table, and Other Scalars"
anchor="defaults">
<t>[To be reviewed]</t>
<t>DefTimeouts is defined in the MIB module to configure idle Bind
timeout and IP protocol specific idle NAT session timeouts. The
timeouts defined are global to the system and are not interface
specific.</t>
<t>Protocol specific statistics are maintained in natProtocolTable,
which is indexed by the protocol type.</t>
<t>The scalars natAddrBindNumberOfEntries and
natAddrPortBindNumberOfEntries hold the number of entries that
currently exist in the Address Bind and the Address Port Bind tables,
respectively.</t>
<t>The generation of natPacketDiscard notifications can be configured by
using the natNotifThrottlingInterval scalar MIB object.</t>
</section>
<section title="natAddrBindTable and natAddrPortBindTable">
<t>[To be reviewed]</t>
<t>Two Bind tables, natAddrBindTable and natAddrPortBindTable, are
defined to hold the bind entries. Entries are derived from the
address map table and are not configurable. natAddrBindTable contains
Address Binds, and natAddrPortBindTable contains Address Port Binds.
natAddrBindTable is indexed by the tuple of (ifIndex, LocalAddrType,
LocalAddr). natAddrPortBindTable is indexed by the tuple of (ifIndex,
LocalAddrType, LocalAddr, LocalPort, Protocol). These tables also
maintain bind specific statistics. A Symmetric NAT will have no
entries in the Bind tables.</t>
</section>
<section title="natSessionTable">
<t>[To be reviewed]</t>
<t>natSessionTable is defined to hold NAT session entries. NAT session
entries are derived from NAT Binds (except in the case of Symmetric
NAT) and are not configurable.</t>
<t>The NAT session provides the necessary translation glue between two
session representations of the same end-to-end session; that is, a
session as seen in the private realm and in the public realm. Session
orientation (inbound or outbound) is determined from the orientation
of the first packet traversing the NAT interface. Address map entries
and bind entries on the interface determine whether a session is
subject to NAT translation. One or both endpoints of a session may be
subject to translation.</t>
<t>With the exception of symmetric NAT, all other NAT functions use
end-point specific bind to perform individual end-point translations.
Multiple NAT sessions would use the same bind as long as they share
the same endpoint. Symmetric NAT does not retain a consistent port
bind across multiple sessions using the same endpoint. For this
reason, the bind identifier for a NAT session in symmetric NAT is set
to zero. natSessionTable is indexed by the tuple of (ifIndex,
natSessionIndex). Statistics for NAT sessions are also maintained in
the same table.</t>
</section>
<section title="RFC 3489 NAPT Variations, NAT Session and Bind Tables"
anchor="napt">
<t>
[To be reviewed, translate to new terminology]
</t>
<t><xref target="RFC3489"/> defines four variations of NAPT - Full Cone, Restricted
Cone, Port Restricted Cone, and Symmetric NAT. These can be
differentiated in the NAT MIB based on different values for the
objects in the session and the bind tables, as indicated below.
</t>
<t>
In a Port Restricted Cone NAT, NAT Session objects will contain a
non-zero PrivateSrcEPBindId object. Further, all address and port
objects within a NAT session will have non-zero values (i.e., no
wildcard matches).
</t>
<t>
An Address Restricted Cone NAT may have been implemented in the same
way as a Port Restricted Cone NAT, except that the UDP NAT Sessions
may use ANY match on PrivateDstPort and PublicDstPort objects; i.e.,
PrivateDstPort and PublicDstPort objects within a NAT session may be
set to zero.
</t>
<t>
A Full Cone NAT may have also been implemented in the same way as a
Port Restricted Cone NAT, except that the UDP NAT Sessions may use
ANY match on PrivateDstAddr, PrivateDstPort, PublicDstAddr, and
PublicDstPort objects. Within a NAT Session, all four of these
objects may be set to zero. Alternately, all address and port
objects within a NAT Session may have non-zero values, yet the
TranslationEntity of the PrivateSrcEPBindId for the NAT Sessions may
be set bi-directionally, i.e., as a bit mask of (outboundSrcEndPoint
and inboundDstEndPoint) or (inboundSrcEndPoint and
outboundDstEndPoint), depending on the interface realm type. Lastly,
a Symmetric NAT does not maintain Port Bindings. As such, the NAT
Session objects will have the PrivateSrcEPBindId set to zero.
</t>
</section>
<section title="Notifications">
<t>
[To be reviewed]
</t>
<t>
natPacketDiscard notifies the end user/manager of packets being
discarded due to lack of address mappings.
</t>
<t>
[Port exhaustion, CGN-MIB?]
</t>
</section>
<section title="Notifications">
<t>
[To be reviewed]
</t>
<t>
The association between the various NAT tables can be represented as
follows:
</t>
<figure>
<artwork><![CDATA[
Interface
|
|
|
Address map
|
|
|
----------------------------------------------
| |
| |
| |
Address Bind Port Bind
| |
| |
| |
----------------------------------------------
|
|
|
NAT Session
]]></artwork>
</figure>
<t>All NAT functions, with the exception of Symmetric NAT, use Bind(s)
to provide the glue necessary for a NAT Session.
natSessionPrivateSrcEPBindId and natSessionPrivateDstEPBindId objects
represent the endpoint Binds used by NAT Sessions.</t>
</section>
<section title="Configuration via the MIB">
<t>
[To be reviewed]
</t>
<t>
<xref target="natInterfaceTable"/>, and <xref
target="natAddrMapTable"/> and part of <xref target="defaults"/>
refer to objects that are configurable on a NAT device. NAT derives
Address Bind and Address Port Bind entries from the Address Map table.
Hence, an Address Bind or an Address Port Bind entry must not exist
without an associated entry in the Address Map table.
</t>
<t>
Further, NAT derives NAT session entries from NAT Binds, except in
the case of symmetric NAT, which derives translation parameters for a
NAT session directly from an address map entry. Hence, with the
exception of Symmetric NAT, a NAT session entry must not exist in the
NAT Session table without a corresponding bind.
</t>
<t>
A Management station may use the following steps to configure entries
in the NAT-MIB:
<list style="symbols">
<t>Create an entry in the natInterfaceTable specifying the value of
ifIndex as the interface index of the interface on which NAT is
being configured. Specify appropriate values, as applicable, for
the other objects (e.g., natInterfaceRealm,
natInterfaceServiceType) in the table (refer to <xref
target="natInterfaceTable"/>).</t>
<t>Create one or more address map entries sequentially in reduced
order of priority in the natAddrMapTable, specifying the value of
ifIndex to be the same for all entries. The ifIndex specified
would be the same as that specified for natInterfaceTable (refer
to <xref target="natAddrMapTable"/>).</t>
<t>Configure the maximum permitted idle time duration for BINDs and
TCP, UDP, and ICMP protocol sessions by setting the relevant scalars in
natDefTimeouts object (refer to <xref target="defaults"/>).</t>
</list>
</t>
</section>
<section title="Relationship to Interface MIB">
<t>
[To be reviewed, relationship to other MIB?]
</t>
<t>
The natInterfaceTable specifies the NAT configuration attributes
on each interface. The concept of "interface" is as defined by
InterfaceIndex/ifIndex of the IETF Interfaces MIB <xref target="RFC2863"/>.
</t>
</section>
</section>
<section title="Definitions" anchor="mib">
<t>
This MIB module IMPORTs objects from <xref target="RFC2578"/>, <xref target="RFC2579"/>, <xref target="RFC2580"/>, <xref target="RFC2863"/>,
<xref target="RFC3411"/>, and <xref target="RFC4001"/>. It also refers to
information in <xref target="RFC0792"/>, <xref target="RFC2463"/>, and <xref target="RFC3413"/>.
</t>
<figure>
<artwork><?rfc include="NAT-MIB-bis.mib"?></artwork>
</figure>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank R. Rohit, P. Srisuresh, Rajiv
Raghunarayan, Nalinksh Pai, and Cliff Wang, the original authors of
<xref target="RFC4008"/>, as well as the following individuals who have
participated in the drafting, review, and discussion of this memo:</t>
<t>
Cathy Zhou,
Juergen Schoenwaelder,
Marc Blanchet,
and Yu Fu.
</t>
</section>
<section title="Security Considerations">
<t>[To be reviewed, note about large number of mappings/bindings]</t>
<t> It is clear that this MIB can potentially be useful for
configuration. 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.</t>
<t>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.
</t>
<t>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 bind and session information. The NAT
bind and session objects reveal the identity of private hosts that
are engaged in a session with external end nodes. A curious outsider
could monitor these two objects to assess the number of private hosts
being supported by the NAT device. Further, a disgruntled former
employee of an enterprise could use the NAT bind and session
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.</t>
<t>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.</t>
<t> It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework (see <xref target="RFC3410"/>, section
8), including full support for the SNMPv3 cryptographic mechanisms
(for authentication and privacy).
</t>
<t> 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.</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2578.xml"?>
<?rfc include="reference.RFC.2579.xml"?>
<?rfc include="reference.RFC.2580.xml"?>
<?rfc include="reference.RFC.3022.xml"?>
<?rfc include="reference.RFC.2663.xml"?>
<?rfc include="reference.RFC.4001.xml"?>
<?rfc include="reference.RFC.0792.xml"?>
<?rfc include="reference.RFC.3489.xml"?>
<?rfc include="reference.RFC.2863.xml"?>
<?rfc include="reference.RFC.2463.xml"?>
<?rfc include="reference.RFC.3411.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3413.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1918.xml"?>
<?rfc include="reference.RFC.3410.xml"?>
<?rfc include="reference.RFC.4008.xml"?>
<?rfc include="reference.RFC.6333.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:52:52 |