summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8158.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8158.txt')
-rw-r--r--doc/rfc/rfc8158.txt1907
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc8158.txt b/doc/rfc/rfc8158.txt
new file mode 100644
index 0000000..b151260
--- /dev/null
+++ b/doc/rfc/rfc8158.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Sivakumar
+Request for Comments: 8158 R. Penno
+Category: Standards Track Cisco Systems
+ISSN: 2070-1721 December 2017
+
+
+ IP Flow Information Export (IPFIX) Information Elements
+ for Logging NAT Events
+
+Abstract
+
+ 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. In many cases, the logs are essential 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
+ use proprietary formats; hence, it is difficult to expect consistent
+ behavior. This lack of standardization 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 NAT events.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8158.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 1]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
+ 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Event-Based Logging . . . . . . . . . . . . . . . . . . . . . 6
+ 4.1. Logging Destination Information . . . . . . . . . . . . . 6
+ 4.2. Information Elements . . . . . . . . . . . . . . . . . . 7
+ 4.3. Definition of NAT Events . . . . . . . . . . . . . . . . 11
+ 4.4. Quota Exceeded Event Types . . . . . . . . . . . . . . . 12
+ 4.5. Threshold Reached Event Types . . . . . . . . . . . . . . 13
+ 4.6. Templates for NAT Events . . . . . . . . . . . . . . . . 14
+ 4.6.1. NAT44 Session Create and Delete Events . . . . . . . 14
+ 4.6.2. NAT64 Session Create and Delete Events . . . . . . . 15
+ 4.6.3. NAT44 BIB Create and Delete Events . . . . . . . . . 16
+ 4.6.4. NAT64 BIB Create and Delete Events . . . . . . . . . 16
+ 4.6.5. Addresses Exhausted Event . . . . . . . . . . . . . . 17
+ 4.6.6. Ports Exhausted Event . . . . . . . . . . . . . . . . 17
+ 4.6.7. Quota Exceeded Events . . . . . . . . . . . . . . . . 18
+ 4.6.7.1. Maximum Session Entries Exceeded . . . . . . . . 18
+ 4.6.7.2. Maximum BIB Entries Exceeded . . . . . . . . . . 18
+ 4.6.7.3. Maximum Entries per User Exceeded . . . . . . . . 19
+ 4.6.7.4. Maximum Active Hosts or Subscribers Exceeded . . 19
+ 4.6.7.5. Maximum Fragments Pending Reassembly Exceeded . . 19
+ 4.6.8. Threshold Reached Events . . . . . . . . . . . . . . 20
+ 4.6.8.1. Address Pool High or Low Threshold Reached . . . 20
+ 4.6.8.2. Address and Port Mapping High Threshold Reached . 21
+ 4.6.8.3. Address and Port Mapping per User High Threshold
+ Reached . . . . . . . . . . . . . . . . . . . . . 21
+ 4.6.8.4. Global Address Mapping High Threshold Reached . . 22
+ 4.6.9. Address Binding Create and Delete Events . . . . . . 22
+
+
+
+Sivakumar & Penno Standards Track [Page 2]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ 4.6.10. Port Block Allocation and De-allocation . . . . . . . 22
+ 5. Management Considerations . . . . . . . . . . . . . . . . . . 23
+ 5.1. Ability to Collect Events from Multiple NAT Devices . . . 23
+ 5.2. Ability to Suppress Events . . . . . . . . . . . . . . . 24
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
+ 6.1. Information Elements . . . . . . . . . . . . . . . . . . 24
+ 6.1.1. natInstanceID . . . . . . . . . . . . . . . . . . . . 24
+ 6.1.2. internalAddressRealm . . . . . . . . . . . . . . . . 24
+ 6.1.3. externalAddressRealm . . . . . . . . . . . . . . . . 25
+ 6.1.4. natQuotaExceededEvent . . . . . . . . . . . . . . . . 25
+ 6.1.5. natThresholdEvent . . . . . . . . . . . . . . . . . . 26
+ 6.1.6. natEvent . . . . . . . . . . . . . . . . . . . . . . 27
+ 6.1.7. maxSessionEntries . . . . . . . . . . . . . . . . . . 27
+ 6.1.8. maxBIBEntries . . . . . . . . . . . . . . . . . . . . 28
+ 6.1.9. maxEntriesPerUser . . . . . . . . . . . . . . . . . . 28
+ 6.1.10. maxSubscribers . . . . . . . . . . . . . . . . . . . 28
+ 6.1.11. maxFragmentsPendingReassembly . . . . . . . . . . . . 29
+ 6.1.12. addressPoolHighThreshold . . . . . . . . . . . . . . 29
+ 6.1.13. addressPoolLowThreshold . . . . . . . . . . . . . . . 29
+ 6.1.14. addressPortMappingHighThreshold . . . . . . . . . . . 30
+ 6.1.15. addressPortMappingLowThreshold . . . . . . . . . . . 30
+ 6.1.16. addressPortMappingPerUserHighThreshold . . . . . . . 30
+ 6.1.17. globalAddressMappingHighThreshold . . . . . . . . . . 31
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 32
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 33
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 3]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+1. Introduction
+
+ The IP Flow Information Export (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) that can be carried by the IPFIX protocol.
+ This document details the IPFIX IEs that MUST be logged by a NAT
+ device that supports NAT logging using IPFIX and all the optional
+ fields. The fields specified in this document are gleaned from
+ [RFC4787] and [RFC5382].
+
+ This document and [NAT-LOG] are written in order to standardize the
+ events and parameters to be recorded using IPFIX [RFC7011] and SYSLOG
+ [RFC5424], respectively. 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 it is an
+ IETF standard that meets all the needs for a reliable logging
+ mechanism. IPFIX provides the flexibility to the logging device to
+ define the datasets that it is logging. The IEs specified for
+ logging must be the same irrespective of the encoding mechanism used.
+
+1.1. Terminology
+
+ The term "NAT device" in this document refers to any NAT44 or NAT64
+ device. The term "Collector" refers to any device that receives
+ binary data from a NAT device and converts it into meaningful
+ information. This document uses the term "session" as defined in
+ [RFC2663], and the term "Binding Information Base" (BIB) as defined
+ in [RFC6146]. The term "Information Element" or "IE" is defined in
+ [RFC7011]. The term "Carrier-Grade NAT" refers to a large-scale NAT
+ device as described in [RFC6888]
+
+ The IPFIX IEs that are NAT specific are created with NAT terminology.
+ In order to avoid creating duplicates, IEs are reused if they convey
+ the same meaning. This document uses the term "timestamp" for the
+ IE, which defines the time when an event is logged; this is the same
+ as the IPFIX term "observationTimeMilliseconds" as described in
+ [IPFIX-IANA]. Since observationTimeMilliseconds is not self-
+ explanatory for NAT implementors, the term "timeStamp" is used.
+ Event templates, which refer to IPFIX Template Records, as well as
+ log events, which refer to IPFIX Flow Records, are also used in this
+ document.
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 4]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+1.2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. Scope
+
+ This document provides the information model to be used for logging
+ the NAT events, including Carrier-Grade NAT (CGN) events. [RFC7011]
+ provides guidance on the choices of the transport protocols used for
+ IPFIX and their effects. This document does not provide guidance on
+ transport protocols like TCP, UDP, or Stream Control Transmission
+ Protocol (SCTP), which are to be used to log NAT events. The logs
+ SHOULD be reliably sent to the Collector to ensure that the log
+ events are not lost. The choice of the actual transport protocol is
+ beyond the scope of this document.
+
+ This document uses the allocated IPFIX IEs in the IANA "IPFIX
+ Information Elements" registry [IPFIX-IANA] and registers some new
+ ones.
+
+ 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.
+
+ The implementation details of the Collector application are beyond
+ the scope of this document.
+
+ The optimization of logging the NAT events is left to the
+ implementation and is beyond the scope of this document.
+
+3. Deployment
+
+ NAT logging based on IPFIX uses binary encoding; hence, it 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.
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 5]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ A Collector may receive NAT events from multiple CGN devices. The
+ Collector distinguishes between the devices using the source IP
+ address, source port, and Observation Domain ID in the IPFIX header.
+ The Collector can decide to store the information based on the
+ administrative policies that are in line with the operator and the
+ local jurisdiction. The retention policy is not dictated by the
+ Exporter and is left to the policies that are defined at the
+ Collector.
+
+ A Collector may have scale issues if it is overloaded by a large
+ number of simultaneous events. An appropriate throttling mechanism
+ may be used to handle the oversubscription.
+
+ The logs that are exported can be used for a variety of reasons. An
+ example use case is to do accounting based on when the users logged
+ on and off. The translation will be installed when the user logs on
+ and removed when the user logs off. These events create log records.
+ Another use case is to identify an attacker or a host in a provider
+ network. The network administrators can use these logs to identify
+ the usage patterns, the need for additional IP addresses, and etc.
+ The deployment of NAT logging is not limited to just these cases.
+
+4. Event-Based Logging
+
+ An event in a NAT device can be viewed as a state transition because
+ it relates to the management of NAT resources. The creation and
+ deletion of NAT sessions and bindings are examples of events, as they
+ result in resources (addresses and ports) being allocated or freed.
+ The events can happen through the processing of data packets flowing
+ through the NAT device, 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 is provided in Table 2. Each of
+ these events SHOULD be logged, unless this is 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. It is
+ necessary to preserve the list of Collectors and its associated
+ information like the IPv4/IPv6 address, port, and protocol across
+ reboots so that the configuration information is not lost when the
+ device is restarted. The NAT device implementing the IPFIX logging
+ MUST follow the IPFIX specification in [RFC7011].
+
+4.1. Logging Destination Information
+
+ Logging destination information in a NAT event is discussed in
+ [RFC6302] and [RFC6888]. Logging destination information increases
+ the size of each record and increases the need for storage
+ considerably. It increases the number of log events generated
+
+
+
+Sivakumar & Penno Standards Track [Page 6]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ because when the same user connects to a different destination, it
+ results in a log record per destination address. Logging the source
+ and destination addresses results in loss of privacy. Logging of
+ destination addresses and ports, pre- or post-NAT, SHOULD NOT be done
+ [RFC6888]. However, this document provides the necessary fields to
+ log the destination information in cases where they must be logged.
+
+4.2. Information Elements
+
+ The templates could contain a subset of the IEs shown in Table 1,
+ depending upon the event being logged. For example, a NAT44 session
+ creation template record will contain:
+
+ {sourceIPv4Address, postNATSourceIPv4Address, destinationIPv4Address,
+ postNATDestinationIPv4Address, sourceTransportPort,
+ postNAPTSourceTransportPort, destinationTransportPort,
+ postNAPTDestinationTransportPort, internalAddressRealm, natEvent,
+ timeStamp}
+
+ An example of the actual event data record is shown below in a human-
+ readable form:
+
+ {192.0.2.1, 203.0.113.100, 192.0.2.104, 192.0.2.104, 14800, 1024, 80,
+ 80, 0, 1, 09:20:10:789}
+
+ A single NAT device could be exporting multiple templates, and the
+ Collector MUST support receiving multiple templates from the same
+ source.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 7]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ The following table includes all the IEs that a NAT device would need
+ to export the events. The formats of the IEs and the IPFIX IDs are
+ listed. Detailed descriptions of the fields natInstanceID,
+ internalAddressRealm, externalAddressRealm, natQuotaExceededEvent,
+ and natThresholdEvent are included in the IANA Considerations
+ section.
+
+ +-----------------------------------+--------+-------+--------------+
+ | Field Name | Size | IANA | Description |
+ | | (bits) | IPFIX | |
+ | | | ID | |
+ +-----------------------------------+--------+-------+--------------+
+ | timeStamp | 64 | 323 | System Time |
+ | | | | when the |
+ | | | | event |
+ | | | | occurred |
+ | | | | |
+ | natInstanceID | 32 | 463 | NAT Instance |
+ | | | | Identifier |
+ | | | | |
+ | vlanId | 16 | 58 | VLAN ID in |
+ | | | | case of |
+ | | | | overlapping |
+ | | | | networks |
+ | | | | |
+ | ingressVRFID | 32 | 234 | VRF ID in |
+ | | | | case of |
+ | | | | overlapping |
+ | | | | networks |
+ | | | | |
+ | sourceIPv4Address | 32 | 8 | Source IPv4 |
+ | | | | Address |
+ | | | | |
+ | postNATSourceIPv4Address | 32 | 225 | Translated |
+ | | | | Source IPv4 |
+ | | | | Address |
+ | | | | |
+ | protocolIdentifier | 8 | 4 | Transport |
+ | | | | protocol |
+ | | | | |
+ | sourceTransportPort | 16 | 7 | Source Port |
+ | | | | |
+ | postNAPTSourceTransportPort | 16 | 227 | Translated |
+ | | | | Source port |
+ | | | | |
+ | destinationIPv4Address | 32 | 12 | Destination |
+ | | | | IPv4 Address |
+ | | | | |
+
+
+
+Sivakumar & Penno Standards Track [Page 8]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ | postNATDestinationIPv4Address | 32 | 226 | Translated |
+ | | | | IPv4 |
+ | | | | destination |
+ | | | | address |
+ | | | | |
+ | destinationTransportPort | 16 | 11 | Destination |
+ | | | | port |
+ | | | | |
+ | postNAPTDestinationTransportPort | 16 | 228 | Translated |
+ | | | | Destination |
+ | | | | port |
+ | | | | |
+ | sourceIPv6Address | 128 | 27 | Source IPv6 |
+ | | | | address |
+ | | | | |
+ | destinationIPv6Address | 128 | 28 | Destination |
+ | | | | IPv6 address |
+ | | | | |
+ | postNATSourceIPv6Address | 128 | 281 | Translated |
+ | | | | source IPv6 |
+ | | | | address |
+ | | | | |
+ | postNATDestinationIPv6Address | 128 | 282 | Translated |
+ | | | | Destination |
+ | | | | IPv6 address |
+ | | | | |
+ | internalAddressRealm | (*) | 464 | Source |
+ | | | | Address |
+ | | | | Realm |
+ | | | | |
+ | externalAddressRealm | (*) | 465 | Destination |
+ | | | | Address |
+ | | | | Realm |
+ | | | | |
+ | natEvent | 8 | 230 | Type of |
+ | | | | Event |
+ | | | | |
+ | portRangeStart | 16 | 361 | Allocated |
+ | | | | port block |
+ | | | | start |
+ | | | | |
+ | portRangeEnd | 16 | 362 | Allocated |
+ | | | | Port block |
+ | | | | end |
+ | | | | |
+ | natPoolId | 32 | 283 | NAT pool |
+ | | | | Identifier |
+ | | | | |
+
+
+
+Sivakumar & Penno Standards Track [Page 9]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ | natQuotaExceededEvent | 32 | 466 | Limit event |
+ | | | | identifier |
+ | | | | |
+ | natThresholdEvent | 32 | 467 | Threshold |
+ | | | | event |
+ | | | | identifier |
+ | | | | |
+ | maxSessionEntries | 32 | 471 | Maximum |
+ | | | | session |
+ | | | | entries |
+ | | | | |
+ | maxBIBEntries | 32 | 472 | Maximum bind |
+ | | | | entries |
+ | | | | |
+ | maxEntriesPerUser | 32 | 473 | Maximum |
+ | | | | entries per- |
+ | | | | user |
+ | | | | |
+ | maxSubscribers | 32 | 474 | Maximum |
+ | | | | subscribers |
+ | | | | |
+ | maxFragmentsPendingReassembly | 32 | 475 | Maximum |
+ | | | | fragments |
+ | | | | for |
+ | | | | ressembly |
+ | | | | |
+ | addressPoolHighThreshold | 32 | 476 | High |
+ | | | | threshold |
+ | | | | for address |
+ | | | | pool |
+ | | | | |
+ | addressPoolLowThreshold | 32 | 477 | Low |
+ | | | | threshold |
+ | | | | for address |
+ | | | | pool |
+ | | | | |
+ | addressPortMappingHighThreshold | 32 | 478 | High |
+ | | | | threshold |
+ | | | | for |
+ | | | | address/port |
+ | | | | mapping |
+ | | | | |
+ | addressPortMappingLowThreshold | 32 | 479 | Low |
+ | | | | threshold |
+ | | | | for |
+ | | | | address/port |
+ | | | | mapping |
+ | | | | |
+
+
+
+Sivakumar & Penno Standards Track [Page 10]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ | addressPortMappingPerUserHighThre | 32 | 480 | High |
+ | shold | | | threshold |
+ | | | | for per-user |
+ | | | | address/port |
+ | | | | mapping |
+ | | | | |
+ | globalAddressMappingHighThreshold | 32 | 481 | High |
+ | | | | threshold |
+ | | | | for global |
+ | | | | address |
+ | | | | mapping |
+ +-----------------------------------+--------+-------+--------------+
+
+ Note: (*) indicates octetArray
+
+ Table 1: NAT IE List
+
+4.3. Definition of NAT Events
+
+ The following is the complete list of NAT events and the proposed
+ event type values. The natEvent IE is defined in the "IPFIX
+ Information Elements" registry [IPFIX-IANA];. The list can be
+ expanded in the future as necessary. The data record will have the
+ corresponding natEvent value to indicate the event that is being
+ logged.
+
+ Note that the first two events are marked "Historic" and are listed
+ here for the sole purpose of completeness. Any compliant
+ implementation SHOULD NOT use the events that are marked "Historic".
+ These values were defined prior to the existence of this document and
+ outside the IETF. These events are not standalone and require more
+ information to be conveyed to qualify the event. For example, the
+ NAT translation create event does not specify if it is NAT44 or
+ NAT64. As a result, the Behave working group decided to have an
+ explicit definition for each one of the unique events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 11]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ +-------+------------------------------------+
+ | Value | Event Name |
+ +-------+------------------------------------+
+ | 0 | Reserved |
+ | 1 | NAT translation create (Historic) |
+ | 2 | NAT translation delete (Historic) |
+ | 3 | NAT Addresses exhausted |
+ | 4 | NAT44 session create |
+ | 5 | NAT44 session delete |
+ | 6 | NAT64 session create |
+ | 7 | NAT64 session delete |
+ | 8 | NAT44 BIB create |
+ | 9 | NAT44 BIB delete |
+ | 10 | NAT64 BIB create |
+ | 11 | NAT64 BIB delete |
+ | 12 | NAT ports exhausted |
+ | 13 | Quota Exceeded |
+ | 14 | Address binding create |
+ | 15 | Address binding delete |
+ | 16 | Port block allocation |
+ | 17 | Port block de-allocation |
+ | 18 | Threshold Reached |
+ +-------+------------------------------------+
+
+ Table 2: NAT Event ID
+
+4.4. Quota Exceeded Event Types
+
+ The Quota Exceeded event is a natEvent IE described in Table 2. The
+ Quota Exceeded events are generated when the hard limits set by the
+ administrator have been reached or exceeded. The following table
+ shows the sub-event types for the Quota Exceeded 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, maximum active hosts or subscribers limit
+ reached, and maximum Fragments pending reassembly limit reached.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 12]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ +-------+---------------------------------------+
+ | Value | Quota Exceeded Event Name |
+ +-------+---------------------------------------+
+ | 0 | Reserved |
+ | 1 | Maximum session entries |
+ | 2 | Maximum BIB entries |
+ | 3 | Maximum entries per user |
+ | 4 | Maximum active hosts or subscribers |
+ | 5 | Maximum fragments pending reassembly |
+ +-------+---------------------------------------+
+
+ Table 3: Quota Exceeded Event
+
+4.5. Threshold Reached Event Types
+
+ 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 the Quota Exceeded
+ and Threshold Reached events is that, once the Quota Exceeded events
+ are hit, the packets are dropped or mappings will not be created,
+ 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.
+
+ 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 either the operator might have
+ to add more addresses to the pool or the subsequent users may be
+ denied NAT translation mappings.
+
+ The address pool low threshold event will be reported when the
+ address pool reaches a low-water mark as defined by the operator.
+ This will serve as an indication that the operator can reclaim some
+ of the global IPv4 addresses in the pool.
+
+ 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.
+
+ The per-user address and port mapping high threshold is generated
+ when a single user utilizes more address and port mapping than a
+ configured threshold. We don't track the low threshold for per-user
+ address and port mappings because, as the ports are freed, the
+ address will become available. The address pool low threshold event
+ will then be triggered so that the global IPv4 address can be
+ reclaimed.
+
+
+
+
+Sivakumar & Penno Standards Track [Page 13]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ The global address mapping high threshold event is generated when the
+ maximum number of mappings per user is reached for a NAT device doing
+ paired-address pooling.
+
+ +-------+---------------------------------------------------------+
+ | Value | Threshold Exceeded Event Name |
+ +-------+---------------------------------------------------------+
+ | 0 | Reserved |
+ | 1 | Address pool high threshold event |
+ | 2 | Address pool low threshold event |
+ | 3 | Address and port mapping high threshold event |
+ | 4 | Address and port mapping per user high threshold event |
+ | 5 | Global address mapping high threshold event |
+ +-------+---------------------------------------------------------+
+
+ Table 4: Threshold Event
+
+4.6. Templates for NAT Events
+
+ 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. A NAT device that implements a given NAT
+ event MUST support the mandatory IEs in the templates. Depending on
+ the implementation and configuration, various IEs that are not
+ mandatory can be included or ignored.
+
+4.6.1. NAT44 Session Create and Delete Events
+
+ 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.
+
+ The destination address and port information is optional as required
+ by [RFC6888]. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 14]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ +----------------------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +----------------------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | sourceIPv4Address | 32 | Yes |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | protocolIdentifier | 8 | Yes |
+ | sourceTransportPort | 16 | Yes |
+ | postNAPTSourceTransportPort | 16 | Yes |
+ | destinationIPv4Address | 32 | No |
+ | postNATDestinationIPv4Address | 32 | No |
+ | destinationTransportPort | 16 | No |
+ | postNAPTDestinationTransportPort | 16 | No |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ | internalAddressRealm | octetArray | No |
+ | externalAddressRealm | octetArray | No |
+ +----------------------------------+-------------+-----------+
+
+ Table 5: NAT44 Session Delete/Create Template
+
+4.6.2. NAT64 Session Create and Delete Events
+
+ These events will be generated when a NAT64 session is created or
+ deleted. The following is a template of the event.
+
+ +----------------------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +----------------------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | sourceIPv6Address | 128 | Yes |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | protocolIdentifier | 8 | Yes |
+ | sourceTransportPort | 16 | Yes |
+ | postNAPTSourceTransportPort | 16 | Yes |
+ | destinationIPv6Address | 128 | No |
+ | postNATDestinationIPv4Address | 32 | No |
+ | destinationTransportPort | 16 | No |
+ | postNAPTDestinationTransportPort | 16 | No |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ | internalAddressRealm | octetArray | No |
+ | externalAddressRealm | octetArray | No |
+ +----------------------------------+-------------+-----------+
+
+ Table 6: NAT64 Session Create/Delete Event Template
+
+
+
+Sivakumar & Penno Standards Track [Page 15]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+4.6.3. NAT44 BIB Create and Delete Events
+
+ These events will be generated when a NAT44 Bind entry is created or
+ deleted. The following is a template of the event.
+
+ +-----------------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | sourceIPv4Address | 32 | Yes |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | protocolIdentifier | 8 | No |
+ | sourceTransportPort | 16 | No |
+ | postNAPTSourceTransportPort | 16 | No |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ | internalAddressRealm | octetArray | No |
+ | externalAddressRealm | octetArray | No |
+ +-----------------------------+-------------+-----------+
+
+ Table 7: NAT44 BIB Create/Delete Event Template
+
+4.6.4. NAT64 BIB Create and Delete Events
+
+ These events will be generated when a NAT64 Bind entry is created or
+ deleted. The following is a template of the event.
+
+ +-----------------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | sourceIPv6Address | 128 | Yes |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | protocolIdentifier | 8 | No |
+ | sourceTransportPort | 16 | No |
+ | postNAPTSourceTransportPort | 16 | No |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ | internalAddressRealm | octetArray | No |
+ | externalAddressRealm | octetArray | No |
+ +-----------------------------+-------------+-----------+
+
+ Table 8: NAT64 BIB Create/Delete Event Template
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 16]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+4.6.5. Addresses Exhausted Event
+
+ 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.
+
+ The following is a template of the event.
+
+ +---------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +---------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natPoolID | 32 | Yes |
+ | natInstanceID | 32 | No |
+ +---------------+-------------+-----------+
+
+ Table 9: Addresses Exhausted Event Template
+
+4.6.6. Ports Exhausted Event
+
+ 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.
+
+ The following is a template of the event.
+
+ +--------------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +--------------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | protocolIdentifier | 8 | Yes |
+ | natInstanceID | 32 | No |
+ +--------------------------+-------------+-----------+
+
+ Table 10: Ports Exhausted Event Template
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 17]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+4.6.7. Quota Exceeded Events
+
+ 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.
+
+4.6.7.1. Maximum Session Entries Exceeded
+
+ The maximum session entries exceeded event is generated when the
+ administratively configured NAT session limit is reached. The
+ following is the template of the event.
+
+ +-----------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natQuotaExceededEvent | 32 | Yes |
+ | maxSessionEntries | 32 | Yes |
+ | natInstanceID | 32 | No |
+ +-----------------------+-------------+-----------+
+
+ Table 11: Session Entries Exceeded Event Template
+
+4.6.7.2. Maximum BIB Entries Exceeded
+
+ The maximum BIB entries exceeded event is generated when the
+ administratively configured BIB entry limit is reached. The
+ following is the template of the event.
+
+ +-----------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natQuotaExceededEvent | 32 | Yes |
+ | maxBIBEntries | 32 | Yes |
+ | natInstanceID | 32 | No |
+ +-----------------------+-------------+-----------+
+
+ Table 12: BIB Entries Exceeded Event Template
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 18]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+4.6.7.3. Maximum Entries per User Exceeded
+
+ This event is generated when a single user reaches the
+ administratively configured NAT translation limit. The following is
+ the template of the event.
+
+ +-----------------------+-------------+---------------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------+-------------+---------------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natQuotaExceededEvent | 32 | Yes |
+ | maxEntriesPerUser | 32 | Yes |
+ | sourceIPv4Address | 32 | Yes for NAT44 |
+ | sourceIPv6Address | 128 | Yes for NAT64 |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ +-----------------------+-------------+---------------+
+
+ Table 13: Per-User Entries Exceeded Event Template
+
+4.6.7.4. Maximum Active Hosts or Subscribers Exceeded
+
+ 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.
+
+ +-----------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natQuotaExceededEvent | 32 | Yes |
+ | maxSubscribers | 32 | Yes |
+ | natInstanceID | 32 | No |
+ +-----------------------+-------------+-----------+
+
+ Table 14: Maximum Hosts/Subscribers Exceeded Event Template
+
+4.6.7.5. Maximum Fragments Pending Reassembly Exceeded
+
+ This event is generated when the number of fragments pending
+ reassembly reaches the administratively configured limit. Note that
+ in the case of NAT64, when this condition is detected in the IPv6-to-
+ IPv4 direction, the IPv6 source address is mandatory in the template.
+ Similarly, when this condition is detected in IPv4-to-IPv6 direction,
+ the source IPv4 address is mandatory in the template below. The
+ following is the template of the event.
+
+
+
+Sivakumar & Penno Standards Track [Page 19]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ +-------------------------------+-------------+----------------+
+ | Field Name | Size (bits) | Mandatory |
+ +-------------------------------+-------------+----------------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natQuotaExceededEvent | 32 | Yes |
+ | maxFragmentsPendingReassembly | 32 | Yes |
+ | sourceIPv4Address | 32 | Yes for NAT44 |
+ | sourceIPv6Address | 128 | Yes for NAT64 |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ | internalAddressRealm | octetArray | No |
+ +-------------------------------+-------------+----------------+
+
+ Table 15: Maximum Fragments Pending Reassembly Exceeded Event
+ Template
+
+4.6.8. Threshold Reached Events
+
+ This event will be generated when a NAT device reaches an 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.
+
+4.6.8.1. Address Pool High or Low Threshold Reached
+
+ 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
+
+ +----------------------------------------------+--------+-----------+
+ | Field Name | Size | Mandatory |
+ | | (bits) | |
+ +----------------------------------------------+--------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natThresholdEvent | 32 | Yes |
+ | natPoolID | 32 | Yes |
+ | addressPoolHighThreshold/ | 32 | Yes |
+ | addressPoolLowThreshold | | |
+ | natInstanceID | 32 | No |
+ +----------------------------------------------+--------+-----------+
+
+ Table 16: Address Pool High/Low Threshold Reached Event Template
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 20]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+4.6.8.2. Address and Port Mapping High Threshold Reached
+
+ This event is generated when the high threshold is reached for the
+ address pool and ports.
+
+ +----------------------------------------------+--------+-----------+
+ | Field Name | Size | Mandatory |
+ | | (bits) | |
+ +----------------------------------------------+--------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natThresholdEvent | 32 | Yes |
+ | addressPortMappingHighThreshold/ | 32 | Yes |
+ | addressPortMappingLowThreshold | | |
+ | natInstanceID | 32 | No |
+ +----------------------------------------------+--------+-----------+
+
+ Table 17: Address Port High Threshold Reached Event Template
+
+4.6.8.3. Address and Port Mapping per User High Threshold Reached
+
+ This event is generated when the high threshold is reached for the
+ per-user address pool and ports.
+
+ +----------------------------------------------+--------+-----------+
+ | Field Name | Size | Mandatory |
+ | | (bits) | |
+ +----------------------------------------------+--------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natThresholdEvent | 32 | Yes |
+ | addressPortMappingHighThreshold/ | 32 | Yes |
+ | addressPortMappingLowThreshold | | |
+ | sourceIPv4Address | 32 | Yes for |
+ | | | NAT44 |
+ | sourceIPv6Address | 128 | Yes for |
+ | | | NAT64 |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ +----------------------------------------------+--------+-----------+
+
+ Table 18: Address and Port Mapping per User High Threshold Reached
+ Event Template
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 21]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+4.6.8.4. Global Address Mapping High Threshold Reached
+
+ This event is generated when the high threshold is reached for the
+ per-user address pool and ports. This is generated only by NAT
+ devices that use a paired-address-pooling behavior.
+
+ +-----------------------------------+-------------+-----------+
+ | Field Name | Size (bits) | Mandatory |
+ +-----------------------------------+-------------+-----------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | natThresholdEvent | 32 | Yes |
+ | globalAddressMappingHighThreshold | 32 | Yes |
+ | natInstanceID | 32 | No |
+ | vlanID/ingressVRFID | 16/32 | No |
+ +-----------------------------------+-------------+-----------+
+
+ Table 19: Global Address Mapping High Threshold Reached Event
+ Template
+
+4.6.9. Address Binding Create and Delete Events
+
+ These events will be generated when a NAT device binds a local
+ address with a global address and when the global address is freed.
+ A NAT device will generate the binding events when it receives the
+ first packet of the first flow from a host in the private realm.
+
+ +--------------------------+-------------+---------------+
+ | Field Name | Size (bits) | Mandatory |
+ +--------------------------+-------------+---------------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | sourceIPv4Address | 32 | Yes for NAT44 |
+ | sourceIPv6Address | 128 | Yes for NAT64 |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | natInstanceID | 32 | No |
+ +--------------------------+-------------+---------------+
+
+ Table 20: NAT Address Binding Template
+
+4.6.10. Port Block Allocation and De-allocation
+
+ 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.
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 22]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ portRangeStart represents the starting value of the range.
+
+ portRangeEnd represents the ending value of the range.
+
+ NAT devices would do this in order to reduce logs and to potentially
+ 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.
+
+ 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.
+
+ +--------------------------+-------------+---------------+
+ | Field Name | Size (bits) | Mandatory |
+ +--------------------------+-------------+---------------+
+ | timeStamp | 64 | Yes |
+ | natEvent | 8 | Yes |
+ | sourceIPv4Address | 32 | Yes for NAT44 |
+ | sourceIPv6Address | 128 | Yes for NAT64 |
+ | postNATSourceIPv4Address | 32 | Yes |
+ | portRangeStart | 16 | Yes |
+ | portRangeEnd | 16 | No |
+ | natInstanceID | 32 | No |
+ +--------------------------+-------------+---------------+
+
+ Table 21: NAT Port Block Allocation Event Template
+
+5. Management Considerations
+
+ 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 fulfill these requirements is out of
+ scope of the present document. Some management considerations are
+ covered in [NAT-LOG]. This document covers the additional
+ considerations.
+
+5.1. Ability to Collect Events from Multiple NAT Devices
+
+ An IPFIX Collector MUST be able to collect events from multiple NAT
+ devices and decipher events based on the Observation Domain ID in the
+ IPFIX header.
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 23]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+5.2. Ability to Suppress Events
+
+ The exhaustion events can be overwhelming during traffic bursts;
+ hence, they SHOULD be handled by the NAT devices to rate-limit them
+ before sending them to the Collectors. For example, 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.
+
+6. IANA Considerations
+
+6.1. Information Elements
+
+ IANA has registered the following IEs in the "IPFIX Information
+ Elements" registry at [IPFIX-IANA].
+
+6.1.1. natInstanceID
+
+ ElementID: 463
+
+ Name: natInstanceID
+
+ Description: This Information Element uniquely identifies an Instance
+ of the NAT that runs on a NAT middlebox function after the packet
+ passes the Observation Point. natInstanceID is defined in [RFC7659].
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC791] for the definition of the IPv4 source address
+ field. See [RFC3022] for the definition of NAT. See [RFC3234] for
+ the definition of middleboxes.
+
+6.1.2. internalAddressRealm
+
+ ElementID: 464
+
+ Name: internalAddressRealm
+
+ 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 Virtual Routing and Forwarding (VRF)
+ ID, 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.
+
+
+
+Sivakumar & Penno Standards Track [Page 24]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ Abstract Data Type: octetArray
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC791] for the definition of the IPv4 source address
+ field. See [RFC3022] for the definition of NAT. See [RFC3234] for
+ the definition of middleboxes.
+
+6.1.3. externalAddressRealm
+
+ ElementID: 465
+
+ Name: externalAddressRealm
+
+ 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.
+
+ Abstract Data Type: octetArray
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC791] for the definition of the IPv4 source address
+ field. See [RFC3022] for the definition of NAT. See [RFC3234] for
+ the definition of middleboxes.
+
+6.1.4. natQuotaExceededEvent
+
+ ElementID: 466
+
+ Name: natQuotaExceededEvent
+
+ Description: This Information Element identifies the type of a NAT
+ Quota Exceeded event. Values for this Information Element are listed
+ in the "NAT Quota Exceeded Event Type" registry, see [IPFIX-IANA].
+ Initial values in the registry are defined by the table below. New
+ assignments of values will be administered by IANA and are subject to
+ Expert Review [RFC8126]. Experts need to check definitions of new
+ values for completeness, accuracy, and redundancy.
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 25]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ +--------+---------------------------------------+
+ | Value | Quota Exceeded Event Name |
+ +--------+---------------------------------------+
+ | 0 | Reserved |
+ | 1 | Maximum session entries |
+ | 2 | Maximum BIB entries |
+ | 3 | Maximum entries per user |
+ | 4 | Maximum active hosts or subscribers |
+ | 5 | Maximum fragments pending reassembly |
+ +--------+---------------------------------------+
+
+ Note: This is the same as Table 3.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC791] for the definition of the IPv4 source address
+ field. See [RFC3022] for the definition of NAT. See [RFC3234] for
+ the definition of middleboxes.
+
+6.1.5. natThresholdEvent
+
+ ElementID: 467
+
+ Name: natThresholdEvent
+
+ Description: This Information Element identifies a type of a NAT
+ Threshold event. Values for this Information Element are listed in
+ the "NAT Threshold Event Type" registry, see [IPFIX-IANA]. Initial
+ values in the registry are defined by the table below. New
+ assignments of values will be administered by IANA and are subject to
+ Expert Review [RFC8126]. Experts need to check definitions of new
+ values for completeness, accuracy, and redundancy.
+
+
+ +--------+---------------------------------------------------------+
+ | Value | Threshold Exceeded Event Name |
+ +--------+---------------------------------------------------------+
+ | 0 | Reserved |
+ | 1 | Address pool high threshold event |
+ | 2 | Address pool low threshold event |
+ | 3 | Address and port mapping high threshold event |
+ | 4 | Address and port mapping per user high threshold event |
+ | 5 | Global address mapping high threshold event |
+ +--------+---------------------------------------------------------+
+
+ Note: This is the same as Table 4.
+
+
+
+Sivakumar & Penno Standards Track [Page 26]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC791] for the definition of the IPv4 source address
+ field. See [RFC3022] for the definition of NAT. See [RFC3234] for
+ the definition of middleboxes.
+
+6.1.6. natEvent
+
+ The original definition of this Information Element specified only
+ three values: 1, 2, and 3. This definition has been replaced by a
+ registry, to which new values can be added. The semantics of the
+ three originally defined values remain unchanged. IANA maintains the
+ "NAT Event Type (Value 230)" registry for values of this Information
+ Element at [IPFIX-IANA].
+
+ ElementID: 230
+
+ Name: natEvent
+
+ Description: This Information Element identifies a NAT event. This
+ IE identifies the type of a NAT event. Examples of NAT events
+ include, but are not limited to, NAT translation create, NAT
+ translation delete, Threshold Reached, or Threshold Exceeded, etc.
+ Values for this Information Element are listed in the "NAT Event
+ Type" registry, see [IPFIX-IANA]. The NAT event values in the
+ registry are defined by Table 2 in Section 4.3. New assignments of
+ values will be administered by IANA and are subject to Expert Review
+ [RFC8126]. Experts need to check definitions of new values for
+ completeness, accuracy, and redundancy.
+
+ Abstract Data Type: unsigned8
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes. See RFC 8158 for the definitions
+ of values 4-16.
+
+6.1.7. maxSessionEntries
+
+ ElementID: 471
+
+ Name: maxSessionEntries
+
+ Description: This element represents the maximum session entries that
+ can be created by the NAT device.
+
+
+
+Sivakumar & Penno Standards Track [Page 27]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.8. maxBIBEntries
+
+ ElementID: 472
+
+ Name: maxBIBEntries
+
+ Description: This element represents the maximum BIB entries that can
+ be created by the NAT device.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.9. maxEntriesPerUser
+
+ ElementID: 473
+
+ Name: maxEntriesPerUser
+
+ Description: This element represents the maximum NAT entries that can
+ be created per user by the NAT device.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.10. maxSubscribers
+
+ ElementID: 474
+
+ Name: maxSubscribers
+
+ Description: This element represents the maximum subscribers or
+ maximum hosts that are allowed by the NAT device.
+
+
+
+
+Sivakumar & Penno Standards Track [Page 28]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.11. maxFragmentsPendingReassembly
+
+ ElementID: 475
+
+ Name: maxFragmentsPendingReassembly
+
+ Description: This element represents the maximum fragments that the
+ NAT device can store for reassembling the packet.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.12. addressPoolHighThreshold
+
+ ElementID: 476
+
+ Name: addressPoolHighThreshold
+
+ Description: This element represents the high threshold value of the
+ number of public IP addresses in the address pool.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.13. addressPoolLowThreshold
+
+ ElementID: 477
+
+ Name: addressPoolLowThreshold
+
+ Description: This element represents the low threshold value of the
+ number of public IP addresses in the address pool.
+
+
+
+
+Sivakumar & Penno Standards Track [Page 29]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.14. addressPortMappingHighThreshold
+
+ ElementID: 478
+
+ Name: addressPortMappingHighThreshold
+
+ Description: This element represents the high threshold value of the
+ number of address and port mappings.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.15. addressPortMappingLowThreshold
+
+ ElementID: 479
+
+ Name: addressPortMappingLowThreshold
+
+ Description: This element represents the low threshold value of the
+ number of address and port mappings.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.16. addressPortMappingPerUserHighThreshold
+
+ ElementID: 480
+
+ Name: addressPortMappingPerUserHighThreshold
+
+ Description: This element represents the high threshold value of the
+ number of address and port mappings that a single user is allowed to
+ create on a NAT device.
+
+
+
+Sivakumar & Penno Standards Track [Page 30]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes.
+
+6.1.17. globalAddressMappingHighThreshold
+
+ ElementID: 481
+
+ Name: globalAddressMappingHighThreshold
+
+ Description: This element represents the high threshold value of the
+ number of address and port mappings that a single user is allowed to
+ create on a NAT device in a paired address pooling behavior.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ Reference: See [RFC3022] for the definition of NAT. See [RFC3234]
+ for the definition of middleboxes. See [RFC4787] for the definition
+ of paired address pooling behavior.
+
+7. Security Considerations
+
+ The security considerations listed in detail for IPFIX in [RFC7011]
+ apply to this document as well. As described in [RFC7011], 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
+ [RFC7011].
+
+ This document re-emphasizes the use of Transport Layer Security (TLS)
+ or Datagram Transport Layer Security (DTLS) for exchanging the log
+ messages between the NAT device and the Collector. The log events
+ sent in cleartext can result in confidential data being exposed to
+ attackers, who could then spoof log events based on the information
+ in cleartext messages. Hence, the log events SHOULD NOT be sent in
+ cleartext.
+
+ The logging of NAT events can result in privacy concerns as a result
+ of exporting information such as the source address and port
+ information. The logging of destination information can also cause
+ privacy concerns, but it has been well documented in [RFC6888]. A
+ NAT device can choose to operate in various logging modes if it wants
+
+
+
+Sivakumar & Penno Standards Track [Page 31]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ to avoid logging of private information. The Collector that receives
+ the information can also choose to mask the private information but
+ generate reports based on abstract data. It is outside the scope of
+ this document to address the implementation of logging modes for
+ privacy considerations.
+
+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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [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, <https://www.rfc-editor.org/info/rfc4787>.
+
+ [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+ Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+ RFC 5382, DOI 10.17487/RFC5382, October 2008,
+ <https://www.rfc-editor.org/info/rfc5382>.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
+ April 2011, <https://www.rfc-editor.org/info/rfc6146>.
+
+ [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
+ "Logging Recommendations for Internet-Facing Servers",
+ BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
+ <https://www.rfc-editor.org/info/rfc6302>.
+
+ [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
+ A., and H. Ashida, "Common Requirements for Carrier-Grade
+ NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
+ April 2013, <https://www.rfc-editor.org/info/rfc6888>.
+
+ [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+ "Specification of the IP Flow Information Export (IPFIX)
+ Protocol for the Exchange of Flow Information", STD 77,
+ RFC 7011, DOI 10.17487/RFC7011, September 2013,
+ <https://www.rfc-editor.org/info/rfc7011>.
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 32]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+ [RFC7659] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
+ "Definitions of Managed Objects for Network Address
+ Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659,
+ October 2015, <https://www.rfc-editor.org/info/rfc7659>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2. Informative References
+
+ [IPFIX-IANA]
+ IANA, "IPFIX Information Elements",
+ <http://www.iana.org/assignments/ipfix>.
+
+ [NAT-LOG] Chen, Z., Zhou, C., Tsou, T., and T. Taylor, Ed., "Syslog
+ Format for NAT Logging", Work in Progress, draft-ietf-
+ behave-syslog-nat-logging-06, January 2014.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ DOI 10.17487/RFC0791, September 1981,
+ <https://www.rfc-editor.org/info/rfc791>.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations",
+ RFC 2663, DOI 10.17487/RFC2663, August 1999,
+ <https://www.rfc-editor.org/info/rfc2663>.
+
+ [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
+ Address Translator (Traditional NAT)", RFC 3022,
+ DOI 10.17487/RFC3022, January 2001,
+ <https://www.rfc-editor.org/info/rfc3022>.
+
+ [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+ Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
+ <https://www.rfc-editor.org/info/rfc3234>.
+
+ [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
+ DOI 10.17487/RFC5424, March 2009,
+ <https://www.rfc-editor.org/info/rfc5424>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 33]
+
+RFC 8158 IPFIX IEs for NAT Logging December 2017
+
+
+Acknowledgements
+
+ 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 Trammell for their
+ review and comments.
+
+Authors' Addresses
+
+ Senthil Sivakumar
+ Cisco Systems
+ 7100-8 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States of America
+
+ Phone: +1 919 392 5158
+ Email: ssenthil@cisco.com
+
+
+ Reinaldo Penno
+ Cisco Systems
+ 170 W Tasman Drive
+ San Jose, CA 95035
+ United States of America
+
+ Email: repenno@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sivakumar & Penno Standards Track [Page 34]
+