| Internet Engineering Task Force | Z. Chen |
| Internet-Draft | China Telecom |
| Intended status: Standards Track | C. Zhou |
| Expires: January 15, 2014 | Huawei Technologies |
| T. Tsou | |
| Huawei Technologies (USA) | |
| T. Taylor | |
| Huawei Technologies | |
| July 14, 2013 |
Syslog Format for NAT Logging
draft-ietf-behave-syslog-nat-logging-02
With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for various operational purposes. The logs may be required for troubleshooting, to identify a host that was used to launch malicious attacks, and/or 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.
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 January 15, 2014.
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.
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, 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.
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.
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].
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).
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. As discussed below, static assignments are typically associated with IPv6 transition methods rather than traditional NAT. The details of what to log will depend on the transition method concerned.
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 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>.
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 an alternative 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], an identifier associated with the incoming tunnel from the host is used instead.
The DS-Lite customer edge equipment (the 'B4') may also perform NAT44 functions, similar to the functions performed by traditional NAT44 devices. This document does not include any requirements specific to the B4, since logs are not usually collected from customer equipment.
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 equipment (unified CPE, [I-D.softwire-unified-cpe]). 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.
The border router (BR), 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. 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.
Out-of-range ports are a sign of misconfiguration or other problems, so it is reasonable for the BR to log such events (subject to the rate limiting). The log should capture the port set that the BR believes is configured on the unified CPE. For both Lightweight 4over6 and MAP-E, this is associated with an identifier, the 16-bit port set identifier (PSID).
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.
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 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 reporting device identifier and an optional reporting device type in each case. The reporting device identifier is potentially useful only if the HOSTNAME field in the log header identifies an off-board device rather than the NAT itself. The reporting device type identifies which of the reporting device types listed in Section 5.2.3 is reporting the event.
Reference will be made below to a subscriber site identifier. IOn practice, NATs use various means to distinguish customer endpoints, and this will be reflected in what they log. From a strictly theoretical point of view:
NAT session creation and deletion events may be logged in a fully dynamic NAT when a binding from a subscriber site identifier and source port to an external address and port is recorded in or deleted from the session database. See Section 3 of [RFC3022] for more details about session creation and deletion.
The following specific events are defined:
These take the same parameters for all types of NAT, aside from the variation in subscriber site identifier noted above:
The logging of destination address and port for outgoing packets is considered out of scope of this document, 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 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 short, destination logging will be a rarely-used procedure for which standardization seems unnecessary.
This event is recorded at a dynamic or hybrid NAT when a given subscriber site identifier 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:
This event is recorded at a hybrid NAT whenever the set of ports allocated to a given address binding changes. When ports are allocated, the same ports are allocated for UDP and for TCP. The parameters for this event are:
The log MUST indicate the cumulative set of ports allocated to the address binding (taking account both of allocations and deallocations) at the time the log was generated. An implementation MAY show each individual allocation as a separate range, or MAY consolidate adjacent ranges. For example, suppose the address binding is initially allocated the range 1024-1535. The log at the time of the initial allocation will contain that one range. Suppose now that an additional allocation is granted, consisting of the range 1536-2047. The log generated may contain the two ranges 1024-1535 and 1536-2047, or may contain the one consolidated range 1024-2047. Finally, suppose that ports 1536-1791 are deallocated. The resulting log will show the ranges 1024-1535 and 1792-2047 as the current allocation to the address binding.
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:
Implementations MUST provide the ability to limit the rate at which this log is generated, since the NAT may move back and forth between exhausted and almost-exhausted state many times during a particular busy episode.
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) individually. The event parameters are:
Implementations MUST provide the ability to limit the rate at which this log is generated, since the NAT may move back and forth between exhausted and almost-exhausted state many times during a particular busy episode.
A "Quota Exceeded" event is reported when the NAT cannot allocate a new session because of an administratively imposed limit on the number of sessions allowed for a given subscriber or set of subscribers, for a given protocol or totalled over all protocols. The parameters of this event are:
Site scope is either single site, multiple sites served by the same VLAN or VRF, or all sites served by the NAT. If the site scope is single site, then the subscriber site identifier MUST be present and the VLAN or VRF identifier MUST be absent. If the site scope is multiple sites, then the reverse MUST be true. If the site scope is all sites, the subscriber site identifier, the VRF idenbtifier, and the VLAN identifier MUST NOT be present. Protocol scope is either a specific protocol (UDP, TCP, ICMP) or all protocols, meaning that the quota concerned applies to the total number of sessions supported by the NAT regardless of protocol.
Implementations MUST provide the ability to limit the rate at which this log is generated, since the NAT may move back and forth between over-quota and within-quota state many times during a particular busy episode.
As discussed in Section 2.2, this event may be reported at MAP-E or Lightweight 4over6 Border Router, either through receipt of ICMP error messages or by direct observation of incoming IPv4 packets.
The event report takes the following parameters:
*** Should we anticipate logging of the configuration (IPv6 prefix, IPv4 prefix/address, PSID) assigned to the Lightweight 4over6 or MAP-E CPE? ***
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.
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.
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 1. 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 DevID 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 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.
| Event | MSGID | PRI | SD-ID |
|---|---|---|---|
| NAT session creation | SessAdd | 86 info | NATsess |
| NAT session deletion | SessDel | 86 info | NATsess |
| Address binding event | AddrBind | 86 info | NATBind |
| Port allocation change | PtAlloc | 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 |
This section describes how to encode the individual parameters that can appear in NAT-related logs. The parameters are taken from the event descriptions in Section 3, and are listed in Table 2. Formally, as will be seen in Table 10, 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.
| PARAM-NAME | Parameter |
|---|---|
| APoolId | Address pool identifier |
| DevID | reporting device identifier |
| DevTyp | reporting device type |
| PostS4 | Mapped external IPv4 address |
| PostSPt | Mapped external port or ICMP identifier |
| PreSPt | Internal port or ICMP identifier |
| Proto | Protocol identifier |
| PScop | Protocol scope for quota |
| PSID | Port set identifier |
| PtRg | Range of consecutive port numbers |
| SiteID | Subscriber site identifier |
| SScop | Site scope for quota |
| TrigR | Address realm triggering the creation of the session |
| VLANid | VLAN identifier |
| VRFid | VPN routing and forwarding identifier |
PARAM-Value: decimal integer identifying a specific address pool at the reporting NAT.
PARAM-VALUE: a UTF-8 string identifying the NAT or BR 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.
PARAM-VALUE: one of the values provided in the IANA SYSLOG reporting device type registry established by this document. The initial values in that registry are:
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 reporting device type of the reporting NAT are noted in Section 5.3.
PARAM-VALUE: IPv4 address, represented in dotted decimal form.
PARAM-Value: decimal integer, port number or ICMP query identifier.
PARAM-Value: decimal integer, port number or ICMP query 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 reporting device type "AFTR") to which the event described by this record applies.
PARAM-VALUE: as for Proto for a specific protocol. "*" for sum over all protocols.
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.
PARAM-VALUE: a field consisting of two decimal integers separated by a minus sign/hyphen. The first integer is the lowest port number, the second, the highest port number, in a range of consecutive ports.
A human-readable UTF-8 string identifying a specific host or CPE served by the reporting device. The type of identifier depends on the configuration of the reporting device, and is implementation and deployment-specific. See Section 3 for a discussion of the possible identifier types.
PARAM-VALUE: "S" for single site, "M" for sum over multiple sites, served by the same VLAN or VRF. "*" for sum over all sites served by the NAT.
PARAM-VALUE: "I" for internal, "E" for external.
PARAM-VALUE: a decimal integer representing the VLAN identifier associated with the subscriber site.
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.
This section describes the complete NAT-related contents of the logs used to report the events listed in Table 1.
As shown in Table 1, 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 3. The requirements for these contents are derived from the description in Section 3.1.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevTyp | Section 5.2.3 | OPTIONAL |
| DevID | Section 5.2.2 | OPTIONAL |
| SiteID | Section 5.2.11 | MANDATORY |
| PostS4 | Section 5.2.4 | MANDATORY |
| Proto | Section 5.2.7 | MANDATORY |
| PreSPt | Section 5.2.6 | MANDATORY |
| PostSPt | Section 5.2.5 | MANDATORY |
| TrigR | Section 5.2.13 | OPTIONAL |
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 DevID are both present. IPv6 addresses are reported omitting a common /16 prefix and the IID portion of the address (not to be too unrealistic!). All the optional parameters are present. 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.
Character count: about 205.
The next example is perhaps more typical in size. Assume an enterprise NAT44 generating its own logs. The optional parameters are omitted. This is a session deletion event.
The character count: about 165.
As shown in Table 1, 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 4. The requirements for these contents are derived from the description in Section 3.2.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevTyp | Section 5.2.3 | OPTIONAL |
| DevID | Section 5.2.2 | OPTIONAL |
| SiteID | Section 5.2.11 | MANDATORY |
| PostS4 | Section 5.2.4 | MANDATORY |
As an example, consider a DS-Lite AFTR [RFC6333] incorporating a PCP server, where PCP is used 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.) As in the session creation example, the first /16 prefix and the final 64 bits are omitted from the encapsulating IPv6 address which is used as the subscriber site identifier.
Character count: about 125.
As indicated in Table 1, the port block allocation change event is indicated by MSG-ID set to "PtAlloc". The associated SD-ELEMENT is tagged by SD-ID "NATPBlk". The contents of the NATPBlk SD-ELEMENT are shown in Table 5. The requirements for these contents are derived from the description in Section 3.3.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevTyp | Section 5.2.3 | OPTIONAL |
| DevID | Section 5.2.2 | OPTIONAL |
| SiteID | Section 5.2.11 | MANDATORY |
| PostS4 | Section 5.2.4 | MANDATORY |
| PtRg | Section 5.2.10 | MANDATORY |
As in the example in the previous section example, consider a DS- Lite AFTR [RFC6333] incorporating a PCP server, where PCP is used to obtain an external address binding and a port range. See [I-D.pcp-port-set] for the port set part of this operation.
Strictly for purposes of illustration, assume that the subscriber is allocated two ranges of 64 consecutive values each, with the first beginning at 2048 and the second at 4096.
Character count: about 155.
As indicated in Table 1, 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 6. The requirements for these contents are derived from the description in Section 3.4.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevTyp | Section 5.2.3 | OPTIONAL |
| DevID | Section 5.2.2 | OPTIONAL |
| APoolId | Section 5.2.1 | MANDATORY |
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.
Character count: about 120.
As indicated in Table 1, 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 7. The requirements for these contents are derived from the description in Section 3.5.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevTyp | Section 5.2.3 | OPTIONAL |
| DevID | Section 5.2.2 | OPTIONAL |
| PostS4 | Section 5.2.4 | MANDATORY |
| Proto | Section 5.2.7 | MANDATORY |
The example is straightforward. Note the warning priority indication at the beginning of the log.
Character count: about 110.
As indicated in Table 1, 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 8. The requirements for these contents are derived from the description in Section 3.6.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevTyp | Section 5.2.3 | OPTIONAL |
| DevID | Section 5.2.2 | OPTIONAL |
| SScop | Section 5.2.12 | MANDATORY |
| PScop | Section 5.2.8 | MANDATORY |
| SiteID | Section 5.2.11 | OPTIONAL |
| VLANid | Section 5.2.14 | OPTIONAL |
| VRFid | Section 5.2.15 | OPTIONAL |
Example 1: limit on TCP sessions for a specific user site reached at an AFTR with off-board log generation.
Character count: about 135.
Example 2: global limit on number of sessions for all subscribers served by the same VLAN.
Character count: about 115.
Example 3: limit on total number of sessions for TCP.
Character count: about 100.
As indicated in Table 1, 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 9. The requirements for these contents are derived from the description in Section 3.7.
| PARAM-NAME | Description | Requirement |
|---|---|---|
| DevID | Section 5.2.2 | OPTIONAL |
| SiteID | Section 5.2.11 | MANDATORY |
| PSID | Section 5.2.9 | MANDATORY |
Example: Lightweight 4over6 BR configured with PSID 15 for the given subscriber site.
Character count: about 110.
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 Data ID | Structured Data Parameter | Required or Optional | Reference |
|---|---|---|---|
| NATsess | OPTIONAL | RFCxxxx | |
| DevTyp | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| SiteID | MANDATORY | RFCxxxx | |
| PostS4 | MANDATORY | RFCxxxx | |
| Proto | MANDATORY | RFCxxxx | |
| PreSPt | MANDATORY | RFCxxxx | |
| PostSPt | MANDATORY | RFCxxxx | |
| TrigR | OPTIONAL | RFCxxxx | |
| ---- | ---- | ---- | ---- |
| NATBind | OPTIONAL | RFCxxxx | |
| DevTyp | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| SiteID | MANDATORY | RFCxxxx | |
| PostS4 | MANDATORY | RFCxxxx | |
| ---- | ---- | ---- | ---- |
| NATPBlk | OPTIONAL | RFCxxxx | |
| DevTyp | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| SiteID | MANDATORY | RFCxxxx | |
| PostS4 | MANDATORY | RFCxxxx | |
| PtRg | MANDATORY | RFCxxxx | |
| ---- | ---- | ---- | ---- |
| NATAddrEx | OPTIONAL | RFCxxxx | |
| DevTyp | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| APoolId | MANDATORY | RFCxxxx | |
| ---- | ---- | ---- | ---- |
| NATPEx | OPTIONAL | RFCxxxx | |
| DevTyp | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| PostS4 | MANDATORY | RFCxxxx | |
| Proto | MANDATORY | RFCxxxx | |
| ---- | ---- | ---- | ---- |
| NATQEx | OPTIONAL | RFCxxxx | |
| DevTyp | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| SScop | MANDATORY | RFCxxxx | |
| PScop | MANDATORY | RFCxxxx | |
| SiteID | OPTIONAL | RFCxxxx | |
| VLANid | OPTIONAL | RFCxxxx | |
| VRFid | OPTIONAL | RFCxxxx | |
| ---- | ---- | ---- | ---- |
| NATInvP | OPTIONAL | RFCxxxx | |
| DevID | OPTIONAL | RFCxxxx | |
| SiteID | MANDATORY | RFCxxxx | |
| PSID | MANDATORY | RFCxxxx |
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 11. 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 |
| BR | Lightweight 4over6 or MAP-E BR | RFCxxxx |
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 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.