Syslog Format for NAT Logging
draft-ietf-behave-syslog-nat-logging-06

Abstract

NAT devices are required to log events like creation and deletion of translations and information about the resources the NAT is managing. The logs are required to identify an attacker or a host that was used to launch malicious attacks, and for various other purposes of accounting and management. Since there is no standard way of logging this information, different NAT devices behave differently. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information.

This document describes the information that is required to be logged by the NAT devices. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 7011). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging.

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 July 28, 2014.

Copyright Notice

Copyright (c) 2014 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. Introduction
• 1.1. Terminology
• 2. Deployment Considerations
• 2.1. Static and Dynamic NATs
• 2.2. Realms and Address Pools
• 2.2.1. Address Pools
• 2.3. NAT Logging Requirements For Different Transition Methods
• 2.4. Subscriber Identification
• 2.5. The Port Control Protocol (PCP)
• 2.6. Logging At the Customer Edge
• 3. NAT-Related Events and Parameters
• 3.1. Events Relating To Allocation Of Resources To Hosts
• 3.1.1. NAT Address Mapping Creation and Deletion
• 3.1.2. NAT Address and Port Mapping Creation and Deletion
• 3.1.3. NAT Session Creation and Deletion
• 3.1.3.1. Destination Logging
• 3.1.4. Port Range Allocation and Deallocation
• 3.2. Threshold Events
• 3.2.1. Address Pool High- and Low-Water-Mark Threshold Events
• 3.2.2. Global Address Mapping High-Water-Mark Threshold Event
• 3.2.3. Global Address and Port Mapping High-Water-Mark Threshold Event
• 3.2.4. Subscriber-Specific Address and Port Mapping Threshold Event
• 3.3. Limit-Related Events
• 3.3.1. Global Address Mapping Limit Exceeded
• 3.3.2. Global Address and Port Mapping Limit Exceeded
• 3.3.3. Global Limit On Number of Active Hosts Exceeded
• 3.3.4. Subscriber-Specific Limit On Number of Address and Port Mappings Exceeded
• 3.3.5. Global Limit On Number Of Fragments Pending Reassembly Exceeded
• 4. SYSLOG Applicability
• 5. SYSLOG Record Format For NAT Logging
• 5.1. SYSLOG HEADER Fields
• 5.2. Parameter Encodings
• 5.2.1. General Encoding Rules
• 5.2.2. Special Cases
• 5.2.3. Relationship To Objects In the NAT MIB
• 5.3. Encoding Of Complete Log Report For Each Event Type
• 5.3.1. Encoding of Events Relating To Allocation Of Resources To Hosts
• 5.3.1.1. NAT Address Mapping Creation and Deletion
• 5.3.1.2. NAT Address and Port Mapping Creation and Deletion
• 5.3.1.3. NAT Session Creation and Deletion
• 5.3.1.4. Port Range Allocation and Deallocation
• 5.3.2. Encoding of Threshold Events
• 5.3.2.1. NAT Address Pool High- and Low-Water-Mark Threshold Events
• 5.3.2.2. Global Address Mapping High-Water-Mark Threshold Exceeded
• 5.3.2.3. Global Address and Port Mapping High-Water-Mark Threshold Event
• 5.3.2.4. Subscriber-Specific Address and Port Mapping High-Water-Mark Threshold Event
• 5.3.3. Encoding of Limit Events
• 5.3.3.1. Global Address Mapping Limit Exceeded
• 5.3.3.2. Global Address and Port Mapping Limit Exceeded
• 5.3.3.3. Global Limit On Number of Active Hosts Exceeded
• 5.3.3.4. Subscriber-Specific Limit On Number of Address and Port Mappings Exceeded
• 5.3.3.5. Pending Fragment Limit Exceeded
• 6. Management Considerations
• 6.1. General Requirements For Control Of Logging
• 6.1.1. Configuration of PRI Value
• 6.1.2. Ability For Each Collector To Detect Lost Event Reports
• 6.1.3. Ability To Rate Limit Or Disable Event Reports
• 6.2. Setting Limits and Thresholds
• 6.3. Other Management Requirements
• 7. Security Considerations
• 8. IANA Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

This document deals with logging of NAT activity in two categories: NAT translations and NAT resource usage.

Operators already need to record the addresses assigned to subscribers at any point in time, for operational and regulatory reasons. When operators introduce NAT devices that support address sharing (e.g., Carrier Grade NATs (CGNs)) into their network, additional information has to be logged. This document and [I-D.behave-ipfix-nat-logging] are provided in order to standardize the events and parameters to be recorded, using SYSLOG [RFC5424] and IPFIX [RFC7011] respectively. The same content is proposed to be logged by both documents.

In addition to records of subscriber activity, some operators use logs to indicate when utilization of critical resources is approaching or has reached limits set by the operator or implementation. This document and the IPFIX document therefore provide logs in two categories: thresholds exceeded and limits exceeded. Operators have the alternative to receive the threshold limits as SNMP notifications (see the NAT MIB [I-D.behave-NAT-MIB]).

Detailed logging requirements will vary depending on the context in which they are used. For example, different methods for transition from IPv4 to IPv6 require different events and different parameters to be logged. Section 2 covers this topic.

