Internet Engineering Task Force Z. Chen Internet-Draft China Telecom Intended status: Standards Track C. Zhou Expires: November 09, 2013 Huawei Technologies T. Tsou Huawei Technologies (USA) T. Taylor Huawei Technologies May 08, 2013 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. Chen, et al. Expires November 09, 2013 [Page 1] Internet-Draft Syslog Format for NAT Logging May 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 2.1. NAT Logging Requirements For Different Transition Methods 4 2.2. Architectural Context . . . . . . . . . . . . . . . . . . 6 3. NAT-Related Events and Parameters . . . . . . . . . . . . . . 7 3.1. NAT Session Creation and Deletion . . . . . . . . . . . . 8 3.2. Binding Information Base (BIB) Entry Creation and Deletion . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Address Binding Event . . . . . . . . . . . . . . . . . . 10 3.4. Port Block Allocation and Deallocation . . . . . . . . . 10 3.5. NAT Address Exhaustion Event . . . . . . . . . . . . . . 11 3.6. Port Exhaustion Event . . . . . . . . . . . . . . . . . . 11 3.7. Quota Exceeded Event . . . . . . . . . . . . . . . . . . 11 3.8. Invalid Port Detected . . . . . . . . . . . . . . . . . . 12 4. SYSLOG Applicability . . . . . . . . . . . . . . . . . . . . 13 5. SYSLOG Record Format For NAT Logging . . . . . . . . . . . . 13 5.1. SYSLOG HEADER Fields . . . . . . . . . . . . . . . . . . 14 5.2. Parameter Encodings . . . . . . . . . . . . . . . . . . . 15 5.2.1. NTyp: NAT Type . . . . . . . . . . . . . . . . . . . 16 5.2.2. NID: NAT Identifier . . . . . . . . . . . . . . . . . 16 5.2.3. VLANid: VLAN Identifier . . . . . . . . . . . . . . . 17 5.2.4. VRFid: VPN Routing and Forwarding Identifier . . . . 17 5.2.5. PreS4: Pre-NAT IPv4 Source Address . . . . . . . . . 17 5.2.6. PreS6: Pre-NAT IPv6 Source Address . . . . . . . . . 17 5.2.7. Enc6: Encapsulating IPv6 Source Address . . . . . . . 17 5.2.8. PostS4: Post-NAT Source IPv4 Address . . . . . . . . 17 5.2.9. Proto: Protocol Identifier . . . . . . . . . . . . . 17 5.2.10. PreSPt: Pre-NAT Source Port or ICMP Identifier . . 17 5.2.11. PostSPt: Post-NAT Source Port or ICMP Identifier . 17 5.2.12. PreD4: Pre-NAT Destination IPv4 Address . . . . . . . 18 Chen, et al. Expires November 09, 2013 [Page 2] Internet-Draft Syslog Format for NAT Logging May 2013 5.2.13. PreD6: Pre-NAT Destination IPv6 Address . . . . . . . 18 5.2.14. PostD4: Post-NAT Destination IPv4 Address . . . . . . 18 5.2.15. PostDPt: Post-NAPT Destination Port or ICMP Identifier . . . . . . . . . . . . . . . . . . . . . 18 5.2.16. TrigR: Realm Triggering Session Creation . . . . . . 18 5.2.17. PtMin: Starting Port Number . . . . . . . . . . . . . 18 5.2.18. PtMax: Ending Port Number . . . . . . . . . . . . . . 18 5.2.19. PtRgSz: Port Range Size . . . . . . . . . . . . . . . 18 5.2.20. PtRgStp: Step Size Between Port Ranges . . . . . . . 18 5.2.21. APoolId: Address Pool Identifier . . . . . . . . . . 18 5.2.22. QTyp: Quota Limit Type . . . . . . . . . . . . . . . 19 5.2.23. PSID: Port Set Identifier . . . . . . . . . . . . . . 19 5.3. Encoding Of Complete Log Report For Each Event Type . . . 19 5.3.1. NAT Session Creation and Deletion . . . . . . . . . . 19 5.3.1.1. Examples . . . . . . . . . . . . . . . . . . . . 20 5.3.2. Binding Information Base (BIB) Entry Creation or Deletion . . . . . . . . . . . . . . . . . . . . . . 21 5.3.3. Address Binding Event . . . . . . . . . . . . . . . . 22 5.3.4. Port Block Allocation and Deallocation . . . . . . . 22 5.3.5. Address Exhaustion Event . . . . . . . . . . . . . . 23 5.3.6. NAT Port Exhaustion . . . . . . . . . . . . . . . . . 24 5.3.7. Quota Exceeded . . . . . . . . . . . . . . . . . . . 24 5.3.8. Invalid Port Detected . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 Chen, et al. Expires November 09, 2013 [Page 3] Internet-Draft Syslog Format for NAT Logging May 2013 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 Chen, et al. Expires November 09, 2013 [Page 4] Internet-Draft Syslog Format for NAT Logging May 2013 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. Chen, et al. Expires November 09, 2013 [Page 5] Internet-Draft Syslog Format for NAT Logging May 2013 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 Chen, et al. Expires November 09, 2013 [Page 6] Internet-Draft Syslog Format for NAT Logging May 2013 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. +---------------------+--------------------------------------+ | NAT Type | Subscriber-Identifying Address | Chen, et al. Expires November 09, 2013 [Page 7] Internet-Draft Syslog Format for NAT Logging May 2013 +---------------------+--------------------------------------+ | Traditional NAT44 | Pre-NAT IPv4 source address | | ---- | ---- | | Traditional NAT64 | Pre-NAT IPv6 source address | | ---- | ---- | | DS-Lite AFTR (Note) | Encapsulating IPv6 source address | | ---- | ---- | | Unified CPE | Encapsulating IPv6 source address | +---------------------+--------------------------------------+ Note: for Gateway-Initiated DS-Lite [RFC6674], the encapsulating protocol may not be IPv6. In that case the subscriber-identifying address consists of the combination of the softwire identifier (SWID) and the context identifier (CID). See [RFC6674]. Table 1: Subscriber-Identifying Address, By NAT Type 3.1. NAT Session Creation and Deletion NAT session creation and deletion events are recorded when a binding to a specific destination address and port is recorded in or deleted from the session database. See the discussion in Section 3 of [RFC6146]. The following specific events are defined: o NAT Session Creation o NAT Session Deletion These take the same parameters for all types of NAT, aside from the variation in subscriber-identifying address noted above: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o VLAN identifier or VPN Routing and Forwarding (VRF) identifier (OPTIONAL); o Subscriber-identifying address (see Table 1) (MANDATORY); o Post-NAT source IPv4 address (MANDATORY); o Protocol identifier (MANDATORY); o Source port or ICMP identifier (MANDATORY); o Post-NAPT source port or ICMP identifier (MANDATORY); Chen, et al. Expires November 09, 2013 [Page 8] Internet-Draft Syslog Format for NAT Logging May 2013 o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address (OPTIONAL); o Post-NAT destination IPv4 address (OPTIONAL); o Post-NAPT destination port or ICMP identifier (OPTIONAL); o Address realm (internal or external) of the source of the packet triggering the creation of the session (OPTIONAL). Note that [RFC6888] recommends against destination logging because of the privacy issues it creates. The pre-NAT value of destination address will differ from the post-NAT value only in a double-NAT situation. Hence in most cases even with destination logging the pre-NAT value will not be recorded. 3.2. Binding Information Base (BIB) Entry Creation and Deletion By definition, a BIB entry refers to a destination-independent mapping between a source transport address and a post-NAT source transport address. The parameters for the BIB entry creation and deletion events reflect this difference from NAT session creation and deletion. Moreover, BIB entry creation is always triggered by a packet from an internal source. The BIB events are: o NAT BIB entry Creation o NAT BIB entry Deletion These events have the following parameters: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o VLAN identifier or VPN Routing and Forwarding (VRF) identifier (OPTIONAL); o Subscriber-identifying address (see Table 1) (MANDATORY); o Post-NAT source IPv4 address (MANDATORY); o Protocol identifier (MANDATORY); o Source port or ICMP identifier (MANDATORY); o Post-NAPT source port or ICMP identifier (MANDATORY); Chen, et al. Expires November 09, 2013 [Page 9] Internet-Draft Syslog Format for NAT Logging May 2013 3.3. Address Binding Event This event reports when a given source address has been bound to an external source address. An address binding occurs when the first packet in the first flow from the host in the internal realm is received at the NAT. It MAY occur under other circumstances (e.g., PCP request, or NAT policy permits assignment of a new external address due to port conflict). The event parameters are: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o Subscriber-identifying address (see Table 1) (MANDATORY); o Post-NAT source IPv4 address (MANDATORY); 3.4. Port Block Allocation and Deallocation This event is reported when a block of ports/ICMP identifiers is allocated or deallocated to a given address binding, rather than allocating individual ports as individual flows are recognized. The same allocation applies to each protocol supported by the NAT. The parameters for this event are: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o Subscriber-identifying address (see Table 1) (MANDATORY); o Post-NAT source IPv4 address (MANDATORY); o Starting port number (OPTIONAL); o Ending port number (OPTIONAL); o Port range size (OPTIONAL); o Range step size (OPTIONAL). Flexibility is provided to report a single range of ports (using starting port number and ending port number) or a series of equally spaced ranges (using starting port number, port range size, range step size, and optionally the ending port number). Where a series of ranges is being allocated, the interpretation of the parameters is as follows: Chen, et al. Expires November 09, 2013 [Page 10] Internet-Draft Syslog Format for NAT Logging May 2013 o starting port number is the first (lowest) port number in the first range; o port range size is the number of ports in each allocated range, with a minimum value of 1; o Range step size is the number of port numbers between corresponding values in subsequent ranges. Hence the starting port for a given range is some multiple of range step size plus the value of the starting port number parameter. o Ending port number is the highest port value allocated (i.e., the final port number in the final range). This is needed only if that value is less than the last value defined by the other parameters that would not exceed 65535. 3.5. NAT Address Exhaustion Event This event will be generated when a NAT device runs out of global IPv4 addresses in a given pool of addresses. Typically, this event would mean that the NAT device will not be able to create any new translations until some addresses or ports are freed. This event takes the following parameters: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o address pool identifier (MANDATORY). 3.6. Port Exhaustion Event This event will be generated when a NAT device runs out of ports for a global IPv4 address. Port exhaustion shall be reported per protocol (UDP, TCP, etc.). The event parameters are: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o Post-NAT source IPv4 address (MANDATORY); o Protocol identifier (MANDATORY). 3.7. Quota Exceeded Event Chen, et al. Expires November 09, 2013 [Page 11] Internet-Draft Syslog Format for NAT Logging May 2013 This event is reported when the NAT cannot allocate a new session or BIB entry because of an administratively imposed limit. The parameters of this event are: o NAT type (OPTIONAL); o NAT identifier (OPTIONAL); o quota limit type (MANDATORY); o VLAN identifier or VPN Routing and Forwarding (VRF) identifier (OPTIONAL); o Subscriber-identifying address (see Table 1) (OPTIONAL); o Protocol identifier (OPTIONAL). The possible limit types are on the number of sessions, number of BIB entries, and global number of NAT entries. These limits may apply to an individual protocol, in which case the protocol identifier MUST be present. The limits may apply to an user, in which case a subscriber-identifying address MUST be present. Alternatively, the limits apply to a domain identified by a VLAN or VRF identifier which MUST then be present. 3.8. Invalid Port Detected As discussed in Section 2.1, this event may be reported at a unified CPE, either through receipt of ICMP error messages or by direct observation of incoming IPv4 packets. It takes the following parameters: o NAT identifier (OPTIONAL); o Subscriber-identifying address. For the unified CPE, this is always the encapsulating IPv6 address. (MANDATORY); o port set identifier provisioned to the unified CPE (MANDATORY); o port range size (OPTIONAL); o range step size (OPTIONAL). Port range size is always applicable but, as shown above, is optional to record. Range step size is not applicable for Lightweight 4over6, which allocates a single contiguous range of ports to the CPE. Chen, et al. Expires November 09, 2013 [Page 12] Internet-Draft Syslog Format for NAT Logging May 2013 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 severity 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 examples in Section 5.3, typical record sizes for the high-volume logs are in the order of 150 to 200 bytes, so throughput capacity should be higher than in the call detail case for the same amount of computing power. 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, Chen, et al. Expires November 09, 2013 [Page 13] Internet-Draft Syslog Format for NAT Logging May 2013 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 default value of 8x is suggested, representing a Facility value of 10 (security/ authorization) and a Severity level varying with the event type. The suggested value by event type is shown in Table 2. Depending on where the SYSLOG record is generated, the HOSTNAME field may identify the NAT or an offline logging device. In the latter case, it may be desirable to identify the NAT using the NID field in the STRUCTURED- DATA section (see below). 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. The APP-NAME value "NAT" indicates that the record relates to an event reported by a NAT device. The MSGID values indicate the individual events. They are listed in Table 2 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. +-------------------------+----------+-------------+-----------+ | Event | MSGID | PRI | SD-ID | +-------------------------+----------+-------------+-----------+ | NAT session creation | SessAdd | 86 info | NATsess | | NAT session deletion | SessDel | 86 info | NATsess | | NAT BIB entry creation | BIBAdd | 86 info | NATBIB | | NAT BIB entry deletion | BIBDel | 86 info | NATBIB | | Address binding event | AddrBind | 86 info | NATBind | | Port block allocation | PBlkAdd | 86 info | NATPBlk | | Port block deallocation | PBlkDel | 86 info | NATPBlk | | NAT address exhaustion | AddrEx | 82 critical | NATAddrEx | | NAT port exhaustion | PortEx | 84 warning | NATPEx | | Quota exceeded | Quota | 85 notice | NATQEx | | Invalid port detected | InvPort | 83 error | NATInvP | +-------------------------+----------+-------------+-----------+ Table 2: Recommended MSGID Encodings and Default PRI Values for the Events Defined In Section 3 Chen, et al. Expires November 09, 2013 [Page 14] Internet-Draft Syslog Format for NAT Logging May 2013 5.2. Parameter Encodings This section describes how to encode the individual parameters that can appear in NAT-related logs. These parameters are taken from the event descriptions in Section 3. Formally, as will be seen in Table 12, a parameter used with more than one event is registered as multiple separate parameters, one for each event report in which it is used. However, there is no reason to change either the PARAM-NAME or the encoding of the PARAM-VALUE between different instances of the same parameter. For all of the parameters described below that convey IPv4 or IPv6 addresses, it is RECOMMENDED that implementations allow the operator to configure the portion of the address that will be recorded. Particularly for IPv6, this may involve omission of a specified number of trailing as well as leading octets of the address. *** Open issue *** The parameter "subscriber-identifying address" has multiple possible types, as shown in Table 1. One could encode this as two parameters, a type and a value which is a string restricted to decimal (for IPv4) or hexadecimal digits. That way the parameter could be shown as MANDATORY in the IANA registration. This version opts for compactness, using a different PARAM-NAME for each type, with the consequence that the individual parameters will be shown as OPTIONAL in the IANA registry but normative text in the next section will mandate the appearance of the appropriate one depending on the NAT type. *** Open issue *** Should we provide for GW-initiated DS-Lite? The parameter specifications provided in this section are summarized in Table 3. This table also shows the PARAM-NAME value for each parameter. +------------+------------------------------------------------------+ | PARAM-NAME | Parameter | +------------+------------------------------------------------------+ | NTyp | NAT type | | NID | NAT identifier | | VLANid | VLAN identifier | | VRFid | VPN routing and forwarding identifier | | PreS4 | Pre-NAT IPv4 source address | | PreS6 | Pre-NAT IPv6 source address | | Enc6 | Encapsulating IPv6 source address | | PostS4 | Post-NAT source IPv4 address | | Proto | Protocol identifier | | PreSPt | Source port or ICMP identifier | | PostSPt | Post-NAPT source port or ICMP identifier | Chen, et al. Expires November 09, 2013 [Page 15] Internet-Draft Syslog Format for NAT Logging May 2013 | PreD4 | Destination IPv4 address | | PreD6 | Destination IPv6 address | | PostD4 | Post-NAT destination IPv4 address | | PostDPt | Post-NAPT destination port or ICMP identifier | | TrigR | Address realm triggering the creation of the session | | PtMin | Starting port number | | PtMax | Ending port number | | PtRgSz | Port range size | | PtRgStp | Range step size | | APoolId | Address pool identifier | | QTyp | Quota limit type | | PSID | Port set identifier | +------------+------------------------------------------------------+ Table 3: Parameters Used In NAT-Related Log Reports, By PARAM-NAME 5.2.1. NTyp: NAT Type PARAM-VALUE: one of the values provided in the IANA SYSLOG NAT type registry established by this document. The initial values in that registry are: 44 NAT44; 64 NAT64; AFTR DS-Lite AFTR [RFC6333]; UCPE unified CPE [I-D.softwire-unified-cpe]. This parameter is primarily additional information for the human reader of a log report, but could be used to provide a consistency check on the contents of a log. Instances where parameter usage depends on the NAT type of the reporting NAT are noted in Section 5.3. 5.2.2. NID: NAT Identifier PARAM-VALUE: a UTF-8 string identifying the NAT observing the event which this record reports. Needed only if the necessary identification is not provided by the HOSTNAME parameter in the log record header. Chen, et al. Expires November 09, 2013 [Page 16] Internet-Draft Syslog Format for NAT Logging May 2013 5.2.3. VLANid: VLAN Identifier PARAM-VALUE: a decimal integer representing the VLAN identifier associated with the subscriber site. 5.2.4. VRFid: VPN Routing and Forwarding Identifier PARAM-VALUE: a hexadecimal number representing a VPN identifier [RFC2685] associated with the subscriber site. It is RECOMMENDED that implementations be configurable to include or not include the OUI portion of the identifier. 5.2.5. PreS4: Pre-NAT IPv4 Source Address PARAM-VALUE: part or all of an IPv4 address, represented in dotted decimal form. 5.2.6. PreS6: Pre-NAT IPv6 Source Address PARAM-VALUE: Part or all of an IPv6 address, represented in the form specified by [RFC5952]. 5.2.7. Enc6: Encapsulating IPv6 Source Address PARAM-VALUE: Part or all of an IPv6 address, represented in the form specified by [RFC5952]. 5.2.8. PostS4: Post-NAT Source IPv4 Address PARAM-VALUE: part or all of an IPv4 address, represented in dotted decimal form. 5.2.9. Proto: Protocol Identifier PARAM-VALUE: an integer indicating the value of the Protocol header field (IPv4) or Next Header field (IPv6) in the incoming packet(s) (after decapsulation, for NAT type "AFTR") to which the event described by this record applies. 5.2.10. PreSPt: Pre-NAT Source Port or ICMP Identifier PARAM-Value: integer value of the source port number or ICMP identifier before NAT processing. 5.2.11. PostSPt: Post-NAT Source Port or ICMP Identifier PARAM-Value: integer value of the source port number or ICMP identifier after NAT processing. Chen, et al. Expires November 09, 2013 [Page 17] Internet-Draft Syslog Format for NAT Logging May 2013 5.2.12. PreD4: Pre-NAT Destination IPv4 Address PARAM-VALUE: part or all of an IPv4 address, represented in dotted decimal form. 5.2.13. PreD6: Pre-NAT Destination IPv6 Address PARAM-VALUE: Part or all of an IPv6 address, represented in the form specified by [RFC5952]. 5.2.14. PostD4: Post-NAT Destination IPv4 Address PARAM-VALUE: part or all of an IPv4 address, represented in dotted decimal form. 5.2.15. PostDPt: Post-NAPT Destination Port or ICMP Identifier PARAM-Value: integer value of the destination port number or ICMP identifier after NAT processing. 5.2.16. TrigR: Realm Triggering Session Creation PARAM-VALUE: "I" for internal, "E" for external. 5.2.17. PtMin: Starting Port Number PARAM-Value: integer between 0 and 65535. 5.2.18. PtMax: Ending Port Number PARAM-Value: integer between 0 and 65535. MUST be greater than or equal to PtMin if both are present. 5.2.19. PtRgSz: Port Range Size PARAM-Value: integer between 1 and 65535. PtMin MUST also be present. PtRgSz SHOULD be less than or equal to (PtMax - PtMin + 1) if both other parameters are present, otherwise it SHOULD be less than or equal to (65535 - PtMin + 1). 5.2.20. PtRgStp: Step Size Between Port Ranges PARAM-Value: integer between 1 and 65535. MUST be greater than or equal to PtRgSz if both parameters are present. 5.2.21. APoolId: Address Pool Identifier Chen, et al. Expires November 09, 2013 [Page 18] Internet-Draft Syslog Format for NAT Logging May 2013 PARAM-Value: integer identifying a specific address pool at the reporting NAT. 5.2.22. QTyp: Quota Limit Type Value indicating which type of administrative quota has been exhausted. The possible values are: SESS limit on number of session entries; BIB limit on number of BIB entries; ALL limit on global number of entries. 5.2.23. PSID: Port Set Identifier PARAM-VALUE: integer between 0 and 65535 designating a port set. In practice the upper limit is likely to be two orders of magnitude smaller. 5.3. Encoding Of Complete Log Report For Each Event Type This section describes the complete NAT-related contents of the logs used to report the events listed in Table 2. 5.3.1. NAT Session Creation and Deletion As indicated in Table 2, the NAT session creation event is indicated by MSG-ID set to "SessAdd". Similarly, the NAT session deletion event is indicated by MSG-ID set to "SessDel". For both events, the associated SD-ELEMENT is tagged by SD-ID "NATsess". The contents of the NATsess SD-ELEMENT are shown in Table 4. The requirements for these contents are derived from the description in Section 3.1. +------------+----------------+-------------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | VLANid | Section 5.2.3 | OPTIONAL | | VRFid | Section 5.2.4 | OPTIONAL | | PreS4 | Section 5.2.5 | Note 1 | | PreS6 | Section 5.2.6 | Note 1 | | Enc6 | Section 5.2.7 | Note 1 | | PostS4 | Section 5.2.8 | MANDATORY | | Proto | Section 5.2.9 | MANDATORY | | PreSPt | Section 5.2.10 | MANDATORY | | PostSPt | Section 5.2.11 | MANDATORY | Chen, et al. Expires November 09, 2013 [Page 19] Internet-Draft Syslog Format for NAT Logging May 2013 | PreD4 | Section 5.2.12 | OPTIONAL (Note 2) | | PreD6 | Section 5.2.13 | OPTIONAL (Note 2) | | PostD4 | Section 5.2.14 | OPTIONAL | | PostDPt | Section 5.2.15 | OPTIONAL | | TrigR | Section 5.2.16 | OPTIONAL | +------------+----------------+-------------------+ Table 4: Contents Of the SD-ELEMENT Section For Logging the Session Creation and Deletion Events Note 1: one of PreD4, PreD6, or Enc6 MUST be present. For NAT type "44", use PreD4. For NAT type "64", use PreD6. For NAT types "AFTR" and "UCPE", use Enc6. Note 2: use PreD4 for NAT types "44", "AFTR", and "UCPE". Use PreD6 for NAT type "64". 5.3.1.1. Examples The first example is deliberately chosen to show how long a complete session log might be. For this first example, assume the log is formatted at an off-board device, which collects the information from an AFTR. Thus HOSTNAME and NID are both present. IPv6 addresses are reported omitting a common /16 prefix and the IID portion of the address (not to be too unrealistic!). Destination logging is enabled and all the other optional parameters are present. The AFTR does not translate the destination address, so PreD4 is not included. Note that the log could also include other SD-ELEMENTs (e.g., timeQuality), but enough is enough. The log appears as a single record, but is wrapped between lines for purposes of presentation. <86>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063 SessAdd [NATsess NTyp="AFTR" NID="bgw211.example.net" VLANid="00201B000471E6" Enc6="A2E0:62" PostS4="198.51.100.127" Proto="6" PreSPt="49156" PostSPt="6083" PostD4="198.51.100.16" PostDPt="80" TrigR="I"] Character count: about 260. The next example is perhaps more typical in size. Assume an enterprise NAT44 generating its own logs. The enterprise does do destination logging as a matter of policy, but the other optional parameters are omitted. This is a session deletion event. <86>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com NAT 175 SessDel [NATsess PreS4="192.0.2.5" PostS4="198.51.100.14" Chen, et al. Expires November 09, 2013 [Page 20] Internet-Draft Syslog Format for NAT Logging May 2013 Proto="6" PreSPt="51387" PostSPt="17865" PostD4="198.51.100.86" PostDPt="80"] The character count: about 200. 5.3.2. Binding Information Base (BIB) Entry Creation or Deletion As indicated in Table 2, the NAT BIB entry creation event is indicated by MSG-ID set to "BIBAdd". Similarly, the NAT BIB entry deletion event is indicated by MSG-ID set to "BIBDel". For both events, the associated SD-ELEMENT is tagged by SD-ID "NATBIB". The contents of the NATBIB SD-ELEMENT are shown in Table 5. The requirements for these contents are derived from the description in Section 3.2. +------------+----------------+-------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | VLANid | Section 5.2.3 | OPTIONAL | | VRFid | Section 5.2.4 | OPTIONAL | | PreS4 | Section 5.2.5 | Note 1 | | PreS6 | Section 5.2.6 | Note 1 | | Enc6 | Section 5.2.7 | Note 1 | | PostS4 | Section 5.2.8 | MANDATORY | | Proto | Section 5.2.9 | MANDATORY | | PreSPt | Section 5.2.10 | MANDATORY | | PostSPt | Section 5.2.11 | MANDATORY | +------------+----------------+-------------+ Table 5: Contents Of the SD-ELEMENT Section For Logging BIB Entry Creation and Deletion Events Note 1: one of PreD4, PreD6, or Enc6 MUST be present. For NAT type "44", use PreD4. For NAT type "64", use PreD6. For NAT types "AFTR" and "UCPE", use Enc6. As an example, consider a NAT64 where, as in the first session example above, the first /16 prefix and the final 64 bits are omitted from the IPv6 address. <86>1 2013-05-07T15:27:49.603-04:00 orpheus.example.com NAT 683 BIBAdd [NATBIB PreS6="F73E:7008" PostS4="198.51.100.1" Proto="6" PreSPt="27386" PostSPt="4809"] Character count: about 160. Chen, et al. Expires November 09, 2013 [Page 21] Internet-Draft Syslog Format for NAT Logging May 2013 5.3.3. Address Binding Event As indicated in Table 2, the NAT address binding event is indicated by MSG-ID set to "AddrBind". The associated SD-ELEMENT is tagged by SD-ID "NATBind". The contents of the NATBind SD-ELEMENT are shown in Table 6. The requirements for these contents are derived from the description in Section 3.3. +------------+----------------+-------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | PreS4 | Section 5.2.5 | Note 1 | | PreS6 | Section 5.2.6 | Note 1 | | Enc6 | Section 5.2.7 | Note 1 | | PostS4 | Section 5.2.8 | MANDATORY | +------------+----------------+-------------+ Table 6: Contents Of the SD-ELEMENT Section For Logging the Address Binding Event Note 1: one of PreD4, PreD6, or Enc6 MUST be present. For NAT type "44", use PreD4. For NAT type "64", use PreD6. For NAT types "AFTR" and "UCPE", use Enc6. As an example, consider a managed DS-Lite B4 [RFC6333] operating as a NAT44 in coordination with the AFTR using PCP to obtain an external address binding and a port range. See Section 11 of [RFC6887] for the address binding. (The port allocation is shown in the next section's example.) The example here shows the address binding being recorded by the B4, although it could as well be recorded by the AFTR. As usual, the first /16 prefix and the final 64 bits are omitted from the encapsulating IPv6 address. <86>1 2013-05-07T15:27:49.603Z yourd137mzmhow.example.net NAT 68 AddrBind [NATBind Enc6="5A27:876E" PostS4="198.51.100.1"] Character count: about 135. 5.3.4. Port Block Allocation and Deallocation As indicated in Table 2, the port block allocation event is indicated by MSG-ID set to "PBlkAdd". The associated SD-ELEMENT is tagged by SD-ID "NATPBlk". Similarly, the port block deallocation event is indicated by MSG-ID set to "PBlkDel". For both events, the contents of the NATPBlk SD-ELEMENT are shown in Table 7. The requirements for these contents are derived from the description in Section 3.4. Chen, et al. Expires November 09, 2013 [Page 22] Internet-Draft Syslog Format for NAT Logging May 2013 +------------+----------------+-------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | PtMin | Section 5.2.17 | MANDATORY | | PtMax | Section 5.2.18 | OPTIONAL | | PtRgSz | Section 5.2.19 | OPTIONAL | | PtRgStp | Section 5.2.20 | OPTIONAL | +------------+----------------+-------------+ Table 7: Contents Of the SD-ELEMENT Section For Logging the Port Block Allocation or Deallocation Event As in the example in the previous section example, consider a managed DS-Lite B4 [RFC6333] operating as a NAT44 in coordination with the AFTR using PCP to obtain an external address binding and a port range. See [I-D.pcp-port-set] for the port set part of this operation. The example here shows the port set allocation being recorded by the B4, although it could as well be recorded by the AFTR. Strictly for purposes of illustration, assume that the B4 is allocated two ranges of 64 consecutive values each, with the first beginning at 2048 and the second at 4096. Thus the port range step size is 2048 and the last port is 4159. <86>1 2013-05-07T15:27:49.751Z yourd137mzmhow.example.net NAT 68 PBlkAdd [NATPBlk PtMin="2048" PtMax="4159" PtRgSz="64" PtRgStp="2048"] Character count: about 135. 5.3.5. Address Exhaustion Event As indicated in Table 2, the address exhaustion event is indicated by MSG-ID set to "AddrEx". The associated SD-ELEMENT is tagged by SD-ID "NATAddrEx". The contents of the NATAddrEx SD-ELEMENT are shown in Table 8. The requirements for these contents are derived from the description in Section 3.5. +------------+----------------+-------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | APoolId | Section 5.2.21 | MANDATORY | +------------+----------------+-------------+ Chen, et al. Expires November 09, 2013 [Page 23] Internet-Draft Syslog Format for NAT Logging May 2013 Table 8: Contents Of the SD-ELEMENT Section For Logging the Address Exhaustion Event The example shows this event being reported by a DS-Lite AFTR. Note the critical priority indication at the beginning of the log. As with the session example, we assume off-board log generation. <82>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063 AddrEx [NATAddrEx NID="bgw211.example.net" APoolId="2"] Character count: about 120. 5.3.6. NAT Port Exhaustion As indicated in Table 2, the port exhaustion event is indicated by MSG-ID set to "PortEx". The associated SD-ELEMENT is tagged by SD-ID "NATPEx". The contents of the NATPEx SD-ELEMENT are shown in Table 9. The requirements for these contents are derived from the description in Section 3.6. +------------+----------------+-------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | PostS4 | Section 5.2.8 | MANDATORY | | Proto | Section 5.2.9 | MANDATORY | +------------+----------------+-------------+ Table 9: Contents Of the SD-ELEMENT Section For Logging the Port Exhaustion Event The example is straightforward. Note the warning priority indication at the beginning of the log. <84>1 2013-05-07T22:14:15.03Z cerberus.example.com NAT 5063 PortEx [NATPEx PostS4="198.51.100.1" Proto="6"] Character count: about 110. 5.3.7. Quota Exceeded As indicated in Table 2, the quota exceeded event is indicated by MSG-ID set to "Quota". The associated SD-ELEMENT is tagged by SD-ID "NATQEx". The contents of the NATQEx SD-ELEMENT are shown in Table 10. The requirements for these contents are derived from the description in Section 3.7. Chen, et al. Expires November 09, 2013 [Page 24] Internet-Draft Syslog Format for NAT Logging May 2013 +------------+----------------+-------------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------------+ | NTyp | Section 5.2.1 | OPTIONAL | | NID | Section 5.2.2 | OPTIONAL | | QTyp | Section 5.2.22 | MANDATORY | | VLANid | Section 5.2.3 | OPTIONAL | | VRFid | Section 5.2.4 | OPTIONAL | | PreS4 | Section 5.2.5 | OPTIONAL (Note 1) | | PreS6 | Section 5.2.6 | OPTIONAL (Note 1) | | Enc6 | Section 5.2.7 | OPTIONAL (Note 1) | | Proto | Section 5.2.9 | OPTIONAL | +------------+----------------+-------------------+ Table 10: Contents Of the SD-ELEMENT Section For Logging the Quota Exceeded Event Note 1: if the quota applies to a specific user site, one of PreS4, PreS6, or Enc6 MUST be present. Use PreS4 for NAT44, PreS6 for NAT64, and Enc6 for AFTR or UCPE. Example 1: limit on TCP sessions for a specific user site reached at an AFTR with off-board log generation. <85>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063 Quota [NATQEx NID="bgw211.example.net" QTyp="SESS" Enc6="A2E0:62" Proto="6"] Character count: about 130. Example 2: global limit on number of entries for all subscribers served by the same VPN. <85>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com NAT 175 Quota [NATQEx QTyp="ALL" VRFid="1246"] Character count: about 105. Example 3: limit on total number of BIB entries for TCP. <85>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com NAT 175 Quota [NATQEx QTyp="BIB" Proto="6"] Character count: about 95. 5.3.8. Invalid Port Detected Chen, et al. Expires November 09, 2013 [Page 25] Internet-Draft Syslog Format for NAT Logging May 2013 As indicated in Table 2, the invalid port detected event is indicated by MSG-ID set to "InvPort". The associated SD-ELEMENT is tagged by SD-ID "NATInvP". The contents of the NATInvP SD-ELEMENT are shown in Table 11. The requirements for these contents are derived from the description in Section 3.8. +------------+----------------+-------------+ | PARAM-NAME | Description | Requirement | +------------+----------------+-------------+ | NID | Section 5.2.2 | OPTIONAL | | Enc6 | Section 5.2.7 | MANDATORY | | PSID | Section 5.2.23 | MANDATORY | | PtRgSz | Section 5.2.19 | OPTIONAL | | PtRgStp | Section 5.2.20 | OPTIONAL | +------------+----------------+-------------+ Table 11: Contents Of the SD-ELEMENT Section For Logging the Invalid Port detected Event Example: managed unified CPE running Lightweight 4over6 and configured to report the port range size. <83>1 2013-05-07T15:27:49.603Z yourd137mzmhow.example.net NAT 68 InvPort [NATInvP Enc6="5A27:876E" PSID="15" PtRgSz="512"] Character count: about 120. 6. IANA Considerations This document requests IANA to make the following assignments to the SYSLOG Structured Data ID Values registry. RFCxxxx refers to the present document when approved. +----------------+------------------+-----------------+-------------+ | Structured | Structured Data | Required or | Reference | | Data ID | Parameter | Optional | | +----------------+------------------+-----------------+-------------+ | NATsess | | OPTIONAL | RFCxxxx | | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | VLANid | OPTIONAL | RFCxxxx | | | VRFid | OPTIONAL | RFCxxxx | | | PreS4 | OPTIONAL | RFCxxxx | | | PreS6 | OPTIONAL | RFCxxxx | | | Enc6 | OPTIONAL | RFCxxxx | | | PostS4 | MANDATORY | RFCxxxx | | | Proto | MANDATORY | RFCxxxx | | | PreSPt | MANDATORY | RFCxxxx | Chen, et al. Expires November 09, 2013 [Page 26] Internet-Draft Syslog Format for NAT Logging May 2013 | | PostPt | MANDATORY | RFCxxxx | | | PreD4 | OPTIONAL | RFCxxxx | | | PreD6 | OPTIONAL | RFCxxxx | | | PostD4 | OPTIONAL | RFCxxxx | | | PostDPt | OPTIONAL | RFCxxxx | | | TrigR | OPTIONAL | RFCxxxx | | ---- | ---- | ---- | ---- | | NATBIB | | OPTIONAL | RFCxxxx | | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | VLANid | OPTIONAL | RFCxxxx | | | VRFid | OPTIONAL | RFCxxxx | | | PreS4 | OPTIONAL | RFCxxxx | | | PreS6 | OPTIONAL | RFCxxxx | | | Enc6 | OPTIONAL | RFCxxxx | | | PostS4 | MANDATORY | RFCxxxx | | | Proto | MANDATORY | RFCxxxx | | | PreSPt | MANDATORY | RFCxxxx | | | PostPt | MANDATORY | RFCxxxx | | ---- | ---- | ---- | ---- | | NATBind | | OPTIONAL | RFCxxxx | | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | PreS4 | OPTIONAL | RFCxxxx | | | PreS6 | OPTIONAL | RFCxxxx | | | Enc6 | OPTIONAL | RFCxxxx | | | PostS4 | MANDATORY | RFCxxxx | | ---- | ---- | ---- | ---- | | NATPBlk | | OPTIONAL | RFCxxxx | | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | PtMin | MANDATORY | RFCxxxx | | | PtMax | OPTIONAL | RFCxxxx | | | PtRgSz | OPTIONAL | RFCxxxx | | | PtRgStp | OPTIONAL | RFCxxxx | | ---- | ---- | ---- | ---- | | NATAddrEx | | OPTIONAL | RFCxxxx | | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | APoolId | MANDATORY | RFCxxxx | | ---- | ---- | ---- | ---- | | NATPEx | | OPTIONAL | RFCxxxx | | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | PostS4 | MANDATORY | RFCxxxx | | | Proto | MANDATORY | RFCxxxx | | ---- | ---- | ---- | ---- | | NATQEx | | OPTIONAL | RFCxxxx | Chen, et al. Expires November 09, 2013 [Page 27] Internet-Draft Syslog Format for NAT Logging May 2013 | | NTyp | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | QTyp | MANDATORY | RFCxxxx | | | VLANid | OPTIONAL | RFCxxxx | | | VRFid | OPTIONAL | RFCxxxx | | | PreS4 | OPTIONAL | RFCxxxx | | | PreS6 | OPTIONAL | RFCxxxx | | | Enc6 | OPTIONAL | RFCxxxx | | | Proto | OPTIONAL | RFCxxxx | | ---- | ---- | ---- | ---- | | NATInvP | | OPTIONAL | RFCxxxx | | | NID | OPTIONAL | RFCxxxx | | | Enc6 | MANDATORY | RFCxxxx | | | PSID | MANDATORY | RFCxxxx | | | PtRgSz | OPTIONAL | RFCxxxx | | | PtRgStp | OPTIONAL | RFCxxxx | +----------------+------------------+-----------------+-------------+ Table 12: NAT-Related STRUCTERED-DATA Registrations IANA is further requested to establish a new registry entitled "syslog NAT Types" within the "syslog Parameters" registry. The initial values for this registry are shown in Table 13. New values may be added following the criterion of IETF Review. +-------+----------------------------------------+-----------+ | Value | Description | Reference | +-------+----------------------------------------+-----------+ | 44 | NAT44 | RFCxxxx | | 64 | NAT64 | RFCxxxx | | AFTR | DS-Lite AFTR [RFC6333] | RFCxxxx | | UCPE | Unified CPE [I-D.softwire-unified-cpe] | RFCxxxx | +-------+----------------------------------------+-----------+ Table 13: syslog NAT Type Values The reference [I-D.softwire-unified-cpe] is given below in the Informative References section. 7. Security Considerations When logs are being recorded for regulatory reasons, preservation of their integrity and authentication of their origin is essential. To achieve this result, it is RECOMMENDED that the operator deploy [RFC5848]. Access to the logs defined here while the reported assignments are in force could improve an attacker's chance of hijacking a session Chen, et al. Expires November 09, 2013 [Page 28] Internet-Draft Syslog Format for NAT Logging May 2013 through port-guessing. Even after an assignment has expired, the information in the logs SHOULD be treated as confidential, since, if revealed, it could help an attacker trace sessions back to a particular subscriber or subscriber location. It is therefore RECOMMENDED that these logs be transported securely, using [RFC5425], for example, and that they be stored securely at the collector. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009. [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog Messages", RFC 5848, May 2010. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. 8.2. Informative References [I-D.behave-ipfix-nat-logging] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events (Work in progress)", March 2013. [I-D.pcp-port-set] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation (Work in progress)", March 2013. Chen, et al. Expires November 09, 2013 [Page 29] Internet-Draft Syslog Format for NAT Logging May 2013 [I-D.softwire-lw4over6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture (Work in progress)", April 2013. [I-D.softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., and T. Murakami, "Mapping of Address and Port with Encapsulation (MAP) (Work in progress)", March 2013. [I-D.softwire-public-4over6] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public IPv4 over IPv6 Access Network (Work in progress)", February 2013. [I-D.softwire-unified-cpe] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 Softwire CPE (Work in progress)", March 2013. [I-D.tsou-behave-natx4-log-reduction] Tsou, T., Li, W., and T. Taylor, "Port Management To Reduce Logging In Large-Scale NATs (Work in progress)", May 2013. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. Chen, et al. Expires November 09, 2013 [Page 30] Internet-Draft Syslog Format for NAT Logging May 2013 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. Authors' Addresses Zhonghua Chen China Telecom P.R. China Email: 18918588897@189.cn Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathy.zhou@huawei.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tina.tsou.zouting@huawei.com T. Taylor Huawei Technologies Ottawa Canada Email: tom.taylor.stds@gmail.com Chen, et al. Expires November 09, 2013 [Page 31]