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

Abstract

With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for legal purposes. The logs may be required to identify a host that was used to launch malicious attacks or engage in illegal behaviour, and/or may be required for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. 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 5101). 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 November 09, 2013.

Copyright Notice

Copyright (c) 2013 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. NAT Logging Requirements For Different Transition Methods
• 2.2. Architectural Context
• 3. NAT-Related Events and Parameters
• 3.1. NAT Session Creation and Deletion
• 3.2. Binding Information Base (BIB) Entry Creation and Deletion
• 3.3. Address Binding Event
• 3.4. Port Block Allocation and Deallocation
• 3.5. NAT Address Exhaustion Event
• 3.6. Port Exhaustion Event
• 3.7. Quota Exceeded Event
• 3.8. Invalid Port Detected
• 4. SYSLOG Applicability
• 5. SYSLOG Record Format For NAT Logging
• 5.1. SYSLOG HEADER Fields
• 5.2. Parameter Encodings
• 5.2.1. NTyp: NAT Type
• 5.2.2. NID: NAT Identifier
• 5.2.3. VLANid: VLAN Identifier
• 5.2.4. VRFid: VPN Routing and Forwarding Identifier
• 5.2.5. PreS4: Pre-NAT IPv4 Source Address
• 5.2.6. PreS6: Pre-NAT IPv6 Source Address
• 5.2.7. Enc6: Encapsulating IPv6 Source Address
• 5.2.8. PostS4: Post-NAT Source IPv4 Address
• 5.2.9. Proto: Protocol Identifier
• 5.2.10. PreSPt: Pre-NAT Source Port or ICMP Identifier
• 5.2.11. PostSPt: Post-NAT Source Port or ICMP Identifier
• 5.2.12. PreD4: Pre-NAT Destination IPv4 Address
• 5.2.13. PreD6: Pre-NAT Destination IPv6 Address
• 5.2.14. PostD4: Post-NAT Destination IPv4 Address
• 5.2.15. PostDPt: Post-NAPT Destination Port or ICMP Identifier
• 5.2.16. TrigR: Realm Triggering Session Creation
• 5.2.17. PtMin: Starting Port Number
• 5.2.18. PtMax: Ending Port Number
• 5.2.19. PtRgSz: Port Range Size
• 5.2.20. PtRgStp: Step Size Between Port Ranges
• 5.2.21. APoolId: Address Pool Identifier
• 5.2.22. QTyp: Quota Limit Type
• 5.2.23. PSID: Port Set Identifier
• 5.3. Encoding Of Complete Log Report For Each Event Type
• 5.3.1. NAT Session Creation and Deletion
• 5.3.1.1. Examples
• 5.3.2. Binding Information Base (BIB) Entry Creation or Deletion
• 5.3.3. Address Binding Event
• 5.3.4. Port Block Allocation and Deallocation
• 5.3.5. Address Exhaustion Event
• 5.3.6. NAT Port Exhaustion
• 5.3.7. Quota Exceeded
• 5.3.8. Invalid Port Detected
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

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 which 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 at the NAT, using SYSLOG [RFC5424] and IPFIX [RFC5101] respectively. The content proposed to be logged by the two documents is exactly the same, but as will be seen, the choice of which to use in a given scenario is an engineering issue.

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. That same section also has a brief discussion of possible architectural arrangements under which log generation is carried out.

Section 3 provides a more detailed description of the events that need logging and the parameters that may be required in the logs.

The use of SYSLOG [RFC5424] has advantages and disadvantages compared with the use of IPFIX [RFC5101]. 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. The definitions provide the flexibility to vary actual log contents based on the requirements of the particular deployment.

Despite the discussion of IPv6 transition technologies, this document is limited to logging of events observed at NAT devices only. Logging of other events associated with IPv6 transition is out of scope.

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 uses the term "Session" as it is defined in Section 2.3 of [RFC2663] and the term Binding Information Base (BIB) as it is defined in Section 2 of [RFC6146].

2. Deployment Considerations

This section deals with two major topics. The first is a review of the major IPv4 to IPv6 transition methods and what they imply for NAT logging. This flows into the second topic, which is the different architectural contexts within which NAT logging may occur. Of course, not all NAT usage occurs in conjunction with IP transition, and traditional NAT usage is also considered.

2.1. 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 [I-D.softwire-public-4over6], 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 interior hosts may not be unique. As a consequence, the session tables need to include the IPv6 addresses used to encapsulate the packets outgoing from those hosts. See Section 6.6 of [RFC6333].