Section 3 provides a detailed description of the events that need logging and the parameters that may be required in the logs. Section 3.1 describes events related to subscriber activity, Section 3.2 covers threshold events, and Section 3.3 covers events where hard limits have been reached.

The use of SYSLOG [RFC5424] has advantages and disadvantages compared with the use of IPFIX [RFC7011]. Section 4 provides a statement of applicability for the SYSLOG approach.

Section 5 specifies SYSLOG record formats for logging of the events and parameters described in Section 3. Section 5.1 describes the SYSLOG header format for each report, Section 5.2 lists and describes the encoding of parameters that can appear in the logs, and Section 5.3 specifies the encoding of the body of each event report. The definitions provide the flexibility to vary actual log contents based on the requirements of the particular deployment.

1.1. Terminology

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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

This document makes frequent reference to the NAT MIB. That reference is to the document [I-D.behave-NAT-MIB].

This document makes frequent reference to NAT behaviours defined in [RFC4784]. In particular it refers to

• the recommended pooling behaviour "pooled" and its contrary pooling behaviour "arbitrary"; and
• the recommended mapping behaviour "endpoint-independent" and its contrary mapping behaviour "endpoint-dependent".

This document uses the term "address mapping" to denote an association between an internal IP address and an IP address in a selected external realm. See Section 2.2 for a further discussion of this process.

• The natMapIntAddrTable in the NAT MIB provides details on all currently active address mappings. Note that this table is applicable only when NAT pooling behaviour is "paired".

This document uses the [RFC4787] term "address and port mapping" to denote a three-tuple association between an internal IP address and port and an IP address and port in a selected external realm, or between an internal <IP address, ICMP identifier> pair and an <IP address, ICMP identifier> pair in the selected realm. For implementations which maintain a Binding Information Base (BIB) (as described in Section 2 of [RFC6146], for example), the content of a BIB entry is an address and port mapping.

• The natMappingTable in the NAT MIB provides details on all currently active address and port mappings.

This document uses the term "session" as it is defined in [RFC2663], Section 2.3. From the point of view of this document, session creation involves the combination of a source address and port mapping with a mapping between internal and external destination address and port to create a full five-tuple mapping.

Except where a clear distinction is necessary, this document uses the abbreviation "NAT" to encompass both Network Address Translation (NAT in the strict sense) and Network Address and Port Translation (NAPT). The event report descriptions provided in this document apply to NAPT, and can be simplified for pure NAT operation.

To match the terminology used by the NAT MIB, this document uses the term "subscriber" to denote any device being served by the NAT, whether individual host or customer edge router. That is, despite the carrier-oriented terminology, the intended scope of applicability of this document is both to NATs in the carrier network and managed NATs in the customer network.

Finally, with two exceptions, when the terms "source" or "destination" are used below, they denote the source and destination of packets that are flowing from the internal to the external realm, regardless of the direction of session establishment or the direction of flow of an individual packet. The exceptions relate to the global address and port mapping limit event and the pending fragment limit event, when the actual source and destination addresses in the header of the packet that hit the limit are reported.

2. Deployment Considerations

2.1. Static and Dynamic NATs

A NAT controls a set of resources in the form of one or more pools of external addresses. If the NAT also does port translation (i.e., it is a NAPT), it also controls the sets of UDP and TCP port numbers and ICMP identifiers associated with each external address.

Logging requirements for a NAT depend heavily on its resource allocation strategy. NATs can be classed as static or dynamic depending on whether the resources provided to individual users are pre-configured or allocated in real time as the NAT recognizes new flows.

Static assignments can be logged at configuration time by the NAT or by network infrastructure. The logging volume associated with static assignments will be relatively low, of the order of the volume of user logons.

Dynamic assignments typically require both more detail in the logs and a higher volume of logs in total. A traditional Network Address Port Translator (NAPT) as described in [RFC3022] and following the recommendations of [RFC4787] and [RFC5382] will generate a new address and port mapping each time it encounters a new internal <address, port> combination.

For statistical reasons, static assignments support lower address sharing ratios than fully dynamic assignments as exemplified by the traditional NAPT. The sharing ratio can be increased while restraining log volumes by assigning ports to users in multi-port increments as required rather than assigning just one port at a time. A subscriber may start with no initial allocation, or may start with an initial permanent allocation to which temporary increments are added when the initial set is all being used. See [RFC6264] and [I-D.tsou-behave-natx4-log-reduction] for details. If this strategy is followed, logging will be required only when an increment is allocated or reclaimed rather than every time an internal <address, port> combination is mapped to an external <address, port>.

2.2. Realms and Address Pools

A realm identifies an IP numbering space. A NAT session always maps between an internal and an external realm. In simple NAT configurations, it may be possible to identify a default internal realm and/or a default external realm for all sessions. In more complex NAT configurations a given realm may be an internal realm for some sessions and an external realm for others. Realms without subscriber sites are always external.

Address pools are associated with specific realms in their external role.

It is necessary to define multiple realms when the NAT supports overlapping IP numbering spaces. In such a case, the NAT must determine the source realm and subscriber using additional information associated with the incoming packet. See further discussion in Section 2.4.

