IPFIX Information Elements for logging NAT Events
draft-ietf-behave-ipfix-nat-logging-08

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. The logs are essential in many cases to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices log the information using proprietary formats and hence it is difficult to expect a consistent behavior. The lack of a consistent way to log the data makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the formats for logging of NAT events.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 9, 2016.

Copyright Notice

Copyright (c) 2016 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 (http://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. Terminology
• 2. Introduction
• 2.1. Requirements Language
• 3. Scope
• 4. Deployment
• 5. Event based logging
• 5.1. Logging of destination information
• 5.2. Information Elements
• 5.3. Definition of NAT Events
• 5.4. Quota exceeded Event types
• 5.5. Threshold reached Event types
• 5.6. Templates for NAT Events
• 5.6.1. NAT44 create and delete session events
• 5.6.2. NAT64 create and delete session events
• 5.6.3. NAT44 BIB create and delete events
• 5.6.4. NAT64 BIB create and delete events
• 5.6.5. Addresses Exhausted event
• 5.6.6. Ports Exhausted event
• 5.6.7. Quota exceeded events
• 5.6.7.1. Maximum session entries exceeded
• 5.6.7.2. Maximum BIB entries exceeded
• 5.6.7.3. Maximum entries per user exceeded
• 5.6.7.4. Maximum active host or subscribers exceeded
• 5.6.7.5. Maximum fragments pending reassembly exceeded
• 5.6.8. Threshold reached events
• 5.6.8.1. Address pool high or low threshold reached
• 5.6.8.2. Address and port high threshold reached
• 5.6.8.3. Per-user Address and port high threshold reached
• 5.6.8.4. Global Address mapping high threshold reached
• 5.6.9. Address binding create and delete events
• 5.6.10. Port block allocation and de-allocation
• 6. Encoding
• 6.1. IPFIX
• 7. Acknowledgements
• 8. IANA Considerations
• 8.1. New Information Elements
• 8.2. Modified Information Elements
• 9. Management Considerations
• 9.1. Ability to collect events from multiple NAT devices
• 9.2. Ability to suppress events
• 10. Security Considerations
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses

1. Terminology

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 [RFC2663] and the term Binding Information Base (BIB) as it is defined in [RFC6146]. 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.

2. Introduction

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

2.1. Requirements Language

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 [RFC2119].

3. Scope

This document provides the information model to be used for logging the NAT events including Carrier Grade NAT (CGN) events. This document focuses exclusively on the specification of IPFIX IEs. [RFC7011] provides guidance on the choices of the transport protocols used for IPFIX and their effects. This document does not provide guidance on the transport protocol like TCP, UDP or SCTP that is to be used to log NAT events. The log events SHOULD NOT be lost but the choice of the actual transport protocol is beyond the scope of this document.

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.

4. Deployment

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.

A collector may have scale issues if it is overloaded by a large number of simultaneous events. An appropriate throttling mechanism shall 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.

5. Event based logging

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 transport address, port and protocol MUST be preserved across reboots.

Prior to logging any events, the NAT device MUST send the template of the record to the collector to advertise the format of the data record that it is using to send the events. The templates can be exchanged as frequently as required given the reliability of the connection. There SHOULD be a configurable timer for controlling the template refresh. The IPFIX template management is described in detail in Section 8 of [RFC7011]. The NAT device SHOULD combine as many events as possible in a single packet to effectively utilize the network bandwidth.

5.1. Logging of destination information

Logging of destination information in a NAT event has been discussed in [RFC6302] and [RFC6888]. Logging of destination information increases the size of each record and increases the need for storage considerably. It increases the number of log events generated because when the same user connects to a different destination, it results in a log record per destination address. Logging of destination information also results in the loss of privacy and hence should be done with caution. However, this draft provides the necessary fields to log the destination information in cases where they should be logged.

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

{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.168.16.1, 201.1.1.100, 207.85.231.104, 207.85.231.104, 14800, 1024, 80, 80, 0, 1, 09:20:10:789}

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 assigned yet, and hence the detailed description of these fields are requested in the IANA considerations section.