IPFIX Information Elements for logging NAT Events

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 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, and all the optional fields. The fields specified in this document are gleaned from [RFC4787] and [RFC5382]. This document and [I-D.ietf-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. 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.

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 and the term Binding Information Base (BIB) as it is defined in . The usage of the term Information Element (IE) is defined in [RFC7011]. The term Carrier Grade NAT refers to a large scale NAT device as described in [RFC6888] The IPFIX Information Elements that are NAT specific are created with NAT terminology. In order to avoid creating duplicate IEs, IEs are reused if they convey the same meaning. This 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. This document refers to event templates, that refers to IPFIX template records. This document refers to log events that refers to IPFIX Flow records.

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 .

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 the transport protocol like TCP, UDP or SCTP that is 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. The existing IANA IPFIX IEs registry [IPFIX-IANA] already has assignments for most of the NAT logging events. This document uses the allocated IPFIX IEs and will request IANA for the ones that are defined in this document but not yet allocated. 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 is 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.

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. 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 inline with the operator and the local juridiction. 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 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 events. 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, need for additional IP addresses etc. The deployment of NAT logging is not limited to just these cases.

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 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 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 Table 2. 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. The list of collectors and its associated information like the IPv4/IPv6 address, port and protocol MUST be preserved across reboots. The NAT device implementing the IPFIX logging MUST follow the IPFIX specs as specified in RFC 7011.

Logging of destination information in a NAT event has been discussed in and . 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 the source and destination addresses result in loss of privacy. Logging of destination addresses and ports, pre or post NAT, SHOULD NOT be done [RFC6888]. However, this draft provides the necessary fields to log the destination information in cases where they must be logged.

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, {sourceIPv4Adress, postNATSourceIPv4Address, destinationIpv4Address, postNATDestinationIPv4Address, sourceTransportPort, postNAPTSourceTransportPort, destinationTransportPort, postNAPTDestTransportPort, 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. The following is the table of all the IEs that a NAT device would need to export the events. The formats of the IEs and the IPFIX IDs are listed below. Some of the IPFIX IEs are not yet assigned. The detailed description of these fields that are requested are in the IANA considerations section. Field Name Size (bits) IANA IPFIX ID Description timeStamp 64 323 System Time when the event occured. natInstanceId 32 TBD 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 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 addresss postNATDestinationIPv6Address 128 282 Translated Destination IPv6 address internalAddressRealm OctetArray TBD Source Address Realm externalAddressRealm OctetArray TBD 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 natQuotaExceededEvent 32 TBD Limit event identifier natThresholdEvent 32 TBD Threshold event identifier

The following is the complete list of NAT events and the proposed event type values. The natEvent IE is defined in the IPFIX IANA registry in http://www.iana.org/assignments/ipfix/ipfix.xml. 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. These values were defined prior to the existence of this draft and outside the IETF working group. These events are not standalone and require more information need to be conveyed to qualify the event. For example, the NAT Translation create event does not specify if it is a NAT44 or NAT64. As a result the Behave WG decided to have explicit definition for each one of the unique events. These events are listed here for the purpose of completeness and are already defined in the IPFIX IANA registry. Any compliant implementation SHOULD NOT implement the events that are marked historic. Event Name Values NAT Translation create (Historic) 1 NAT Translation Delete (Historic) 2 NAT Addresses exhausted 3 NAT44 Session create 4 NAT44 Session delete 5 NAT64 Session create 6 NAT64 Session delete 7 NAT44 BIB create 8 NAT44 BIB delete 9 NAT64 BIB create 10 NAT64 BIB delete 11 NAT ports exhausted 12 Quota exceeded 13 Address binding create 14 Address binding delete 15 Port block allocation 16 Port block de-allocation 17 Threshold reached 18

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 has been 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, Maximum active hosts limit reached or maximum subscribers limit reached and Maximum Fragments pending reassembly limit reached. Quota Exceeded Event Name Values Maximum Session entries 1 Maximum BIB entries 2 Maximum entries per user 3 Maximum active hosts or subscribers 4 Maximum fragments pending reassembly 5

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. 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. 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 uses 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 threhold event will then be triggered so that the IPv4 global address can be reclaimed. The Global address mapping high threshold event is generated when the maximum mappings per-user is reached for a NAT device doing paired address pooling. Threshold Exceeded Event Name Values Address pool high threshold event 1 Address pool low threshold event 2 Address and port mapping high threshold event 3 Address and port mapping per user high threshold event 4 Global Address mapping high threshold event 5

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 IE's in the templates. Depending on the implementation and configuration various IEs that are not mandatory can be included or ignored.

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 . 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. 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 32 No internalAddressRealm OctetArray No externalAddressRealm OctetArray No

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 32 No internalAddressRealm OctetArray No externalAddressRealm OctetArray No

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 32 No internalAddressRealm OctetArray No externalAddressRealm OctetArray No

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 32 No internalAddressRealm OctetArray No externalAddressRealm OctetArray No

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

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

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.

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 configuredLimit 32 Yes natInstanceID 32 No

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 configuredLimit 32 Yes natInstanceID 32 No

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 configuredLimit 32 Yes sourceIPv4 address 32 Yes for NAT44 sourceIPv6 address 128 Yes for NAT64 natInstanceID 32 No vlanID/ingressVRFID 32 No

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 configuredLimit 32 Yes natInstanceID 32 No

This event is generated when the number of fragments pending reassembly reaches the administratively configured limit. Note that in 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. Field Name Size (bits) Mandatory timeStamp 64 Yes natEvent 8 Yes natQuotaExceededEvent 32 Yes configuredLimit 32 Yes sourceIPv4 address 32 Yes for NAT44 sourceIPv6 address 128 Yes for NAT64 natInstanceID 32 No vlanID/ingressVRFID 32 No internalAddressRealm OctetArray No

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.

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 (bits) Mandatory timeStamp 64 Yes natEvent 8 Yes natThresholdEvent 32 Yes natPoolID 32 Yes configuredLimit 32 Yes natInstanceID 32 No

This event is generated when the high threshold is reached for the address pool and ports. Field Name Size (bits) Mandatory timeStamp 64 Yes natEvent 8 Yes natThresholdEvent 32 Yes configuredLimit 32 Yes natInstanceID 32 No

This event is generated when the high threshold is reached for the per-user address pool and ports. Field Name Size (bits) Mandatory timeStamp 64 Yes natEvent 8 Yes natThresholdEvent 32 Yes configuredLimit 32 Yes sourceIPv4 address 32 Yes for NAT44 sourceIPv6 address 128 Yes for NAT64 natInstanceID 32 No vlanID/ingressVRFID 32 No

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 configuredLimit 32 Yes natInstanceID 32 No vlanID/ingressVRFID 32 No

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 sourceIPv4 address 32 Yes for NAT44 sourceIPv6 address 128 Yes for NAT64 Translated Source IPv4 Address 32 Yes natInstanceID 32 No

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. 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 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. 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 sourceIPv4 address 32 Yes for NAT44 sourceIPv6 address 128 Yes for NAT64 Translated Source IPv4 Address 32 Yes portRangeStart 16 Yes portRangeEnd 16 No natInstanceID 32 No

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 are covered in [I-D.ietf-behave-syslog-nat-logging]. This document covers the additional considerations.

An IPFIX collector MUST be able to collect events from multiple NAT devices and be able to decipher events based on the Observation Domain ID in the IPFIX header.

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.

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.

IANA will register the following IEs in the IPFIX Information Elements registry at http://www.iana.org/assignments/ipfix/ipfix.xml

Name : natInstanceID Description: This Information Element uniquely identifies an Instance of the NAT, that runs on a NAT middlebox function after the packet passed the Observation Point. natInstanceID is defined in RFC 7659 [RFC7659] Abstract Data Type: unsigned32 Data Type Semantics: identifier Reference: See RFC 791 [RFC0791] 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.

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 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. Abstract Data Type: octetArray Data Type Semantics: identifier Reference: See RFC 791 [RFC0791] 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.

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 RFC 791 [RFC0791] 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.

Values of this Information Element are defined in a registry maintained by IANA at . New assignments of values will be administered by IANA, subject to Expert Review [RFC5226]. Experts need to check definitions of new values for completeness, accuracy, and redundancy. 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 exceed event type registry, see [http://www.iana.org/assignments/ipfix/ipfix.xml#TBD-by-IANA] Initial values in the registry are defined by the table below. Quota Exceeded Event Name Values Maximum Session entries 1 Maximum BIB entries 2 Maximum entries per user 3 Maximum active hosts or subscribers 4 Maximum fragments pending reassembly 5 Abstract Data Type: unsigned32 Data Type Semantics: identifier Reference: See RFC 791 [RFC0791] 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.

Values of this Information Element are defined in a registry maintained by IANA at http://www.iana.org/assignments/ipfix/ipfix.xml#TBD-by-IANA. New assignments of values will be administered by IANA, subject to Expert Review [RFC5226]. Experts need to check definitions of new values for completeness, accuracy, and redundancy. Name: natThresholdEvent Description: This Information Element identifies a type of a NAT threshold event. Values for this Information Element are listed in the NAT threshhold event type registry, see . Initial values in the registry are defined by the table below. Threshold Exceeded Event Name Values Address pool high threshold event 1 Address pool low threshold event 2 Address and port mapping high threshold event 3 Address and port mapping per user high threshold event 4 Global Address mapping high threshold event 5 Abstract Data Type: unsigned32 Data Type Semantics: identifier Reference: See RFC 791 [RFC0791] 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.

The original definition of this Information Element specified only three values 1, 2, and 3. This definition is replaced by a registry, to which new values can be added. The semantics of the three originally defined values remains unchanged. IANA maintains the registry for values of this Information Element at . New assignments of values will be administered by IANA, subject to Expert Review [RFC5226]. Experts need to check definitions of new values for completeness, accuracy, and redundancy. Name : natEvent Description: Description: This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include but not limited to, creation or deletion of a NAT translation entry, a threshold reached or exceeded etc. Values for this Information Element are listed in the NAT event type registry, see [http://www.iana.org/assignments/ipfix/ipfix.xml#TBD-by-IANA] The NAT Event values in the registry are defined by the Table 2 in Section 5.3. Abstract Data Type: unsigned8 Data Type Semantics: identifier Element ID : 230 Reference: See RFC 3022 [RFC3022] for the definition of NAT. See RFC 3234 [RFC3234] for the definition of middleboxes. See [thisRFC] for the definitions of values 4-16.

The security considerations listed in detail for IPFIX in applies to this draft as well. As described in 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 . 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. The logging of NAT events can result in privacy concerns as result of exporting information such as source address and port information. The logging of destinaion 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 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.