2.2.1. Address Pools

An address pool is a mechanism for configuring the set of addresses to which a given internal address can be mapped in a given realm. The pool may be used simply to ration the available addresses within that realm, or may be selected for other reasons such as to add additional semantics (e.g., type of service required) to the external address within the target realm. Clearly a given internal address may be mapped into more than one address pool at a given time.

The model of an address pool assumed in this document and in the NAT MIB is that the pool offers a fixed range of port/ICMP identifier values, the same over all addresses within the pool. How these are allocated to individual mappings depends on the pooling behaviour. With a pooling behaviour of "arbitrary", the NAT can select any address in the pool with a free port value for the required protocol and map the internal address to it. With the recommended pooling behaviour of "paired", the NAT restricts itself to finding a free port at the address to which the internal address is already mapped, if there is one.

From this description, one can see that ports are a limited resource, subject to exhaustion at the pool level and, with "paired" behaviour, at the level of the individual address. Log events are defined in Section 3.2.1 that allow monitoring of port utilization at the pool level. Section 6.2 discusses how the thresholds for triggering these events should be varied depending on pooling behaviour.

2.3. NAT Logging Requirements For Different Transition Methods

A number of transition technologies have been or are being developed to aid in the transition from IPv4 to IPv6. 6rd [RFC5969] and DS-Lite [RFC6333] are at the deployment stage. Several 'stateless' technologies: Public IPv4 over IPv6 [RFC7040], MAP-E [I-D.softwire-map], and Lightweight 4over6 [I-D.softwire-lw4over6] have seen experimental deployment and are in the process of being standardized at the time of writing of this document.

Of the technologies just listed, 6rd and Public IPv4 over IPv6 do not involve NATs and hence need not be considered further. The other techniques involve NAT at the customer edge, at the border router, or both, and hence are in scope.

A DS-Lite Address Family Transition Router (AFTR) includes a large-scale session-stateful NAT44 processing potentially millions of sessions per second. The special character of AFTR operation over that of a traditional NAT44 is that the source IPv4 addresses of the internal hosts will not be unique. As a consequence, identification of the realm and subscriber from which the packet was sent needs to include an additional identifier associated with the subscriber host. For basic DS-Lite, this will be the IPv6 address used to encapsulate the packets outgoing from the host. See Section 6.6 of [RFC6333]. For gateway-initiated DS-Lite [RFC6674], two identifiers are needed: an identifier of the softwire from the gateway to the NAT, and an identifier associated with the incoming tunnel to the gateway.

The DS-Lite customer edge equipment (the 'B4') may also perform NAT44 functions, similar to the functions performed by traditional NAT44 devices.

As a NAT44, the DS-Lite AFTR may be fully dynamic, or may allocate ports in increments as described in the previous section.

Lightweight 4over6 [I-D.softwire-lw4over6] and MAP-E [I-D.softwire-map] both require NAT44 operation at the customer edge. In both cases the resource allocation strategy is static. Thus any logging of resource allocation for these two transition techniques can be done by the network at configuration time.

2.4. Subscriber Identification

The ability to identify the particular subscriber involved in an event is required for the events defined in Section 3.1, and desirable for technician follow-up for those defined in Section 3.2.4 and Section 3.3.

As mentioned above, in some NAT configurations the source address is insufficient to identify an individual subscriber because of overlapping address space, and additional information is required. For example, if the NAT supports DS-Lite [RFC 6333], the source address of incoming packets from DS-Lite subscribers will always be in the range 192.0.0/29. The additional information required in this case is the IPv6 address of the encapsulating header.

The natSubscribersTable in the NAT MIB contains the additional information needed, if any, to identify each subscriber. Thus it is sufficient to include the index to this table in the event report to provide the needed identification. However, this implies that for full interpretation of the event report, the configuration information stored in the natSubscribersTable must be stored (along with AAA information relating the additional identifiers to the subscriber profiles, which must be stored in any event). To relieve the operator of the need to store the configuration data (given that the logs may be needed months or years after they were recorded), the reports specified in Section 3.1 include the additional identifying information that is found in the natSubscribersTable.

This document standardizes the presentation of the following possible additional classifying information within NAT-related log reports:

• interface index [RFC2863];
• VLAN index [RFC4363];
• VPN identifier [RFC4265];
• DS-Lite encapsulating IPv6 address [RFC6333].

Which of these is actually used in a given NAT depends on implementation and deployment.

• Gateway-Initiated DS-Lite [RFC6674] identifiers could also be specified, but it seems premature to do so because it is not clear which of the variety of possibilities presented in Section 6 and Appendix A.2 of [RFC6674] are actually being deployed.

2.5. The Port Control Protocol (PCP)

The Port Control Protocol (PCP) [RFC6887] and its port set extension [I-D.pcp-port-set] can be viewed as a way to provision ports by other means. However, PCP can be invoked on a per-flow basis, so the volume of logs generated by a PCP server can be closer to the volume associated with a fully dynamic NAT. The volume really depends on how PCP is being used in a specific network.

2.6. Logging At the Customer Edge