The DS-Lite customer edge equipment (the 'B4') may also perform NAT44 functions, but these will be similar to the functions performed by traditional NAT44 devices. This document therefore does not include any requirements specific to the B4.

To reduce the volume of potential logging at the DS-Lite AFTR, there have been proposals to assign groups of ports to the B4 at one time, assuming that the assignment can be coordinated between the B4 and the AFTR. Examples of such proposals include [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set]. If bulk port assignment is implemented, then instead of logging individual sessions the AFTR will log address binding and bulk port assignment events. Depending on the number of ports assigned at once, this could reduce the volume of logs by one or two orders of magnitude, but at the cost of reducing the average number of subscribers that can share one IPv4 address.

Lightweight 4over6 and MAP-E both require NAT44 operation at the customer equipment, with an added restriction on port number usage. The functions of the customer equipment (the "unified CPE") are specified in [I-D.softwire-unified-cpe]. A mapping between an IPv4 address (in general, shared between subscribers), an IPv6 address used for the encapsulating tunnel to the border router, and an assigned set of port numbers defined by a port set identifier is provisioned rather than established dynamically. The unified CPE may log this mapping when it receives it, but it is more likely that any such logging is performed by service provider infrastructure. This document therefore does not recognize any specific requirements for logging of sessions, address bindings, or port assignments at the unified CPE.

The unified CPE does experience one event unique to its operation. The border router, for either Lightweight 4over6 or MAP-E, is required to monitor port usage by outgoing IPv4 packets. If the ports used by a host fall outside its configured port set, the border router may return an ICMPv6 type 1, code 5 (source address failed ingress/egress policy) error message to the unified CPE. Receipt of such error messages at the unified CPE indicates inconsistency of configuration between the unified CPE and the border router. It is also possible for the same reason that the unified CPE receives incoming IPv4 packets with destination port numbers outside of its assigned range.

The log reporting this event should capture the port set configured on the unified CPE. For both Lightweight 4over6 and MAP-E, this is associated with an identifier, the port set identifier (PSID). In the case of Lightweight 4over6, the actual set of port numbers can be calculated from the combination of the PSID value and the size of the single contiguous range of ports assigned to the CPE. In the case of MAP-E, the default assignment consists of a series of equally sized and equally spaced ranges, so the calculation needs the range spacing as well as the range size. Normally, just logging the PSID should be sufficient for debugging misconfigurations.

2.2. Architectural Context

The architectural context within which logging is deployed is an important factor in the rate at which logs need to be recorded. The required logging rate in turn determines whether SYSLOG is a practical solution. See the discussion of feasible logging rates in Section 4.

The three basic contexts we can consider are logging at provisioning time, logging of NAT bindings or sessions triggered by new packet flows at the customer edge, and logging of NAT sessions at a carrier grade NAT (CGN).

Logging at provisioning time is applicable when resources such as address bindings and port blocks are allocated at provisioning time and not as new packet flows are detected. This is true of several of the transition methods discussed in Section 2.1. As mentioned in that section, the basic data from which logs are generated can be captured by DHCP servers or by AAA. The details are out of scope for this document.

The Port Control Protocol (PCP) [RFC6887] and its port set extension [I-D.pcp-port-set] can be viewed as a way to provision by other means. However, PCP can be invoked on a per-flow basis, so the volume of logs generated by PCP can be closer to the volume that has to be recorded in the other architectural contexts mentioned above and discussed below. The volume really depends on how PCP is being used in a specific network.

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.

The volume of new flows per second processed by a carrier grade NAT can rise into the millions. This has a major impact on the applicability of SYSLOG to logging of CGN sessions.

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. Since the present document deals with SYSLOG rather than IPFIX, 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.

The listed parameters include an optional NAT identifier and an optional NAT type in each case. The NAT identifier is potentially useful only if the HOSTNAME field in the log header identifies an off-board device rather than the NAT itself. The NAT type identifies which of the NAT types listed in Table 1 is reporting the event.

Reference will be made below to a subscriber-identifying address parameter. For traditional NATs, the source IPv4 address (for NAT44) or IPv6 address (for NAT64) is sufficient. For the transition methods discussed in Section 2.1, which are all based on IPv4-in-IPv6 tunnels, the subscriber site is identified by the IPv6 tunnel endpoint address provisioned to that site. In the case of DS-Lite, as mentioned already, the source IPv4 address is not meaningful, and in the case of Lightweight 4over6 and MAP-E the IPv4 address may be shared. Table 1 summarizes this information for concise reference below.