One document matched: draft-ietf-behave-ipfix-nat-logging-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-behave-ipfix-nat-logging-06"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IPFIX IEs for NAT logging">IPFIX Information Elements for logging NAT Events</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Senthil Sivakumar" initials="S." surname="Sivakumar">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7100-8 Kit Creek Road</street>
<!-- Reorder these if your country does things differently -->
<city>Research Triangle Park</city>
<region>North Carolina</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919 392 5158</phone>
<email>ssenthil@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Renaldo Penno" initials="R." surname="Penno">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>California</region>
<code>95035</code>
<country>USA</country>
</postal>
<phone></phone>
<email>repenno@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="January" year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Behave</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t> Network operators require NAT devices to log events like creation and deletion of
translations and information about the resources that the NAT device is managing. The
logs are essential in many cases to identify an attacker or a host
that was used to launch malicious attacks and for various other
purposes of accounting. Since there is no standard way of logging
this information, different NAT devices log the information using proprietary formats
and hence it is difficult to expect a consistent behavior. The lack of a
consistent way to log the data makes it difficult to write the collector applications
that would receive this data and process it to present useful
information. This document describes the formats for logging of NAT events.
</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>The usage of the term "NAT device" in this document refer to any
NAT44 and NAT64 devices. The usage of the term "collector"
refers to any device that receives the binary data from a NAT device and
converts that into meaningful information. This document uses the term
"Session" as it is defined in <xref target="RFC2663"> </xref> and the
term BIB as it is defined in <xref target="RFC6146"></xref>. The usage
of the term Information Element (IE) is defined in
[RFC7011].</t>
<t> The IPFIX Information elements that are NAT specific are created with
NAT terminology. In order to avoid creating duplicate IE's, IE's
that are reused if they convey the same meaning. However, that causes
confusion in terminology used in NAT specific terms and IPFIX IE's.
Any non-IPFIX terminology used to convey NAT events are described
in this section. </t>
<t> The document uses the term timestamp for the Information element which
defines the time when an event is logged, this is the same as IPFIX
term observationTimeMilliseconds as described in [IPFIX-IANA]. Since
observationTimeMilliseconds is not self explanatory for NAT implementors,
this document uses the term timeStamp. </t>
</section>
<section title="Introduction">
<t>The IPFIX Protocol [RFC7011] defines a generic push mechanism for exporting information
and events. The IPFIX Information Model [IPFIX-IANA] defines a set of standard Information Elements
(IEs) which can be carried by the IPFIX protocol. This document details the IPFIX Information
Elements(IEs) that MUST be logged by a NAT device that supports NAT logging using IPFIX.
The document will specify the
format of the IE's that SHOULD be logged by the NAT device and all the optional fields. The
fields specified in this document are gleaned from <xref target="RFC4787"></xref> and <xref
target="RFC5382"></xref>.</t>
<t>
This document and [I-D.behave-syslog-nat-logging] are written in order to standardize
the events and parameters to be recorded, using IPFIX [RFC7011]
and SYSLOG [RFC5424]respectively. The intent is to provide a consistent
way to log information irrespective of the mechanism that is used.</t>
<section title="Requirements Language">
<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"></xref>.</t>
</section>
</section>
<section title="Scope">
<t>This document provides the information model to be used for logging
the NAT events including Carrier Grade NAT (CGN) events. This document focuses exclusively on
the specification of IPFIX IE's.
[RFC7011] provides guidance on the
choices of the transport protocols used for IPFIX and their effects. This document does not provide
guidance on the transport protocol like TCP, UDP or
SCTP that is to be used to log NAT events.
The log events SHOULD NOT be lost but the choice of the actual transport
protocol is beyond the scope of this document.</t>
<t>The existing IANA IPFIX IEs registry [IPFIX-IANA]
already has assignments for most of the NAT logging events. This document
uses the allocated IPFIX IE's and will request IANA for the ones that
are defined in this document but not yet allocated. </t>
<t>This document assumes that the NAT device will use the existing
IPFIX framework to send the log events to
the collector. This would mean that the NAT device will specify the template
that it is going to use for each of the events.
The templates can be of varying length and there could be multiple
templates that a NAT device could use to log the events. </t>
<t>The implementation details of the collector application is beyond the
scope of this document.</t>
<t>The optimization of logging the NAT events is left to the
implementation and is beyond the scope of this document.</t>
</section>
<section title="Applicability">
<t>NAT logging based on IPFIX uses binary encoding and hence is very efficient.
IPFIX based logging is recommended for environments where a high volume of logging is
required, for example, where per-flow logging is needed or in case of Carrier Grade NAT.
However, IPFIX based logging requires a collector that processes the binary
data and requires a network management application that converts this binary
data to a human readable format.</t>
</section>
<section title="Event based logging">
<t>An event in a NAT device can be viewed as a state transition as it relates
to the management of NAT resources. The creation and deletion of NAT
sessions and bindings are examples of events as it results in the
resources (addresses and ports) being allocated or freed. The events can
happen either through the processing of data packets flowing through the
NAT device or through an external entity installing policies on the NAT
router or as a result of an asynchronous event like a timer.
The list of events are provided in Section 4.1. Each of these
events SHOULD be logged, unless they are administratively prohibited. A
NAT device MAY log these events to multiple collectors if redundancy is
required. The network administrator will specify the collectors to which
the log records are to be sent.</t>
<t> A collector may receive NAT events from multiple CGN devices and MUST be able
to distinguish between the devices. Each CGN device should have a unique source ID to
identify themselves. The source ID is part of the IPFIX template and data exchange.</t>
<t> Prior to logging any events, the NAT device MUST send the template of
the record to the collector to advertise the format of the data record
that it is using to send the events. The templates can be exchanged as
frequently as required given the reliability of the connection. There SHOULD
be a configurable timer for controlling the template refresh. NAT
device SHOULD combine as many events as possible in a single packet to
effectively utilize the network bandwidth.</t>
<section title="Logging of destination information">
<t> Logging of destination information in a NAT event has been discussed in
<xref target="RFC6302"></xref> and
<xref target="RFC6888"></xref>.
Logging of destination information increases the size of each record and
increases the need for storage considerably. It increases the number of log events
generated because when the same user connects to a different destination,
it results in a log record per destination address. Logging of destination
information also results in the loss of privacy and hence should be done with caution.
However, this draft provides the necessary fields to log the destination information
in cases where they should be logged.
</t>
</section>
<section title="Information Elements">
<t>The templates could contain a subset of the Information
Elements(IEs) shown in Table 1 depending upon the event being logged.
For example a NAT44 session creation template record will contain,</t>
<t>{sourceIPv4Adress, postNATSourceIPv4Address,
destinationIpv4Address, postNATDestinationIPv4Address,
sourceTransportPort, postNAPTSourceTransportPort,
destinationTransportPort, postNAPTDestTransportPort,
internalAddressRealm, natEvent, timeStamp}</t>
<t>An example of the actual event data record is shown below - in a
human readable form</t>
<t>{192.168.16.1, 201.1.1.100, 207.85.231.104, 207.85.231.104, 14800,
1024, 80, 80, 0, 1, 09:20:10:789}</t>
<t>A single NAT device could be exporting multiple templates and the
collector MUST support receiving multiple templates from the same
source.
<vspace blankLines='50' />
</t>
<t> The following is the table of all the IE's that a NAT device would need
to export the events. The formats of the IE's and the IPFIX IDs are listed
below. Some of the IPFIX IE's are not assigned yet, and hence the detailed
description of these fields are requested in the IANA considerations section.
</t>
<texttable anchor="Template_table" title="Template format Table">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="right">IANA IPFIX ID</ttcol>
<ttcol align="center">Description</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>323</c>
<c>System Time when the event occured.</c>
<c>natInstanceId</c>
<c>32</c>
<c>TBD</c>
<c>NAT Instance Identifier</c>
<c>vlanID</c>
<c>16</c>
<c>58</c>
<c>VLAN ID in case of overlapping networks</c>
<c>ingressVRFID</c>
<c>32</c>
<c>234</c>
<c>VRF ID in case of overlapping networks</c>
<c>sourceIPv4Address</c>
<c>32</c>
<c>8</c>
<c>Source IPv4 Address</c>
<c>postNATSourceIPv4Address</c>
<c>32</c>
<c>225</c>
<c>Translated Source IPv4 Address</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>4</c>
<c>Transport protocol</c>
<c>sourceTransportPort</c>
<c>16</c>
<c>7</c>
<c>Source Port</c>
<c>postNAPTsourceTransportPort</c>
<c>16</c>
<c>227</c>
<c>Translated Source port</c>
<c>destinationIPv4Address</c>
<c>32</c>
<c>12</c>
<c>Destination IPv4 Address</c>
<c>postNATDestinationIPv4Address</c>
<c>32</c>
<c>226</c>
<c>Translated IPv4 destination address</c>
<c>destinationTransportPort</c>
<c>16</c>
<c>11</c>
<c>Destination port</c>
<c>postNAPTdestinationTransportPort</c>
<c>16</c>
<c>228</c>
<c>Translated Destination port</c>
<c>sourceIPv6Address</c>
<c>27</c>
<c>128</c>
<c>Source IPv6 address</c>
<c>destinationIPv6Address</c>
<c>128</c>
<c>28</c>
<c>Destination IPv6 address</c>
<c>postNATSourceIPv6Address</c>
<c>128</c>
<c>281</c>
<c>Translated source IPv6 addresss</c>
<c>postNATDestinationIPv6Address</c>
<c>128</c>
<c>282</c>
<c>Translated Destination IPv6 address</c>
<c>internalAddressRealm</c>
<c>8</c>
<c>TBD</c>
<c>Source Address Realm</c>
<c>externalAddressRealm</c>
<c>8</c>
<c>TBD</c>
<c>Destination Address Realm</c>
<c>natEvent</c>
<c>8</c>
<c>230</c>
<c>Type of Event</c>
<c>portRangeStart</c>
<c>16</c>
<c>361</c>
<c>Allocated port block start</c>
<c>portRangeEnd</c>
<c>16</c>
<c>362</c>
<c>Allocated Port block end</c>
<c>natPoolID</c>
<c>32</c>
<c>283</c>
<c> NAT pool Identifier </c>
<c>natLimitEvent</c>
<c>32</c>
<c>TBD</c>
<c>Limit event identifier</c>
<c>natThresholdEvent</c>
<c>32</c>
<c>TBD</c>
<c>Threshold event identifier</c>
</texttable>
</section>
<!-- End of section IEs above -->
<section title="Definition of NAT Events">
<t>The following are the list of NAT events and the proposed event
values. The list can be expanded in the future as necessary. The data
record will have the corresponding natEvent value to identify the
event that is being logged.</t>
<texttable anchor="event_id_table" title="NAT Event ID table">
<ttcol align="center">Event Name</ttcol>
<ttcol align="right">Values</ttcol>
<c>NAT44 Session create</c>
<c>1</c>
<c>NAT44 Session delete</c>
<c>2</c>
<c>NAT Addresses exhausted</c>
<c>3</c>
<c>NAT64 Session create</c>
<c>4</c>
<c>NAT64 Session delete</c>
<c>5</c>
<c>NAT44 BIB create</c>
<c>6</c>
<c>NAT44 BIB delete</c>
<c>7</c>
<c>NAT64 BIB create</c>
<c>8</c>
<c>NAT64 BIB delete</c>
<c>9</c>
<c>NAT ports exhausted</c>
<c>10</c>
<c>Quota exceeded</c>
<c>11</c>
<c>Address binding create</c>
<c>12</c>
<c>Address binding delete</c>
<c>13</c>
<c>Port block allocation</c>
<c>14</c>
<c>Port block de-allocation</c>
<c>15</c>
<c>Threshold reached</c>
<c>16</c>
</texttable>
</section>
<section title="Quota exceeded Event types">
<t> The Quota exceeded events are generated when the hard limits set by the administrator
has reached or exceeded.
The following table shows the sub event types for the Quota exceeded or limits
reached event. The events that can be reported are the Maximum session entries
limit reached, Maximum BIB entries limit reached, Maximum session/BIB entries per
user limit reached and maximum subscribers or hosts limit reached. </t>
<texttable anchor="limid_id_table" title="Quota Exceeded event table">
<ttcol align="center">Quota Exceeded Event Name</ttcol>
<ttcol align="right">Values</ttcol>
<c>Maximum Session entries </c>
<c>1</c>
<c>Maximum BIB entries </c>
<c>2</c>
<c>Maximum entries per user</c>
<c>3</c>
<c> Maximum active hosts or subscribers </c>
<c>4</c>
<c> Maximum fragments pending reassembly </c>
<c>5</c>
</texttable>
</section>
<section title="Threshold reached Event types">
<t> The following table shows the sub event types for the threshold reached event. The
administrator can configure the thresholds and whenever the threshold is reached or
exceeded, the corresponding events are generated. The main difference between
Quota Exceeded and the Threshold reached events is that, once the Quota exceeded
events are hit, the packets are dropped or mappings wont be created etc, whereas,
the threshold reached events will provide the operator a chance to take action before
the traffic disruptions can happen. A NAT device can choose to implement one or the
other or both.
</t>
<t> The address pool high threshold event will be reported when the address pool reaches
a high water mark as defined by the operator. This will serve as an indication that
the operator might have to add more addresses to the pool or an indication that the
subsequent users may be denied NAT translation mappings. </t>
<t> The address and port mapping high threshold event is generated, when the number of ports
in the configured address pool has reached a configured threshold. </t>
<t> The per-user address and port mapping high threshold is generated when a single user
uses more address and port mapping than a configured threshold. </t>
<texttable anchor="threshold_id_table" title="Threshold event table">
<ttcol align="center">Threshold Exceeded Event Name</ttcol>
<ttcol align="right">Values</ttcol>
<c> Address pool high threshold event</c>
<c>1</c>
<c> Address pool low threshold event </c>
<c>2</c>
<c> Address and port mapping high threshold event </c>
<c>3</c>
<c> Address and port mapping per user high threshold event </c>
<c>4</c>
<c> Global Address mapping high threshold event </c>
<c>5</c>
</texttable>
</section>
<section title="Templates for NAT Events">
<t>The following is the template of events that will be logged.
The events below are identified at the time of this writing but
the set of events is extensible. Depending on the implementation and
configuration various IE's specified can be included or ignored.</t>
<section title="NAT44 create and delete session events">
<t>These events will be generated when a NAT44 session is created or
deleted. The template will be the same, the natEvent will indicate
whether it is a create or a delete event. The following is a
template of the event.</t>
<t> The destination address and port information is optional as required
by <xref target="RFC6888"> </xref>. However, when the destination information
is suppressed, the session log event contains the same information as the
BIB event. In such cases, the NAT device SHOULD NOT send both BIB and session
events.
</t>
<texttable anchor="event_template_table"
title="NAT44 Session delete/create template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>postNATSourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>Yes</c>
<c>sourceTransportPort</c>
<c>16</c>
<c>Yes</c>
<c>postNAPTsourceTransportPort</c>
<c>16</c>
<c>Yes</c>
<c>destinationIPv4Address</c>
<c>32</c>
<c>No</c>
<c>postNATDestinationIPv4Address</c>
<c>32</c>
<c>No</c>
<c>destinationTransportPort</c>
<c>16</c>
<c>No</c>
<c>postNAPTdestinationTransportPort</c>
<c>16</c>
<c>No</c>
<c>internalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>externalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
</texttable>
</section>
<!-- End of section nat44 create/delete above -->
<section title="NAT64 create and delete session events">
<t>These events will be generated when a NAT64 session is created or deleted. The
following is a template of the event.</t>
<texttable anchor="nat64_session_event_template_table"
title="NAT64 session create/delete event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv6Address</c>
<c>128</c>
<c>Yes</c>
<c>postNATSourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>Yes</c>
<c>sourceTransportPort</c>
<c>16</c>
<c>Yes</c>
<c>postNAPTsourceTransportPort</c>
<c>16</c>
<c>Yes</c>
<c>destinationIPv6Address</c>
<c>128</c>
<c>No</c>
<c>postNATDestinationIPv4Address</c>
<c>32</c>
<c>No</c>
<c>destinationTransportPort</c>
<c>16</c>
<c>No</c>
<c>postNAPTdestinationTransportPort</c>
<c>16</c>
<c>No</c>
<c>internalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>externalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
</texttable>
</section>
<!-- End of section nat64 delete/create above -->
<section title="NAT44 BIB create and delete events">
<t>These events will be generated when a NAT44 Bind entry is created or deleted.
The following is a template of the event.</t>
<texttable anchor="nat44_bib_event_template_table"
title="NAT44 BIB create/delete event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>postNATSourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>No</c>
<c>sourceTransportPort</c>
<c>16</c>
<c>No</c>
<c>postNAPTsourceTransportPort</c>
<c>16</c>
<c>No</c>
<c>internalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>externalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
</texttable>
</section>
<!-- End of section nat44 BIB above -->
<section title="NAT64 BIB create and delete events">
<t>These events will be generated when a NAT64 Bind entry is created or deleted.
The following is a template of the event.</t>
<texttable anchor="nat64_bib_event_template_table"
title="NAT64 BIB create/delete event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv6Address</c>
<c>128</c>
<c>Yes</c>
<c>postNATSourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>No</c>
<c>sourceTransportPort</c>
<c>16</c>
<c>No</c>
<c>postNAPTsourceTransportPort</c>
<c>16</c>
<c>No</c>
<c>internalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>externalAddressRealm</c>
<c>8</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
</texttable>
</section>
<section title="Addresses Exhausted event">
<t>This event will be generated when a NAT device runs out of global
IPv4 addresses in a given pool of addresses. Typically, this event would mean that the
NAT device
won't be able to create any new translations until some
addresses/ports are freed. This event SHOULD be rate limited as many packets hitting the
device at the same time will trigger a burst of addresses exhausted events. </t>
<t> The following is a template of the event. Note that either the NAT pool name or the
nat pool identifier SHOULD be logged, but not both.</t>
<texttable anchor="nat_adress_exhaust_template_table"
title="Address Exhausted event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natPoolID</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<!-- End of section nat address exhaust event above -->
<section title="Ports Exhausted event">
<t>This event will be generated when a NAT device runs out of ports
for a global IPv4 address. Port exhaustion shall be reported per
protocol (UDP, TCP etc). This event SHOULD be rate limited as many packets hitting the
device at the same time will trigger a burst of port exhausted events. </t>
<t>The following is a template of the event. </t>
<texttable anchor="nat_ports_exhaust_template_table"
title="Ports Exhausted event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>postNATSourceIPv4Address</c>
<c>32</c>
<c>Yes</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>Yes</c>
</texttable>
</section>
<!-- End of section nat ports exhaust event above -->
<section title="Quota exceeded events">
<t>This event will be generated when a NAT device cannot allocate
resources as a result of an administratively defined policy. The
quota exceeded event templates are described below.</t>
<section title="Maximum session entries exceeded">
<t> The maximum session entries exceeded is generated when the administratively
configured limit is reached. The following is the template of
the event. </t>
<texttable anchor="nat_session_entries_exceeded_template_table"
title="Session Entries Exceeded event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natLimitEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<section title="Maximum BIB entries exceeded">
<t> The maximum BIB entries exceeded is generated when the administratively
configured limit is reached. The following is the template of
the event. </t>
<texttable anchor="nat_bib_entries_exceeded_template_table"
title="BIB Entries Exceeded event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natLimitEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<section title="Maximum entries per user exceeded">
<t> This event is generated when a single user
reaches the administratively configured limit. The following is the template of
the event. </t>
<texttable anchor="nat_per_user_entries_exceeded_template_table"
title="Per-user Entries Exceeded event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natLimitEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv4 address</c>
<c>32</c>
<c>Yes for NAT44</c>
<c>sourceIPv6 address</c>
<c>128</c>
<c>Yes for NAT64</c>
</texttable>
</section>
<section title="Maximum active host or subscribers exceeded">
<t> This event is generated when the number of allowed hosts or subscribers
reaches the administratively configured limit. The following is the template of
the event. </t>
<texttable anchor="nat_max_sub_entries_exceeded_template_table"
title="Maximum hosts/subscribers Exceeded event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natLimitEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<section title="Maximum fragments pending reassembly exceeded">
<t> This event is generated when the number of fragments pending reassembly reaches
the administratively configured limit. The following is the template of
the event. </t>
<texttable anchor="nat_max_frag_reassembly_exceeded_template_table"
title="Maximum fragments pending reassembly Exceeded event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natLimitEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
<c>internalAddressRealm</c>
<c>8</c>
<c>Yes</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv4 address</c>
<c>32</c>
<c>Yes for NAT44</c>
<c>sourceIPv6 address</c>
<c>128</c>
<c>Yes for NAT64</c>
</texttable>
</section>
</section>
<section title="Threshold reached events">
<t>This event will be generated when a NAT device reaches a
operator configured threshold when allocating
resources. The threshold reached events are described in the section above.
The following is a template of the individual events.</t>
<section title="Address pool high or low threshold reached">
<t> This event is generated when the high or low threshold is reached for
the address pool. The template is the same for both high and low threshold
events </t>
<texttable anchor="nat_threshold_addrpool_template_table"
title="Address pool high/low threshold reached event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natThresholdEvent</c>
<c>32</c>
<c>Yes</c>
<c>natPoolID</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<section title="Address and port high threshold reached">
<t> This event is generated when the high threshold is reached for
the address pool and ports. </t>
<texttable anchor="nat_threshold_addrport_template_table"
title="Address port high threshold reached event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natThresholdEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<section title="Per-user Address and port high threshold reached">
<t> This event is generated when the high threshold is reached for
the per-user address pool and ports. </t>
<texttable anchor="nat_per_user_threshold_addrport_template_table"
title="Per-user Address port high threshold reached event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natThresholdEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
<c>sourceIPv4 address</c>
<c>32</c>
<c>Yes for NAT44</c>
<c>sourceIPv6 address</c>
<c>128</c>
<c>Yes for NAT64</c>
</texttable>
</section>
<section title="Global Address mapping high threshold reached">
<t> This event is generated when the high is reached for
the per-user address pool and ports. This is generated
only by NAT devices that use a address pooling behavior
of paired.</t>
<texttable anchor="nat_global_addr_map_threshold_addrport_template_table"
title="Global Address mapping high threshold reached event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>natThresholdEvent</c>
<c>32</c>
<c>Yes</c>
<c>configuredLimit</c>
<c>32</c>
<c>Yes</c>
<c>vlanID/ingressVRFID</c>
<c>32</c>
<c>No</c>
</texttable>
</section>
</section>
<section title="Address binding create and delete events">
<t>These events will be generated when a NAT device binds a local address
with a global address and when the global address is freed.
This binding event happens when the first packet of the first flow from a host in the private
realm. </t>
<texttable anchor="address_binding_template_table"
title="NAT Address Binding template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>sourceIPv4 address</c>
<c>32</c>
<c>Yes for NAT44</c>
<c>sourceIPv6 address</c>
<c>128</c>
<c>Yes for NAT64</c>
<c>Translated Source IPv4 Address</c>
<c>32</c>
<c>Yes</c>
</texttable>
</section>
<section title="Port block allocation and de-allocation">
<t>This event will be generated when a NAT device allocates/de-allocates ports
in a bulk fashion, as opposed to allocating a port on a per flow basis. </t>
<t> portRangeStart represents the starting value of the range. </t>
<t> portRangeEnd represents the ending value of the range. </t>
<t> NAT devices would do this in order to reduce logs
and potentially to limit the number of connections a subscriber is allowed to use. In the
following Port Block allocation template, the portRangeStart and portRangeEnd MUST be
specified. </t>
<t> It is up to the implementation to choose to consolidate log records in case two
consecutive port ranges for the same user are allocated or freed.
</t>
<texttable anchor="nat_bulk_port_allocation_template_table"
title="NAT Port Block Allocation event template">
<ttcol align="center">Field Name</ttcol>
<ttcol align="right">Size (bits)</ttcol>
<ttcol align="center">Mandatory</ttcol>
<c>timeStamp</c>
<c>64</c>
<c>Yes</c>
<c>natInstanceID</c>
<c>32</c>
<c>No</c>
<c>natEvent</c>
<c>8</c>
<c>Yes</c>
<c>sourceIPv4 address</c>
<c>32</c>
<c>Yes for NAT44</c>
<c>sourceIPv6 address</c>
<c>128</c>
<c>Yes for NAT64</c>
<c>Translated Source IPv4 Address</c>
<c>32</c>
<c>Yes</c>
<c>portRangeStart</c>
<c>16</c>
<c>Yes</c>
<c>portRangeEnd</c>
<c>16</c>
<c>No</c>
</texttable>
</section>
<!-- End of section nat ports exhaust event above -->
</section>
<!-- End of section templates above -->
</section>
<!-- End of section Event based logging above -->
<section anchor="Encoding" title="Encoding">
<section title="IPFIX">
<t>
This document uses IPFIX as the encoding mechanism to describe the logging of NAT events. However, the information that
is logged SHOULD be the same irrespective of what kind of encoding scheme is used. IPFIX is chosen because is it
an IETF standard that meets all the needs for a reliable logging mechanism. IPFIX provides the flexibility to the
logging device to define the data sets that it is logging. The IEs specified for logging MUST be
the same irrespective of the encoding mechanism used.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Dan Wing, Selvi Shanmugam, Mohamed Boucadir, Jacni Qin
Ramji Vaithianathan, Simon Perreault, Jean-Francois Tremblay, Paul Aitken, Julia Renouard, Spencer Dawkins
and Brian Trammel for their review and comments.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t> The following information elements are requested from IANA IPFIX registry. </t>
<t> Name : natInstanceId </t>
<t> Description: This Information Element identifies an Instance of the NAT that runs on a NAT middlebox function
after the packet passed the Observation Point. </t>
<t>Abstract Data Type: unsigned32 </t>
<t>Data Type Semantics: identifier </t>
<t> Reference: </t>
<t> See RFC 791 [RFC791] for the definition of the IPv4 source address field.
See RFC 3022 [RFC3022] for the definition of NAT. See RFC 3234 [RFC3234]
for the definition of middleboxes. </t>
<t> Name: internalAddressRealm </t>
<t> Description:
This Information Element represents the internal address realm where the packet
is originated from or destined to. By definition, a NAT mapping can be created
from two address realms, one from internal and one from external. Realms are
implementation dependent and can represent a VRF ID or a VLAN ID or some unique
identifier. Realms are optional and when left unspecified would mean that the
external and internal realms are the same.
</t>
<t>Abstract Data Type: unsigned8 </t>
<t>Data Type Semantics: identifier </t>
<t> Reference: </t>
<t> See RFC 791 [RFC791] for the definition of the IPv4 source address field.
See RFC 3022 [RFC3022] for the definition of NAT. See RFC 3234 [RFC3234]
for the definition of middleboxes. </t>
<t> Name: externalAddressRealm </t>
<t> Description:
This Information Element represents the external address realm where the packet
is originated from or destined to. The detailed definition is in the internal
address realm as specified above.</t>
<t>Abstract Data Type: unsigned8 </t>
<t>Data Type Semantics: identifier </t>
<t> Reference: </t>
<t> See RFC 791 [RFC791] for the definition of the IPv4 source address field.
See RFC 3022 [RFC3022] for the definition of NAT. See RFC 3234 [RFC3234]
for the definition of middleboxes. </t>
<t> Name : natLimitEvent </t>
<t> Description:
This Information Element identifies the limit type that is reported by
the event. There are different types of limits as describer in Table 3.</t>
<t>Abstract Data Type: unsigned32 </t>
<t>Data Type Semantics: identifier </t>
<t> Reference: </t>
<t> See RFC 791 [RFC791] for the definition of the IPv4 source address field.
See RFC 3022 [RFC3022] for the definition of NAT. See RFC 3234 [RFC3234]
for the definition of middleboxes. </t>
<t> Name: natThresholdEvent </t>
<t> Description:
This Information Element identifies the threshold type that is reported by
the event. There are different types of thresholds as describer in Table 4.</t>
<t>Abstract Data Type: unsigned32 </t>
<t>Data Type Semantics: identifier </t>
<t> Reference: </t>
<t> See RFC 791 [RFC791] for the definition of the IPv4 source address field.
See RFC 3022 [RFC3022] for the definition of NAT. See RFC 3234 [RFC3234]
for the definition of middleboxes. </t>
</section>
<section anchor="Management" title="Management Considerations">
<t>This section considers requirements for management of the log system
to support logging of the events described above. It first covers
requirements applicable to log management in general. Any additional
standardization required to fullfil these requirements is out of scope
of the present document. Some management considerations is covered in
[I-D.behave-syslog-nat-logging]. This document covers the additional
considerations. </t>
<section title="Ability to collect events from multiple NAT devices">
<t>
An IPFIX collector MUST be able to collect events from multiple NAT devices and be able to
decipher events based on the sourceID in the IPFIX header.
</t>
</section>
<section title="Ability to suppress events">
<t>
The exhaustion events can be overwhelming during traffic bursts and hence SHOULD be handled
by the NAT devices to rate limit them before sending them to the collectors. For eg. when the
port exhaustion happens during bursty conditions, instead of sending a port exhaustion event
for every packet, the exhaustion events SHOULD be rate limited by the NAT device.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t> The security considerations listed in detail for IPFIX in
<xref target="RFC7011"></xref> applies to this draft as well.
As described in <xref target="RFC7011"></xref> the messages exchanged between the
NAT device and the collector MUST be protected to provide confidentiality, integrity
and authenticity. Without those characteristics, the messages are subject to various
kinds of attacks. These attacks are described in great detail in
<xref target="RFC7011"></xref>. </t>
<t> This document re-emphasizes the use of TLS or DTLS for exchanging the log messages
between the NAT device and the collector. The log events sent in clear text
can result in confidential data being exposed to attackers, who could then
spoof log events based on the information in clear text messages. Hence,
the log events SHOULD NOT be sent in clear text. </t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2663.xml"?>
<?rfc include="reference.RFC.4787.xml"?>
<?rfc include="reference.RFC.5382.xml"?>
<?rfc include="reference.RFC.6146.xml"?>
<?rfc include="reference.RFC.6302.xml"?>
<?rfc include="reference.RFC.6888.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5470.xml"?>
<?rfc include="reference.RFC.7011.xml"?>
<?rfc include="reference.I-D.ietf-behave-syslog-nat-logging.xml"?>
<reference anchor="RFC5101bis">
<front>
<title>Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information</title>
<author initials="B." surname="Claise" fullname="B. Claise">
<organization>Cisco Systems</organization>
</author>
<author initials="B." surname="Trammel" fullname="B. Trammel">
<organization>ETH Zurich</organization>
</author>
<date month="July" year="2013"/>
</front>
</reference>
<reference anchor="RFC5102bis">
<front>
<title>Information Model for IP Flow Information eXport (IPFIX)</title>
<author initials="B." surname="Claise" fullname="B. Claise">
<organization>Cisco Systems</organization>
</author>
<author initials="B." surname="Trammel" fullname="B. Trammel">
<organization>ETH Zurich</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
<reference anchor="IPFIX-IANA"
target="http://www.iana.org/assignments/ipfix">
<front>
<title>IPFIX Information Elements registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<!--
Here we use entities that we defined at the beginningI. -->
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:33 |