Logging at the customer edge (or at the ISP edge for NATs protecting the ISP's internal networks) may be done by the customer for purposes of internal management, or by the ISP for its own administrative and regulatory purposes. Given the likelihood of a high internal community of interest, it is possible but unlikely that a NAT at the edge of a large enterprise network processes a number of new packet flows per second which is comparable to the volume handled by a carrier grade NAT. Most customer edge NATs will handle a much smaller volume of flows.

3. NAT-Related Events and Parameters

The events which follow were initially gleaned, in the words of the authors of [I-D.behave-ipfix-nat-logging], from [RFC4787] and [RFC5382]. Some details were subsequently informed by the discussion in Section 2 and by provisions within the NAT MIB. Section 4 of [RFC6888] also provides a brief statement of logging requirements for carrier grade NATs.

In SYSLOG, the timestamp and the event type will appear in the log header rather than as an explicit part of the structured data portion of the log. Hence they are omitted from the parameter tabulations that follow.

Parameters marked CONDITIONAL are REQUIRED under some circumstances but not others. Details are provided for each event.

3.1. Events Relating To Allocation Of Resources To Hosts

Setting up a NAT session proceeds in a series of logical steps: creation of an address mapping, creation of an address and port mapping, and finally, creation of the session.

The reports corresponding to these three steps are defined in Section 3.1.1, Section 3.1.2, and Section 3.1.3 respectively. Which of these reports is enabled depends on the NAT implementation and operator preferences, subject to the considerations of the next paragraph.

If the NAT implements the recommended pooling behaviour of "paired", address mapping creation is an event distinct in general from the creation of a subsequent address and port mapping based on that address mapping. However, if the pooling behaviour is "arbitrary" [RFC4787], the two events occur simultaneously and there is no point in reporting both. Similarly, if the NAT implements the recommended mapping behaviour of "endpoint-independent mapping", the two events of address and port mapping creation and session creation based on that mapping are distinct and may meaningfully be reported separately. However, if the mapping behaviour is "endpoint-dependent", the two events occur simultaneously and it is only meaningful to report session creation.

The fourth report type in this section describes the bulk allocation of ports to an address mapping, which the NAT may implement if the pooling behaviour is "paired" [RFC4787]. It, along with the other reports, is needed to provide complete accountability for resources allocated to the subscriber.

3.1.1. NAT Address Mapping Creation and Deletion

Two specific events are provided:

• NAT address mapping creation;
• NAT address mapping deletion.

Implementations MUST NOT report these events unless pooling behaviour is "paired".

Address mapping is discussed in detail in Section 2.2.

One address mapping creation event is associated with potentially many succeeding address and port mapping creation events, as individual port values are mapped for specific protocols. Similarly, an address mapping deletion event may be associated with potentially many address and port mapping deletion events, which may have preceded it over a period of time or may occur at the same time as a result of the address unbinding.

The address mapping events take the following specific parameters:

• NAT instance identifier (CONDITIONAL);
• Source subscriber index (MANDATORY);
• Additional source subscriber classifier value as recognized at the ingress to the internal realm (CONDITIONAL);
• Internal realm (CONDITIONAL);
• Internal address type (MANDATORY);
• Internal source IP address (MANDATORY);
• External realm (CONDITIONAL);
• External address type (MANDATORY);
• External source IP address (MANDATORY);
• Trigger for address mapping creation or deletion (OPTIONAL):
  • outgoing packet;
  • administrative action (e.g., via the Port Control Protocol [RFC6887]); or
  • autonomous action of the NAT.

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.
• Additional source subscriber classifier value REQUIRED if the internal source IP address is not enough to identify the subscriber unambiguously, else MUST NOT appear.
• Internal or external realm REQUIRED if not the default internal or external realm, respectively, else MAY appear.

3.1.2. NAT Address and Port Mapping Creation and Deletion

The address and port mapping creation or deletion event reports the addition or deletion of an address and port mapping as defined in Section 1.1. If the implementation maintains a Binding Information Base (BIB), this is equivalent to the creation or deletion of a BIB entry. Implementations MUST support the generation of the address and port mapping creation/deletion event reports if they implement the recommended mapping behaviour "endpoint-independent". They MAY support reporting of these events in the contrary case.

The address and port mapping creation/deletion event report provides the same information as the session creation/deletion event, except for the destination-related fields and (in general) timestamp values in the latter. With "endpoint-independent" mapping behaviour, one address and port mapping creation event is associated with potentially many succeeding session creation events. Similarly, an address and port mapping deletion event will be associated with potentially many session deletion events, which may have preceded it over a period of time or may occur at the same time as a result of the address and port mapping deletion.

Operators should disable the reporting of address and port mapping creation and deletion events when destination logging is enabled, because of the redundancy between the address and port mapping and session event reports. However, if destination logging is disabled and the NAT uses the recommended "endpoint-independent" mapping behaviour, it is the session events that are redundant and should be disabled.

The following specific events are defined:

• NAT address and port mapping creation
• NAT address and port mapping deletion

These take the same parameters for all types of NAT. The internal realm, subscriber-identifying information, internal source IP address, external realm, and external source IP address capture the underlying address mapping. The port values and protocol are unique to the address and port mapping.

The parameters for the address and port mapping creation/deletion event are:

• NAT instance identifier (CONDITIONAL);
• Source subscriber index (MANDATORY);
• Additional source subscriber classifier value as recognized at the ingress to the internal realm (CONDITIONAL);
• Internal realm (CONDITIONAL);
• Internal address type (MANDATORY);
• Internal source IP address (MANDATORY);
• Internal source port or ICMP identifier (MANDATORY);
• External realm (CONDITIONAL);
• External address type (MANDATORY);
• External source IP address (MANDATORY);
• External source port or ICMP identifier (MANDATORY);
• Protocol identifier (MANDATORY);
• Trigger for address and port mapping creation or deletion (OPTIONAL):
  • outgoing packet received;
  • incoming packet received;
  • administrative action (e.g., via the Port Control Protocol [RFC6887]); or
  • deletion of the underlying address mapping (applicable only if pooling behaviour is "paired" [RFC4787]).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.
• Additional source subscriber classifier value REQUIRED if the internal source IP address is not enough to identify the subscriber unambiguously, else MUST NOT appear.
• Internal or external realm REQUIRED if not the default internal or external realm, respectively, else MAY appear.

3.1.3. NAT Session Creation and Deletion

A NAT session creation or deletion event is logged when a address and port mapping is further bound to or unbound from a specific destination address and port in the external realm. One to many sessions can be based on the same address and port mapping.

Implementations MUST provide a means for the operator to specify whether destination information is to be included in the reports of these events (see discussion below).

The following specific events are defined:

• NAT session creation
• NAT session deletion

These take the same parameters for all types of NAT. Parameters "internal realm" through "protocol identifier" capture the underlying address and port mapping. Subsequent parameters capture the destination address and destination subscriber identity (if applicable).

The parameters for the session creation/deletion event are:

• NAT instance identifier (CONDITIONAL);
• Internal source subscriber index, equal to the natSubscriberIndex value in the natSubscribersTable in the NAT MIB (MANDATORY);
• Additional internal subscriber classifier value (CONDITIONAL);
• Internal realm (CONDITIONAL);
• Internal address type (MANDATORY);
• Internal source IP address (MANDATORY);
• Internal source port or ICMP identifier (MANDATORY);
• External realm (CONDITIONAL);
• External address type (MANDATORY);
• External source IP address (MANDATORY);
• External source port or ICMP identifier (MANDATORY);
• Protocol identifier (MANDATORY);
• Internal destination IP address (CONDITIONAL);
• Internal destination port or ICMP identifier (CONDITIONAL);
• Destination subscriber index (CONDITIONAL);
• Additional destination subscriber classifier value as recognized at the ingress to the external realm (CONDITIONAL);
• External destination IP address (CONDITIONAL);
• External destination port or ICMP identifier (CONDITIONAL);
• Trigger for session creation or deletion (OPTIONAL):
  • outgoing packet received;
  • incoming packet received;
  • administrative action (e.g., via the Port Control Protocol [RFC6887]); or
  • deletion of the underlying address and port mapping (applicable only if the NAT mapping behaviour is "endpoint-independent".

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.
• Additional source subscriber classifier value REQUIRED if the internal source IP address is not enough to identify the subscriber unambiguously, else MUST NOT appear.
• Internal or external realm REQUIRED if not the default internal or external realm, respectively, else MAY appear.
• Internal destination address and port REQUIRED if destination logging is enabled and these need to be remapped to external destination address and port. Otherwise, if destination logging is disabled, they MUST NOT appear, and if destination logging is enabled, they SHOULD NOT appear because of redundancy.
• External destination subscriber index REQUIRED if destination logging is enabled and the destination is a subscriber served by the NAT, else MUST NOT appear.
• Additional external subscriber classifier value REQUIRED if destination logging is enabled and the destination is a subscriber served by the NAT and the external destination address is not enough to identify the external destination subscriber unambiguously, else MUST NOT appear.
• External destination address and port REQUIRED if destination logging is enabled, else MUST NOT appear.

3.1.3.1. Destination Logging

The logging of destination address and port is undesirable, for several reasons. [RFC6888] recommends against destination logging because of the privacy issues it creates. From an operator's point of view, destination logging is costly not just because of the volume of logs it will generate, but because the NAT now has to carry additional session state so that it only needs to log once per session between two transport end points rather than logging every packet. Finally, [RFC4787], etc. recommend the use of endpoint-independent mapping to maximize the ability of applications to operate through the NAT. In that case, most of the contents of the session creation event report will be repeated for one destination after another.

One possibility is that the implementation provides the operator with the ability to log destinations only for particular subscribers or particular mapped addresses on a special study basis. This facility could be used for trouble-shooting or malicious activity tracing in particular cases as required. If such a capability is provided, the implementation MUST report destination information for sessions matching the specified criteria, but MUST NOT report these events for other sessions.

3.1.4. Port Range Allocation and Deallocation

This event is recorded at a hybrid NAT whenever the set of ports allocated to a given address mapping changes. It is assumed that when ports are allocated in bulk, the same values are allocated for all protocols.

The following specific events are defined:

• Port range allocation;
• Port range deallocation.

The parameters for these events are:

• NAT instance identifier (CONDITIONAL);
• Source subscriber index (MANDATORY);
• Additional source subscriber classifier value as recognized at the ingress to the internal realm (CONDITIONAL);
• Internal realm (CONDITIONAL);
• Internal address type (MANDATORY);
• Internal source IP address (MANDATORY);
• External realm (CONDITIONAL);
• External address type (MANDATORY);
• External source IP address (MANDATORY);
• Lowest port number of the range being allocated or deallocated (MANDATORY).
• Highest port number of the range being allocated or deallocated (MANDATORY).
• Trigger for port range allocation or deallocation (OPTIONAL):
  • outgoing packet received;
  • incoming packet received;
  • administrative action (e.g., via the Port Control Protocol [RFC6887]); or
  • autonomous action of the NAT.

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.
• Additional source subscriber classifier value REQUIRED if the internal source IP address is not enough to identify the subscriber unambiguously, else MUST NOT appear.
• Internal or external realm REQUIRED if not the default internal or external realm, respectively, else MAY appear.

It will be necessary to use multiple event reports to report more complex allocations or deallocations.

3.2. Threshold Events

The events of this section are based on thresholds set by the operator within the NAT MIB. Cross-references to the associated MIB objects are provided for each event. With the exception of the address pool low-water-mark event, the threshold events provide early warning of potential dropped packets due to resource exhaustion or administrator-imposed limits.

3.2.1. Address Pool High- and Low-Water-Mark Threshold Events

Two specific events provide reports on address pool utilization:

• High-water-mark threshold reached or exceeded;
• Low-water-mark threshold reached or under-shot.

Depending on deployment the operator has the alternative of using the SNMP notifications natNotifPoolWater-MarkHigh and natNotifPoolWater-MarkLow defined in the NAT MIB rather than logging these events.

Address pools are discussed in Section 2.2.1. The natPoolTable object in the NAT MIB provides access to parameters describing the utilization level of address-port combinations within a given pool. Since a new mapping cannot be allocated unless a mappable address and a free port on that address are available, it is important to know when the available set of address-port combinations within a given pool is nearing exhaustion. Hence the natPoolTable contains a high-water-mark threshold settable by the operator. An address pool high-water-mark event report is generated when a new mapping into the pool is requested and aggregate address-port utilization is equal to or greater the threshold.

Similarly it can be of interest to know when a pool is under-utilized. Hence the natPoolTable also provides a low-water-mark threshold. An address pool low-water-mark event report is generated when aggregate address-port utilization is equal to or less than the low-water-mark threshold.

Section 6.2 discusses factors affecting the choice of the threshold values.

The high-water-mark threshold event provides a warning that the address-port combinations offered by the pool are nearing exhaustion. Upon exhaustion, subscribers may be unable to establish new connections because no address has enough free port values left to be allocated to an address mapping ("address exhaustion"). This applies to the case of "paired" pooling behaviour, where typically an address will not be allocated unless it has a sufficient number of free ports. Alternatively, new connections cannot be established simply because no address in the pool has a free port number for the required protocol ("port exhaustion").

Packets triggering failed attempts to establish new connections due to address exhaustion are included in the following NAT MIB dropped packet counters:

• globally, natResourceErrors in the natCounters table;
• per protocol, natProtocolResourceErrors in natProtocolTable;
• per subscriber, natSubscriberResourceErrors in natSubscribersTable.

Packets triggering failed attempts to establish new connections due to port exhaustion are counted in the following NAT MIB dropped packet counters:

• globally, natOutOfPortErrors in the natCounters table;
• per protocol, natProtocolOutOfPortErrors in natProtocolTable;
• per subscriber, natSubscriberOutOfPortErrors in natSubscribersTable.

An address pool threshold event report contains the following specific parameters:

• NAT instance identifier (CONDITIONAL);
• Pool identifier (MANDATORY);
• The threshold value set by the administrator (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

3.2.2. Global Address Mapping High-Water-Mark Threshold Event

One specific event allows monitoring of the total number of mappings between internal and external addresses:

• Address mapping high-water-mark threshold exceeded.

Implementations MUST NOT generate this event report unless the pooling behaviour is "paired". Depending on deployment, operators can choose instead to use the SNMP notification natNotifAddrMappings defined in the NAT MIB.

The NAT MIB displays cumulative counts of address mappings created and removed in the natCounters table. When the difference between these two counters is greater than the threshold natAddrMapNotifyThreshold provided in the natLimits table the global address binding high-water-mark threshold event is reported.

The specific parameters provided by this event report are:

• NAT instance identifier (CONDITIONAL);
• Current number of active address mappings (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

3.2.3. Global Address and Port Mapping High-Water-Mark Threshold Event

One specific event allows monitoring of the total number of active address and port mappings. Where the NAT implements a BIB, this is equivalent to the total number of BIB entries.

• address and port mapping high-water-mark threshold exceeded.

Depending on deployment, operators can choose instead to use the SNMP notification natNotifMappings defined in the NAT MIB.

The NAT MIB displays cumulative counts of address and port mappings created and removed in the natCounters table. When the difference between these two counters is greater than the threshold natMappingsNotifyThreshold provided in the natLimits table the global mapping high-water-mark threshold event is reported.

The specific parameters provided by this event report are:

• NAT instance identifier (CONDITIONAL);
• Current number of active address and port mappings (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

3.2.4. Subscriber-Specific Address and Port Mapping Threshold Event

An event is provided to allow monitoring of the total number of active mappings per subscriber:

• Subscriber-specific mapping high-water-mark threshold exceeded.

Depending on deployment, operators can choose instead to use the SNMP notification natNotifSubscriberMappings defined in the NAT MIB.

The NAT MIB displays cumulative counts of address and port mappings created and removed per subscriber in the natSubscribersTable. When the difference between these two counters is greater than the threshold natSubscriberMapNotifyThresh provided in that table the subscriber address and port mapping high-water-mark threshold event is reported.

The specific parameters provided by this event report are:

• NAT instance identifier (CONDITIONAL);
• Index of the affected subscriber (MANDATORY).
• Current number of active mappings for this subscriber (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

3.3. Limit-Related Events

The events of this section are generated when hard limits set by the operator are exceeded. The consequence for service will be dropped packets. As with the threshold events, the description of each report includes cross-references to the associated MIB objects.

3.3.1. Global Address Mapping Limit Exceeded

The global address mapping limit exceeded event is reported when a new address mapping is requested but the total number of address mappings would exceed an administrative limit if it were added. The limit is given by object natLimitAddressMappings in the natLimits table of the NAT MIB. MIB counters giving number of packets dropped due to resource limitations including this one are:

• globally, natResourceErrors in the natCounters table;
• per protocol, natProtocolResourceErrors in natProtocolTable;
• per subscriber, natSubscriberResourceErrors in natSubscribersTable.

Implementations MUST NOT generate this event report unless the pooling behaviour is "paired". Depending on deployment, operators can choose instead to use the SNMP notification natNotifAddrMappings defined in the NAT MIB.

The parameters for this event are:

• NAT instance identifier (CONDITIONAL);
• Index of the affected subscriber (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

The subscriber index is provided to allow the operator to correlate the event with any subscriber complaints or possible abuse.

3.3.2. Global Address and Port Mapping Limit Exceeded

The global address and port mapping limit exceeded event is reported when a new address and port mapping is requested but the total number of address and port mappings would exceed an administrative limit if it were added. The limit is given by object natLimitMappings in the natLimits table of the NAT MIB. MIB counters giving number of packets dropped due to resource limitations including this one are:

• globally, natResourceErrors in the natCounters table;
• per protocol, natProtocolResourceErrors in natProtocolTable;
• per subscriber, natSubscriberResourceErrors in natSubscribersTable.

The parameters for this event are:

• NAT instance identifier (CONDITIONAL);
• Index of the internal subscriber (CONDITIONAL);
• Index of the external subscriber (CONDITIONAL);
• Source realm of the triggering packet (MANDATORY);
• Incoming packet header IP address type (CONDITIONAL);
• Incoming packet source IP address (CONDITIONAL).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.
• The index of the internal subscriber is REQUIRED if the mapping was triggered by a packet outgoing from the internal to the external realm, else MUST NOT appear.
• The index of the external subscriber is REQUIRED if the mapping was triggered by a packet incoming from a subscriber served by the NAT and located in the external realm (i.e., using an address mapping created previously by the internal subscriber), else MUST NOT appear.
• The address type and source IP address from the initiating packet are REQUIRED if the mapping was triggered by a packet incoming from a purely external realm (i.e., using an address mapping created previously by the internal subscriber), else MAY appear.

The subscriber index or packet source address is provided to allow the operator to correlate the event with any subscriber complaints or possible abuse.

3.3.3. Global Limit On Number of Active Hosts Exceeded

The global limit on number of active hosts exceeded event is reported when an address mapping is requested (at least at the logical level) for a host with no previous active mappings, but the total number of active hosts would exceed an administrative limit if it were added. The limit is given by object natLimitSubscribers in the natLimits table of the NAT MIB. MIB counters giving number of packets dropped due to resource limitations including this one are:

• globally, natResourceErrors in the natCounters table;
• per protocol, natProtocolResourceErrors in natProtocolTable;
• per subscriber, natSubscriberResourceErrors in natSubscribersTable.

The parameters for this event are:

• NAT instance identifier (CONDITIONAL);
• Index of the affected subscriber (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

The subscriber index is provided to allow the operator to correlate the event with any subscriber complaints.

3.3.4. Subscriber-Specific Limit On Number of Address and Port Mappings Exceeded

The subscriber-specific limit on number of address and port mappings exceeded event is reported when a new mapping is requested, but the total number of active mappings for that subscriber would exceed an administrative limit if it were added. The limit is given by object natSubscriberLimitMappings in natSubscribersTable in the NAT MIB. MIB counters giving number of packets dropped due to resource limitations including this one are:

• globally, natResourceErrors in the natCounters table;
• per protocol, natProtocolResourceErrors in natProtocolTable;
• per subscriber, natSubscriberResourceErrors in natSubscribersTable.

The parameters for this event are:

• NAT instance identifier (CONDITIONAL);
• Index of the affected subscriber (MANDATORY).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.

The subscriber index is provided to allow the operator to take administrative action or to correlate the event with any subscriber complaints or possible abuse.

3.3.5. Global Limit On Number Of Fragments Pending Reassembly Exceeded

The global limit on number of fragments pending reassembly exceeded event is reported when a new fragment is received and the number of fragments currently awaiting reassembly is already equal to an administrative limit. That limit is given by the natLimitFragments object in the natLimits table. This event MUST NOT be reported unless the NAT supports the "receive fragments out of order" behavior [RFC4787]. MIB counters giving number of packets dropped due to resource limitations including this one are:

• globally, natResourceErrors in the natCounters table;
• per protocol, natProtocolResourceErrors in natProtocolTable;
• per subscriber, natSubscriberResourceErrors in natSubscribersTable.

The parameters for this event provide the contents of the IP header of the received fragment that triggered it. If the source of the packet is a subscriber served by the NAT and the subscriber index can be determined, it MUST also be included.

• NAT instance identifier (CONDITIONAL);
• Source realm of the packet (MANDATORY);
• Packet header IP address type (MANDATORY);
• Packet source IP address (MANDATORY);
• Packet destination IP address (MANDATORY);
• Source subscriber index (CONDITIONAL).

Conditions:

• NAT instance identifier REQUIRED if device supports more than one instance, else MAY appear.
• Source subscriber index REQUIRED if the source of the packet is a subscriber served by the NAT and can be determined, else MUST NOT appear.

4. SYSLOG Applicability

The primary advantage of SYSLOG is the human readability and searchability of its contents. In addition, it has built-in priority and other header fields that allow for separate routing of reports requiring management action. Finally, it has a well-developed underpinning of transport and security protocol infrastructure.

SYSLOG presents two obstacles to scalability: the fact that the records will typically be larger than records based on a binary protocol such as IPFIX, and, depending on the architectural context, the reduced performance of a router that is forced to do text manipulation in the data plane. One has to conclude that for larger message volumes, IPFIX should be preferred as the reporting medium on the NAT itself. It is possible that SYSLOG could be used as a back-end format on an off-board device processing IPFIX records in real time, but this would give a limited boost to scalability. One concern expressed in list discussion is that when the SYSLOG formatting process gets overloaded records will be lost.

As a result, the key question is what the practical cutoff point is for the expected volume of SYSLOG records, on-board or off-board the NAT. This obviously depends on the computing power of the formatting platform, and also on the record lengths being generated.

Information has been provided to the BEHAVE list at the time of writing to the effect that one production application is generating an average of 150,000 call detail records per second, varying in length from 500 to 1500 bytes. Capacities several times this level have been reported involving shorter records, but this particular application has chosen to limit the average in order to handle peaks.

As illustrated by the example in Section 5.3.1.3, if destination logging is enabled, typical record sizes for session event logs are in the order of 300 bytes, so throughput capacity should be higher than in the call detail case for the same amount of computing power. However, note that bursts of session deletion events may occur as a result of deletion of the underlying mapping or address mapping.

In private communication, a discussant has noted a practical limit of a few hundred thousand SYSLOG records per second on a router.

5. SYSLOG Record Format For NAT Logging

This section describes the SYSLOG record format for NAT logging in terms of the field names used in [RFC5424] and specified in Section 6 of that document. In particular, this section specifies values for the APP-NAME and MSGID fields in the record header, the SD-ID identifying the STRUCTURED-DATA section, and the PARAM-NAMEs and PARAM-VALUE types for the individual possible parameters within that section. The specification is in three parts, covering the header, encoding of the individual parameters, and encoding of the complete log record for each event type.

5.1. SYSLOG HEADER Fields

Within the HEADER portion of the SYSLOG record, the priority (PRI) level is subject to local policy, but a Severity value of 6 (Informational) is suggested for the events relating to creation and deletion of sessions, mappings, address mappings, and port allocation, combined with a suitable Facility value in the range 16-23 (local use) to ensure routing to a secure collector. The Facility value(s) for the threshold and limit events will presumably be chosen to route them to maintenance for immediate action and/or to provisioning for less urgent consideration. The suggested value of Severity by event type is shown in Table 1, but in practice has a clear dependency on the context within which the NAT is operating.

The TIMESTAMP field SHOULD be expressed with sufficient precision to distinguish non-simultaneous event occurrences, subject to the accuracy of the local clock. This specification does not assume the ability to correlate the events reported by the subject device with events recorded by other devices, although that may be required for other reasons. Hence from the point of view of this specification only relative rather than absolute accuracy is of interest.

The HOSTNAME header field MUST identify the NAT device. The value of the HOSTNAME field is subject to the preferences given in Section 6.2.4 of [RFC5424].

The values of the APP-NAME and MSGID fields in the record header determine the semantics of the record. To simplify log collection procedures, the APP-NAME value "NAT" MUST be used for the event reports specified in Section 5.3.1, the APP-NAME value "NATTHR" MUST be used for the event types defined in Section 5.3.2, and the APP-NAME value "NATLIM" MUST be used for the event types defined in Section 5.3.3.

The MSGID values indicate the individual events. They are listed in Table 1 for each of the events defined in Section 3. The table also shows the SD-ID value used to label the event-specific STRUCTURED-DATA element.