idnits 2.17.1 draft-ietf-behave-syslog-nat-logging-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2014) is 3734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 6333' is mentioned on line 399, but not defined == Unused Reference: 'RFC6145' is defined on line 2779, but no explicit reference was found in the text == Unused Reference: 'RFC4026' is defined on line 2825, but no explicit reference was found in the text -- No information found for draft-behave-NAT-MIB - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.behave-NAT-MIB' ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Downref: Normative reference to an Informational RFC: RFC 4784 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- No information found for draft-behave-ipfix-nat-logging - is the name correct? -- No information found for draft-pcp-port-set - is the name correct? -- No information found for draft-softwire-lw4over6 - is the name correct? -- No information found for draft-softwire-map - is the name correct? -- No information found for draft-tsou-behave-natx4-log-reduction - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave Working Group Z. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track C. Zhou 5 Expires: July 29, 2014 T. Tsou 6 T. Taylor, Ed. 7 Huawei Technologies 8 January 25, 2014 10 Syslog Format for NAT Logging 11 draft-ietf-behave-syslog-nat-logging-06 13 Abstract 15 NAT devices are required to log events like creation and deletion of 16 translations and information about the resources the NAT is managing. 17 The logs are required to identify an attacker or a host that was used 18 to launch malicious attacks, and for various other purposes of 19 accounting and management. Since there is no standard way of logging 20 this information, different NAT devices behave differently. The lack 21 of a consistent way makes it difficult to write the collector 22 applications that would receive this data and process it to present 23 useful information. 25 This document describes the information that is required to be logged 26 by the NAT devices. It goes on to standardize formats for reporting 27 these events and parameters using SYSLOG (RFC 5424). A companion 28 document specifies formats for reporting the same events and 29 parameters using IPFIX (RFC 7011). Applicability statements are 30 provided in this document and its companion to guide operators and 31 implementors in their choice of which technology to use for logging. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 29, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 70 2.1. Static and Dynamic NATs . . . . . . . . . . . . . . . . . 6 71 2.2. Realms and Address Pools . . . . . . . . . . . . . . . . 7 72 2.2.1. Address Pools . . . . . . . . . . . . . . . . . . . . 7 73 2.3. NAT Logging Requirements For Different Transition Methods 8 74 2.4. Subscriber Identification . . . . . . . . . . . . . . . . 9 75 2.5. The Port Control Protocol (PCP) . . . . . . . . . . . . . 10 76 2.6. Logging At the Customer Edge . . . . . . . . . . . . . . 10 77 3. NAT-Related Events and Parameters . . . . . . . . . . . . . . 10 78 3.1. Events Relating To Allocation Of Resources To Hosts . . . 10 79 3.1.1. NAT Address Mapping Creation and Deletion . . . . . . 11 80 3.1.2. NAT Address and Port Mapping Creation and Deletion . 12 81 3.1.3. NAT Session Creation and Deletion . . . . . . . . . . 14 82 3.1.3.1. Destination Logging . . . . . . . . . . . . . . . 17 83 3.1.4. Port Range Allocation and Deallocation . . . . . . . 17 84 3.2. Threshold Events . . . . . . . . . . . . . . . . . . . . 19 85 3.2.1. Address Pool High- and Low-Water-Mark Threshold 86 Events . . . . . . . . . . . . . . . . . . . . . . . 19 87 3.2.2. Global Address Mapping High-Water-Mark Threshold 88 Event . . . . . . . . . . . . . . . . . . . . . . . . 20 89 3.2.3. Global Address and Port Mapping High-Water-Mark 90 Threshold Event . . . . . . . . . . . . . . . . . . . 21 91 3.2.4. Subscriber-Specific Address and Port Mapping 92 Threshold Event . . . . . . . . . . . . . . . . . . . 22 93 3.3. Limit-Related Events . . . . . . . . . . . . . . . . . . 22 94 3.3.1. Global Address Mapping Limit Exceeded . . . . . . . . 22 95 3.3.2. Global Address and Port Mapping Limit Exceeded . . . 23 96 3.3.3. Global Limit On Number of Active Hosts Exceeded . . . 24 97 3.3.4. Subscriber-Specific Limit On Number of Address and 98 Port Mappings Exceeded . . . . . . . . . . . . . . . 25 99 3.3.5. Global Limit On Number Of Fragments Pending 100 Reassembly Exceeded . . . . . . . . . . . . . . . . . 26 101 4. SYSLOG Applicability . . . . . . . . . . . . . . . . . . . . 27 102 5. SYSLOG Record Format For NAT Logging . . . . . . . . . . . . 27 103 5.1. SYSLOG HEADER Fields . . . . . . . . . . . . . . . . . . 28 104 5.2. Parameter Encodings . . . . . . . . . . . . . . . . . . . 29 105 5.2.1. General Encoding Rules . . . . . . . . . . . . . . . 32 106 5.2.2. Special Cases . . . . . . . . . . . . . . . . . . . . 32 107 5.2.3. Relationship To Objects In the NAT MIB . . . . . . . 33 108 5.3. Encoding Of Complete Log Report For Each Event Type . . . 35 109 5.3.1. Encoding of Events Relating To Allocation Of 110 Resources To Hosts . . . . . . . . . . . . . . . . . 35 111 5.3.1.1. NAT Address Mapping Creation and Deletion . . . . 36 112 5.3.1.2. NAT Address and Port Mapping Creation and 113 Deletion . . . . . . . . . . . . . . . . . . . . 37 114 5.3.1.3. NAT Session Creation and Deletion . . . . . . . . 39 115 5.3.1.4. Port Range Allocation and Deallocation . . . . . 41 116 5.3.2. Encoding of Threshold Events . . . . . . . . . . . . 43 117 5.3.2.1. NAT Address Pool High- and Low-Water-Mark 118 Threshold Events . . . . . . . . . . . . . . . . 43 119 5.3.2.2. Global Address Mapping High-Water-Mark 120 Threshold Exceeded . . . . . . . . . . . . . . . 44 121 5.3.2.3. Global Address and Port Mapping High-Water-Mark 122 Threshold Event . . . . . . . . . . . . . . . . . 45 123 5.3.2.4. Subscriber-Specific Address and Port Mapping 124 High-Water-Mark Threshold Event . . . . . . . . . 45 125 5.3.3. Encoding of Limit Events . . . . . . . . . . . . . . 46 126 5.3.3.1. Global Address Mapping Limit Exceeded . . . . . . 46 127 5.3.3.2. Global Address and Port Mapping Limit Exceeded . 47 128 5.3.3.3. Global Limit On Number of Active Hosts Exceeded . 48 129 5.3.3.4. Subscriber-Specific Limit On Number of Address 130 and Port Mappings Exceeded . . . . . . . . . . . 49 131 5.3.3.5. Pending Fragment Limit Exceeded . . . . . . . . . 50 132 6. Management Considerations . . . . . . . . . . . . . . . . . . 51 133 6.1. General Requirements For Control Of Logging . . . . . . . 51 134 6.1.1. Configuration of PRI Value . . . . . . . . . . . . . 51 135 6.1.2. Ability For Each Collector To Detect Lost Event 136 Reports . . . . . . . . . . . . . . . . . . . . . . . 52 137 6.1.3. Ability To Rate Limit Or Disable Event Reports . . . 52 138 6.2. Setting Limits and Thresholds . . . . . . . . . . . . . . 53 139 6.3. Other Management Requirements . . . . . . . . . . . . . . 54 140 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 141 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 142 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 143 9.1. Normative References . . . . . . . . . . . . . . . . . . 58 144 9.2. Informative References . . . . . . . . . . . . . . . . . 60 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 147 1. Introduction 149 This document deals with logging of NAT activity in two categories: 150 NAT translations and NAT resource usage. 152 Operators already need to record the addresses assigned to 153 subscribers at any point in time, for operational and regulatory 154 reasons. When operators introduce NAT devices that support address 155 sharing (e.g., Carrier Grade NATs (CGNs)) into their network, 156 additional information has to be logged. This document and 157 [I-D.behave-ipfix-nat-logging] are provided in order to standardize 158 the events and parameters to be recorded, using SYSLOG [RFC5424] and 159 IPFIX [RFC7011] respectively. The same content is proposed to be 160 logged by both documents. 162 In addition to records of subscriber activity, some operators use 163 logs to indicate when utilization of critical resources is 164 approaching or has reached limits set by the operator or 165 implementation. This document and the IPFIX document therefore 166 provide logs in two categories: thresholds exceeded and limits 167 exceeded. Operators have the alternative to receive the threshold 168 limits as SNMP notifications (see the NAT MIB [I-D.behave-NAT-MIB]). 170 Detailed logging requirements will vary depending on the context in 171 which they are used. For example, different methods for transition 172 from IPv4 to IPv6 require different events and different parameters 173 to be logged. Section 2 covers this topic. 175 Section 3 provides a detailed description of the events that need 176 logging and the parameters that may be required in the logs. 177 Section 3.1 describes events related to subscriber activity, 178 Section 3.2 covers threshold events, and Section 3.3 covers events 179 where hard limits have been reached. 181 The use of SYSLOG [RFC5424] has advantages and disadvantages compared 182 with the use of IPFIX [RFC7011]. Section 4 provides a statement of 183 applicability for the SYSLOG approach. 185 Section 5 specifies SYSLOG record formats for logging of the events 186 and parameters described in Section 3. Section 5.1 describes the 187 SYSLOG header format for each report, Section 5.2 lists and describes 188 the encoding of parameters that can appear in the logs, and 189 Section 5.3 specifies the encoding of the body of each event report. 190 The definitions provide the flexibility to vary actual log contents 191 based on the requirements of the particular deployment. 193 1.1. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in "Key words for use in 198 RFCs to Indicate Requirement Levels" [RFC2119]. 200 This document makes frequent reference to the NAT MIB. That 201 reference is to the document [I-D.behave-NAT-MIB]. 203 This document makes frequent reference to NAT behaviours defined in 204 [RFC4784]. In particular it refers to 206 o the recommended pooling behaviour "pooled" and its contrary 207 pooling behaviour "arbitrary"; and 209 o the recommended mapping behaviour "endpoint-independent" and its 210 contrary mapping behaviour "endpoint-dependent". 212 This document uses the term "address mapping" to denote an 213 association between an internal IP address and an IP address in a 214 selected external realm. See Section 2.2 for a further discussion of 215 this process. 217 The natMapIntAddrTable in the NAT MIB provides details on all 218 currently active address mappings. Note that this table is 219 applicable only when NAT pooling behaviour is "paired". 221 This document uses the [RFC4787] term "address and port mapping" to 222 denote a three-tuple association between an internal IP address and 223 port and an IP address and port in a selected external realm, or 224 between an internal pair and an pair in the selected realm. For 226 implementations which maintain a Binding Information Base (BIB) (as 227 described in Section 2 of [RFC6146], for example), the content of a 228 BIB entry is an address and port mapping. 230 The natMappingTable in the NAT MIB provides details on all 231 currently active address and port mappings. 233 This document uses the term "session" as it is defined in [RFC2663], 234 Section 2.3. From the point of view of this document, session 235 creation involves the combination of a source address and port 236 mapping with a mapping between internal and external destination 237 address and port to create a full five-tuple mapping. 239 Except where a clear distinction is necessary, this document uses the 240 abbreviation "NAT" to encompass both Network Address Translation (NAT 241 in the strict sense) and Network Address and Port Translation (NAPT). 242 The event report descriptions provided in this document apply to 243 NAPT, and can be simplified for pure NAT operation. 245 To match the terminology used by the NAT MIB, this document uses the 246 term "subscriber" to denote any device being served by the NAT, 247 whether individual host or customer edge router. That is, despite 248 the carrier-oriented terminology, the intended scope of applicability 249 of this document is both to NATs in the carrier network and managed 250 NATs in the customer network. 252 Finally, with two exceptions, when the terms "source" or 253 "destination" are used below, they denote the source and destination 254 of packets that are flowing from the internal to the external realm, 255 regardless of the direction of session establishment or the direction 256 of flow of an individual packet. The exceptions relate to the global 257 address and port mapping limit event and the pending fragment limit 258 event, when the actual source and destination addresses in the header 259 of the packet that hit the limit are reported. 261 2. Deployment Considerations 263 2.1. Static and Dynamic NATs 265 A NAT controls a set of resources in the form of one or more pools of 266 external addresses. If the NAT also does port translation (i.e., it 267 is a NAPT), it also controls the sets of UDP and TCP port numbers and 268 ICMP identifiers associated with each external address. 270 Logging requirements for a NAT depend heavily on its resource 271 allocation strategy. NATs can be classed as static or dynamic 272 depending on whether the resources provided to individual users are 273 pre-configured or allocated in real time as the NAT recognizes new 274 flows. 276 Static assignments can be logged at configuration time by the NAT or 277 by network infrastructure. The logging volume associated with static 278 assignments will be relatively low, of the order of the volume of 279 user logons. 281 Dynamic assignments typically require both more detail in the logs 282 and a higher volume of logs in total. A traditional Network Address 283 Port Translator (NAPT) as described in [RFC3022] and following the 284 recommendations of [RFC4787] and [RFC5382] will generate a new 285 address and port mapping each time it encounters a new internal 286 combination. 288 For statistical reasons, static assignments support lower address 289 sharing ratios than fully dynamic assignments as exemplified by the 290 traditional NAPT. The sharing ratio can be increased while 291 restraining log volumes by assigning ports to users in multi-port 292 increments as required rather than assigning just one port at a time. 293 A subscriber may start with no initial allocation, or may start with 294 an initial permanent allocation to which temporary increments are 295 added when the initial set is all being used. See [RFC6264] and 296 [I-D.tsou-behave-natx4-log-reduction] for details. If this strategy 297 is followed, logging will be required only when an increment is 298 allocated or reclaimed rather than every time an internal combination is mapped to an external . 301 2.2. Realms and Address Pools 303 A realm identifies an IP numbering space. A NAT session always maps 304 between an internal and an external realm. In simple NAT 305 configurations, it may be possible to identify a default internal 306 realm and/or a default external realm for all sessions. In more 307 complex NAT configurations a given realm may be an internal realm for 308 some sessions and an external realm for others. Realms without 309 subscriber sites are always external. 311 Address pools are associated with specific realms in their external 312 role. 314 It is necessary to define multiple realms when the NAT supports 315 overlapping IP numbering spaces. In such a case, the NAT must 316 determine the source realm and subscriber using additional 317 information associated with the incoming packet. See further 318 discussion in Section 2.4. 320 2.2.1. Address Pools 322 An address pool is a mechanism for configuring the set of addresses 323 to which a given internal address can be mapped in a given realm. 324 The pool may be used simply to ration the available addresses within 325 that realm, or may be selected for other reasons such as to add 326 additional semantics (e.g., type of service required) to the external 327 address within the target realm. Clearly a given internal address 328 may be mapped into more than one address pool at a given time. 330 The model of an address pool assumed in this document and in the NAT 331 MIB is that the pool offers a fixed range of port/ICMP identifier 332 values, the same over all addresses within the pool. How these are 333 allocated to individual mappings depends on the pooling behaviour. 334 With a pooling behaviour of "arbitrary", the NAT can select any 335 address in the pool with a free port value for the required protocol 336 and map the internal address to it. With the recommended pooling 337 behaviour of "paired", the NAT restricts itself to finding a free 338 port at the address to which the internal address is already mapped, 339 if there is one. 341 From this description, one can see that ports are a limited resource, 342 subject to exhaustion at the pool level and, with "paired" behaviour, 343 at the level of the individual address. Log events are defined in 344 Section 3.2.1 that allow monitoring of port utilization at the pool 345 level. Section 6.2 discusses how the thresholds for triggering these 346 events should be varied depending on pooling behaviour. 348 2.3. NAT Logging Requirements For Different Transition Methods 350 A number of transition technologies have been or are being developed 351 to aid in the transition from IPv4 to IPv6. 6rd [RFC5969] and DS-Lite 352 [RFC6333] are at the deployment stage. Several 'stateless' 353 technologies: Public IPv4 over IPv6 [RFC7040], MAP-E 354 [I-D.softwire-map], and Lightweight 4over6 [I-D.softwire-lw4over6] 355 have seen experimental deployment and are in the process of being 356 standardized at the time of writing of this document. 358 Of the technologies just listed, 6rd and Public IPv4 over IPv6 do not 359 involve NATs and hence need not be considered further. The other 360 techniques involve NAT at the customer edge, at the border router, or 361 both, and hence are in scope. 363 A DS-Lite Address Family Transition Router (AFTR) includes a large- 364 scale session-stateful NAT44 processing potentially millions of 365 sessions per second. The special character of AFTR operation over 366 that of a traditional NAT44 is that the source IPv4 addresses of the 367 internal hosts will not be unique. As a consequence, identification 368 of the realm and subscriber from which the packet was sent needs to 369 include an additional identifier associated with the subscriber host. 370 For basic DS-Lite, this will be the IPv6 address used to encapsulate 371 the packets outgoing from the host. See Section 6.6 of [RFC6333]. 372 For gateway-initiated DS-Lite [RFC6674], two identifiers are needed: 373 an identifier of the softwire from the gateway to the NAT, and an 374 identifier associated with the incoming tunnel to the gateway. 376 The DS-Lite customer edge equipment (the 'B4') may also perform NAT44 377 functions, similar to the functions performed by traditional NAT44 378 devices. 380 As a NAT44, the DS-Lite AFTR may be fully dynamic, or may allocate 381 ports in increments as described in the previous section. 383 Lightweight 4over6 [I-D.softwire-lw4over6] and MAP-E 384 [I-D.softwire-map] both require NAT44 operation at the customer edge. 385 In both cases the resource allocation strategy is static. Thus any 386 logging of resource allocation for these two transition techniques 387 can be done by the network at configuration time. 389 2.4. Subscriber Identification 391 The ability to identify the particular subscriber involved in an 392 event is required for the events defined in Section 3.1, and 393 desirable for technician follow-up for those defined in Section 3.2.4 394 and Section 3.3. 396 As mentioned above, in some NAT configurations the source address is 397 insufficient to identify an individual subscriber because of 398 overlapping address space, and additional information is required. 399 For example, if the NAT supports DS-Lite [RFC 6333], the source 400 address of incoming packets from DS-Lite subscribers will always be 401 in the range 192.0.0/29. The additional information required in this 402 case is the IPv6 address of the encapsulating header. 404 The natSubscribersTable in the NAT MIB contains the additional 405 information needed, if any, to identify each subscriber. Thus it is 406 sufficient to include the index to this table in the event report to 407 provide the needed identification. However, this implies that for 408 full interpretation of the event report, the configuration 409 information stored in the natSubscribersTable must be stored (along 410 with AAA information relating the additional identifiers to the 411 subscriber profiles, which must be stored in any event). To relieve 412 the operator of the need to store the configuration data (given that 413 the logs may be needed months or years after they were recorded), the 414 reports specified in Section 3.1 include the additional identifying 415 information that is found in the natSubscribersTable. 417 This document standardizes the presentation of the following possible 418 additional classifying information within NAT-related log reports: 420 o interface index [RFC2863]; 422 o VLAN index [RFC4363]; 424 o VPN identifier [RFC4265]; 426 o DS-Lite encapsulating IPv6 address [RFC6333]. 428 Which of these is actually used in a given NAT depends on 429 implementation and deployment. 431 Gateway-Initiated DS-Lite [RFC6674] identifiers could also be 432 specified, but it seems premature to do so because it is not clear 433 which of the variety of possibilities presented in Section 6 and 434 Appendix A.2 of [RFC6674] are actually being deployed. 436 2.5. The Port Control Protocol (PCP) 438 The Port Control Protocol (PCP) [RFC6887] and its port set extension 439 [I-D.pcp-port-set] can be viewed as a way to provision ports by other 440 means. However, PCP can be invoked on a per-flow basis, so the 441 volume of logs generated by a PCP server can be closer to the volume 442 associated with a fully dynamic NAT. The volume really depends on 443 how PCP is being used in a specific network. 445 2.6. Logging At the Customer Edge 447 Logging at the customer edge (or at the ISP edge for NATs protecting 448 the ISP's internal networks) may be done by the customer for purposes 449 of internal management, or by the ISP for its own administrative and 450 regulatory purposes. Given the likelihood of a high internal 451 community of interest, it is possible but unlikely that a NAT at the 452 edge of a large enterprise network processes a number of new packet 453 flows per second which is comparable to the volume handled by a 454 carrier grade NAT. Most customer edge NATs will handle a much 455 smaller volume of flows. 457 3. NAT-Related Events and Parameters 459 The events which follow were initially gleaned, in the words of the 460 authors of [I-D.behave-ipfix-nat-logging], from [RFC4787] and 461 [RFC5382]. Some details were subsequently informed by the discussion 462 in Section 2 and by provisions within the NAT MIB. Section 4 of 463 [RFC6888] also provides a brief statement of logging requirements for 464 carrier grade NATs. 466 In SYSLOG, the timestamp and the event type will appear in the log 467 header rather than as an explicit part of the structured data portion 468 of the log. Hence they are omitted from the parameter tabulations 469 that follow. 471 Parameters marked CONDITIONAL are REQUIRED under some circumstances 472 but not others. Details are provided for each event. 474 3.1. Events Relating To Allocation Of Resources To Hosts 476 Setting up a NAT session proceeds in a series of logical steps: 477 creation of an address mapping, creation of an address and port 478 mapping, and finally, creation of the session. 480 The reports corresponding to these three steps are defined in 481 Section 3.1.1, Section 3.1.2, and Section 3.1.3 respectively. Which 482 of these reports is enabled depends on the NAT implementation and 483 operator preferences, subject to the considerations of the next 484 paragraph. 486 If the NAT implements the recommended pooling behaviour of "paired", 487 address mapping creation is an event distinct in general from the 488 creation of a subsequent address and port mapping based on that 489 address mapping. However, if the pooling behaviour is "arbitrary" 490 [RFC4787], the two events occur simultaneously and there is no point 491 in reporting both. Similarly, if the NAT implements the recommended 492 mapping behaviour of "endpoint-independent mapping", the two events 493 of address and port mapping creation and session creation based on 494 that mapping are distinct and may meaningfully be reported 495 separately. However, if the mapping behaviour is "endpoint- 496 dependent", the two events occur simultaneously and it is only 497 meaningful to report session creation. 499 The fourth report type in this section describes the bulk allocation 500 of ports to an address mapping, which the NAT may implement if the 501 pooling behaviour is "paired" [RFC4787]. It, along with the other 502 reports, is needed to provide complete accountability for resources 503 allocated to the subscriber. 505 3.1.1. NAT Address Mapping Creation and Deletion 507 Two specific events are provided: 509 o NAT address mapping creation; 511 o NAT address mapping deletion. 513 Implementations MUST NOT report these events unless pooling behaviour 514 is "paired". 516 Address mapping is discussed in detail in Section 2.2. 518 One address mapping creation event is associated with potentially 519 many succeeding address and port mapping creation events, as 520 individual port values are mapped for specific protocols. Similarly, 521 an address mapping deletion event may be associated with potentially 522 many address and port mapping deletion events, which may have 523 preceded it over a period of time or may occur at the same time as a 524 result of the address unbinding. 526 The address mapping events take the following specific parameters: 528 o NAT instance identifier (CONDITIONAL); 530 o Source subscriber index (MANDATORY); 532 o Additional source subscriber classifier value as recognized at the 533 ingress to the internal realm (CONDITIONAL); 535 o Internal realm (CONDITIONAL); 537 o Internal address type (MANDATORY); 539 o Internal source IP address (MANDATORY); 541 o External realm (CONDITIONAL); 543 o External address type (MANDATORY); 545 o External source IP address (MANDATORY); 547 o Trigger for address mapping creation or deletion (OPTIONAL): 549 * outgoing packet; 551 * administrative action (e.g., via the Port Control Protocol 552 [RFC6887]); or 554 * autonomous action of the NAT. 556 Conditions: 558 o NAT instance identifier REQUIRED if device supports more than one 559 instance, else MAY appear. 561 o Additional source subscriber classifier value REQUIRED if the 562 internal source IP address is not enough to identify the 563 subscriber unambiguously, else MUST NOT appear. 565 o Internal or external realm REQUIRED if not the default internal or 566 external realm, respectively, else MAY appear. 568 3.1.2. NAT Address and Port Mapping Creation and Deletion 570 The address and port mapping creation or deletion event reports the 571 addition or deletion of an address and port mapping as defined in 572 Section 1.1. If the implementation maintains a Binding Information 573 Base (BIB), this is equivalent to the creation or deletion of a BIB 574 entry. Implementations MUST support the generation of the address 575 and port mapping creation/deletion event reports if they implement 576 the recommended mapping behaviour "endpoint-independent". They MAY 577 support reporting of these events in the contrary case. 579 The address and port mapping creation/deletion event report provides 580 the same information as the session creation/deletion event, except 581 for the destination-related fields and (in general) timestamp values 582 in the latter. With "endpoint-independent" mapping behaviour, one 583 address and port mapping creation event is associated with 584 potentially many succeeding session creation events. Similarly, an 585 address and port mapping deletion event will be associated with 586 potentially many session deletion events, which may have preceded it 587 over a period of time or may occur at the same time as a result of 588 the address and port mapping deletion. 590 Operators should disable the reporting of address and port mapping 591 creation and deletion events when destination logging is enabled, 592 because of the redundancy between the address and port mapping and 593 session event reports. However, if destination logging is disabled 594 and the NAT uses the recommended "endpoint-independent" mapping 595 behaviour, it is the session events that are redundant and should be 596 disabled. 598 The following specific events are defined: 600 o NAT address and port mapping creation 602 o NAT address and port mapping deletion 604 These take the same parameters for all types of NAT. The internal 605 realm, subscriber-identifying information, internal source IP 606 address, external realm, and external source IP address capture the 607 underlying address mapping. The port values and protocol are unique 608 to the address and port mapping. 610 The parameters for the address and port mapping creation/deletion 611 event are: 613 o NAT instance identifier (CONDITIONAL); 615 o Source subscriber index (MANDATORY); 617 o Additional source subscriber classifier value as recognized at the 618 ingress to the internal realm (CONDITIONAL); 620 o Internal realm (CONDITIONAL); 622 o Internal address type (MANDATORY); 623 o Internal source IP address (MANDATORY); 625 o Internal source port or ICMP identifier (MANDATORY); 627 o External realm (CONDITIONAL); 629 o External address type (MANDATORY); 631 o External source IP address (MANDATORY); 633 o External source port or ICMP identifier (MANDATORY); 635 o Protocol identifier (MANDATORY); 637 o Trigger for address and port mapping creation or deletion 638 (OPTIONAL): 640 * outgoing packet received; 642 * incoming packet received; 644 * administrative action (e.g., via the Port Control Protocol 645 [RFC6887]); or 647 * deletion of the underlying address mapping (applicable only if 648 pooling behaviour is "paired" [RFC4787]). 650 Conditions: 652 o NAT instance identifier REQUIRED if device supports more than one 653 instance, else MAY appear. 655 o Additional source subscriber classifier value REQUIRED if the 656 internal source IP address is not enough to identify the 657 subscriber unambiguously, else MUST NOT appear. 659 o Internal or external realm REQUIRED if not the default internal or 660 external realm, respectively, else MAY appear. 662 3.1.3. NAT Session Creation and Deletion 664 A NAT session creation or deletion event is logged when a address and 665 port mapping is further bound to or unbound from a specific 666 destination address and port in the external realm. One to many 667 sessions can be based on the same address and port mapping. 669 Implementations MUST provide a means for the operator to specify 670 whether destination information is to be included in the reports of 671 these events (see discussion below). 673 The following specific events are defined: 675 o NAT session creation 677 o NAT session deletion 679 These take the same parameters for all types of NAT. Parameters 680 "internal realm" through "protocol identifier" capture the underlying 681 address and port mapping. Subsequent parameters capture the 682 destination address and destination subscriber identity (if 683 applicable). 685 The parameters for the session creation/deletion event are: 687 o NAT instance identifier (CONDITIONAL); 689 o Internal source subscriber index, equal to the natSubscriberIndex 690 value in the natSubscribersTable in the NAT MIB (MANDATORY); 692 o Additional internal subscriber classifier value (CONDITIONAL); 694 o Internal realm (CONDITIONAL); 696 o Internal address type (MANDATORY); 698 o Internal source IP address (MANDATORY); 700 o Internal source port or ICMP identifier (MANDATORY); 702 o External realm (CONDITIONAL); 704 o External address type (MANDATORY); 706 o External source IP address (MANDATORY); 708 o External source port or ICMP identifier (MANDATORY); 710 o Protocol identifier (MANDATORY); 712 o Internal destination IP address (CONDITIONAL); 714 o Internal destination port or ICMP identifier (CONDITIONAL); 716 o Destination subscriber index (CONDITIONAL); 717 o Additional destination subscriber classifier value as recognized 718 at the ingress to the external realm (CONDITIONAL); 720 o External destination IP address (CONDITIONAL); 722 o External destination port or ICMP identifier (CONDITIONAL); 724 o Trigger for session creation or deletion (OPTIONAL): 726 * outgoing packet received; 728 * incoming packet received; 730 * administrative action (e.g., via the Port Control Protocol 731 [RFC6887]); or 733 * deletion of the underlying address and port mapping (applicable 734 only if the NAT mapping behaviour is "endpoint-independent". 736 Conditions: 738 o NAT instance identifier REQUIRED if device supports more than one 739 instance, else MAY appear. 741 o Additional source subscriber classifier value REQUIRED if the 742 internal source IP address is not enough to identify the 743 subscriber unambiguously, else MUST NOT appear. 745 o Internal or external realm REQUIRED if not the default internal or 746 external realm, respectively, else MAY appear. 748 o Internal destination address and port REQUIRED if destination 749 logging is enabled and these need to be remapped to external 750 destination address and port. Otherwise, if destination logging 751 is disabled, they MUST NOT appear, and if destination logging is 752 enabled, they SHOULD NOT appear because of redundancy. 754 o External destination subscriber index REQUIRED if destination 755 logging is enabled and the destination is a subscriber served by 756 the NAT, else MUST NOT appear. 758 o Additional external subscriber classifier value REQUIRED if 759 destination logging is enabled and the destination is a subscriber 760 served by the NAT and the external destination address is not 761 enough to identify the external destination subscriber 762 unambiguously, else MUST NOT appear. 764 o External destination address and port REQUIRED if destination 765 logging is enabled, else MUST NOT appear. 767 3.1.3.1. Destination Logging 769 The logging of destination address and port is undesirable, for 770 several reasons. [RFC6888] recommends against destination logging 771 because of the privacy issues it creates. From an operator's point 772 of view, destination logging is costly not just because of the volume 773 of logs it will generate, but because the NAT now has to carry 774 additional session state so that it only needs to log once per 775 session between two transport end points rather than logging every 776 packet. Finally, [RFC4787], etc. recommend the use of endpoint- 777 independent mapping to maximize the ability of applications to 778 operate through the NAT. In that case, most of the contents of the 779 session creation event report will be repeated for one destination 780 after another. 782 One possibility is that the implementation provides the operator with 783 the ability to log destinations only for particular subscribers or 784 particular mapped addresses on a special study basis. This facility 785 could be used for trouble-shooting or malicious activity tracing in 786 particular cases as required. If such a capability is provided, the 787 implementation MUST report destination information for sessions 788 matching the specified criteria, but MUST NOT report these events for 789 other sessions. 791 3.1.4. Port Range Allocation and Deallocation 793 This event is recorded at a hybrid NAT whenever the set of ports 794 allocated to a given address mapping changes. It is assumed that 795 when ports are allocated in bulk, the same values are allocated for 796 all protocols. 798 The following specific events are defined: 800 o Port range allocation; 802 o Port range deallocation. 804 The parameters for these events are: 806 o NAT instance identifier (CONDITIONAL); 808 o Source subscriber index (MANDATORY); 810 o Additional source subscriber classifier value as recognized at the 811 ingress to the internal realm (CONDITIONAL); 813 o Internal realm (CONDITIONAL); 815 o Internal address type (MANDATORY); 817 o Internal source IP address (MANDATORY); 819 o External realm (CONDITIONAL); 821 o External address type (MANDATORY); 823 o External source IP address (MANDATORY); 825 o Lowest port number of the range being allocated or deallocated 826 (MANDATORY). 828 o Highest port number of the range being allocated or deallocated 829 (MANDATORY). 831 o Trigger for port range allocation or deallocation (OPTIONAL): 833 * outgoing packet received; 835 * incoming packet received; 837 * administrative action (e.g., via the Port Control Protocol 838 [RFC6887]); or 840 * autonomous action of the NAT. 842 Conditions: 844 o NAT instance identifier REQUIRED if device supports more than one 845 instance, else MAY appear. 847 o Additional source subscriber classifier value REQUIRED if the 848 internal source IP address is not enough to identify the 849 subscriber unambiguously, else MUST NOT appear. 851 o Internal or external realm REQUIRED if not the default internal or 852 external realm, respectively, else MAY appear. 854 It will be necessary to use multiple event reports to report more 855 complex allocations or deallocations. 857 3.2. Threshold Events 859 The events of this section are based on thresholds set by the 860 operator within the NAT MIB. Cross-references to the associated MIB 861 objects are provided for each event. With the exception of the 862 address pool low-water-mark event, the threshold events provide early 863 warning of potential dropped packets due to resource exhaustion or 864 administrator-imposed limits. 866 3.2.1. Address Pool High- and Low-Water-Mark Threshold Events 868 Two specific events provide reports on address pool utilization: 870 o High-water-mark threshold reached or exceeded; 872 o Low-water-mark threshold reached or under-shot. 874 Depending on deployment the operator has the alternative of using the 875 SNMP notifications natNotifPoolWater-MarkHigh and natNotifPoolWater- 876 MarkLow defined in the NAT MIB rather than logging these events. 878 Address pools are discussed in Section 2.2.1. The 879 natPoolTable object in the NAT MIB provides access to parameters 880 describing the utilization level of address-port combinations within 881 a given pool. Since a new mapping cannot be allocated unless a 882 mappable address and a free port on that address are available, it is 883 important to know when the available set of address-port combinations 884 within a given pool is nearing exhaustion. Hence the 885 natPoolTable contains a high-water-mark threshold settable by the 886 operator. An address pool high-water-mark event report is generated 887 when a new mapping into the pool is requested and aggregate address- 888 port utilization is equal to or greater the threshold. 890 Similarly it can be of interest to know when a pool is under- 891 utilized. Hence the natPoolTable also provides a low-water-mark 892 threshold. An address pool low-water-mark event report is generated 893 when aggregate address-port utilization is equal to or less than the 894 low-water-mark threshold. 896 Section 6.2 discusses factors affecting the choice of the threshold 897 values. 899 The high-water-mark threshold event provides a warning that the 900 address-port combinations offered by the pool are nearing exhaustion. 901 Upon exhaustion, subscribers may be unable to establish new 902 connections because no address has enough free port values left to be 903 allocated to an address mapping ("address exhaustion"). This applies 904 to the case of "paired" pooling behaviour, where typically an address 905 will not be allocated unless it has a sufficient number of free 906 ports. Alternatively, new connections cannot be established simply 907 because no address in the pool has a free port number for the 908 required protocol ("port exhaustion"). 910 Packets triggering failed attempts to establish new connections due 911 to address exhaustion are included in the following NAT MIB dropped 912 packet counters: 914 o globally, natResourceErrors in the natCounters table; 916 o per protocol, natProtocolResourceErrors in natProtocolTable; 918 o per subscriber, natSubscriberResourceErrors in 919 natSubscribersTable. 921 Packets triggering failed attempts to establish new connections due 922 to port exhaustion are counted in the following NAT MIB dropped 923 packet counters: 925 o globally, natOutOfPortErrors in the natCounters table; 927 o per protocol, natProtocolOutOfPortErrors in natProtocolTable; 929 o per subscriber, natSubscriberOutOfPortErrors in 930 natSubscribersTable. 932 An address pool threshold event report contains the following 933 specific parameters: 935 o NAT instance identifier (CONDITIONAL); 937 o Pool identifier (MANDATORY); 939 o The threshold value set by the administrator (MANDATORY). 941 Conditions: 943 o NAT instance identifier REQUIRED if device supports more than one 944 instance, else MAY appear. 946 3.2.2. Global Address Mapping High-Water-Mark Threshold Event 948 One specific event allows monitoring of the total number of mappings 949 between internal and external addresses: 951 o Address mapping high-water-mark threshold exceeded. 953 Implementations MUST NOT generate this event report unless the 954 pooling behaviour is "paired". Depending on deployment, operators 955 can choose instead to use the SNMP notification natNotifAddrMappings 956 defined in the NAT MIB. 958 The NAT MIB displays cumulative counts of address mappings created 959 and removed in the natCounters table. When the difference between 960 these two counters is greater than the threshold 961 natAddrMapNotifyThreshold provided in the natLimits table the global 962 address binding high-water-mark threshold event is reported. 964 The specific parameters provided by this event report are: 966 o NAT instance identifier (CONDITIONAL); 968 o Current number of active address mappings (MANDATORY). 970 Conditions: 972 o NAT instance identifier REQUIRED if device supports more than one 973 instance, else MAY appear. 975 3.2.3. Global Address and Port Mapping High-Water-Mark Threshold Event 977 One specific event allows monitoring of the total number of active 978 address and port mappings. Where the NAT implements a BIB, this is 979 equivalent to the total number of BIB entries. 981 o address and port mapping high-water-mark threshold exceeded. 983 Depending on deployment, operators can choose instead to use the SNMP 984 notification natNotifMappings defined in the NAT MIB. 986 The NAT MIB displays cumulative counts of address and port mappings 987 created and removed in the natCounters table. When the difference 988 between these two counters is greater than the threshold 989 natMappingsNotifyThreshold provided in the natLimits table the global 990 mapping high-water-mark threshold event is reported. 992 The specific parameters provided by this event report are: 994 o NAT instance identifier (CONDITIONAL); 996 o Current number of active address and port mappings (MANDATORY). 998 Conditions: 1000 o NAT instance identifier REQUIRED if device supports more than one 1001 instance, else MAY appear. 1003 3.2.4. Subscriber-Specific Address and Port Mapping Threshold Event 1005 An event is provided to allow monitoring of the total number of 1006 active mappings per subscriber: 1008 o Subscriber-specific mapping high-water-mark threshold exceeded. 1010 Depending on deployment, operators can choose instead to use the SNMP 1011 notification natNotifSubscriberMappings defined in the NAT MIB. 1013 The NAT MIB displays cumulative counts of address and port mappings 1014 created and removed per subscriber in the natSubscribersTable. When 1015 the difference between these two counters is greater than the 1016 threshold natSubscriberMapNotifyThresh provided in that table the 1017 subscriber address and port mapping high-water-mark threshold event 1018 is reported. 1020 The specific parameters provided by this event report are: 1022 o NAT instance identifier (CONDITIONAL); 1024 o Index of the affected subscriber (MANDATORY). 1026 o Current number of active mappings for this subscriber (MANDATORY). 1028 Conditions: 1030 o NAT instance identifier REQUIRED if device supports more than one 1031 instance, else MAY appear. 1033 3.3. Limit-Related Events 1035 The events of this section are generated when hard limits set by the 1036 operator are exceeded. The consequence for service will be dropped 1037 packets. As with the threshold events, the description of each 1038 report includes cross-references to the associated MIB objects. 1040 3.3.1. Global Address Mapping Limit Exceeded 1042 The global address mapping limit exceeded event is reported when a 1043 new address mapping is requested but the total number of address 1044 mappings would exceed an administrative limit if it were added. The 1045 limit is given by object natLimitAddressMappings in the natLimits 1046 table of the NAT MIB. MIB counters giving number of packets dropped 1047 due to resource limitations including this one are: 1049 o globally, natResourceErrors in the natCounters table; 1051 o per protocol, natProtocolResourceErrors in natProtocolTable; 1053 o per subscriber, natSubscriberResourceErrors in 1054 natSubscribersTable. 1056 Implementations MUST NOT generate this event report unless the 1057 pooling behaviour is "paired". Depending on deployment, operators 1058 can choose instead to use the SNMP notification natNotifAddrMappings 1059 defined in the NAT MIB. 1061 The parameters for this event are: 1063 o NAT instance identifier (CONDITIONAL); 1065 o Index of the affected subscriber (MANDATORY). 1067 Conditions: 1069 o NAT instance identifier REQUIRED if device supports more than one 1070 instance, else MAY appear. 1072 The subscriber index is provided to allow the operator to correlate 1073 the event with any subscriber complaints or possible abuse. 1075 3.3.2. Global Address and Port Mapping Limit Exceeded 1077 The global address and port mapping limit exceeded event is reported 1078 when a new address and port mapping is requested but the total number 1079 of address and port mappings would exceed an administrative limit if 1080 it were added. The limit is given by object natLimitMappings in the 1081 natLimits table of the NAT MIB. MIB counters giving number of 1082 packets dropped due to resource limitations including this one are: 1084 o globally, natResourceErrors in the natCounters table; 1086 o per protocol, natProtocolResourceErrors in natProtocolTable; 1088 o per subscriber, natSubscriberResourceErrors in 1089 natSubscribersTable. 1091 The parameters for this event are: 1093 o NAT instance identifier (CONDITIONAL); 1095 o Index of the internal subscriber (CONDITIONAL); 1096 o Index of the external subscriber (CONDITIONAL); 1098 o Source realm of the triggering packet (MANDATORY); 1100 o Incoming packet header IP address type (CONDITIONAL); 1102 o Incoming packet source IP address (CONDITIONAL). 1104 Conditions: 1106 o NAT instance identifier REQUIRED if device supports more than one 1107 instance, else MAY appear. 1109 o The index of the internal subscriber is REQUIRED if the mapping 1110 was triggered by a packet outgoing from the internal to the 1111 external realm, else MUST NOT appear. 1113 o The index of the external subscriber is REQUIRED if the mapping 1114 was triggered by a packet incoming from a subscriber served by the 1115 NAT and located in the external realm (i.e., using an address 1116 mapping created previously by the internal subscriber), else MUST 1117 NOT appear. 1119 o The address type and source IP address from the initiating packet 1120 are REQUIRED if the mapping was triggered by a packet incoming 1121 from a purely external realm (i.e., using an address mapping 1122 created previously by the internal subscriber), else MAY appear. 1124 The subscriber index or packet source address is provided to allow 1125 the operator to correlate the event with any subscriber complaints or 1126 possible abuse. 1128 3.3.3. Global Limit On Number of Active Hosts Exceeded 1130 The global limit on number of active hosts exceeded event is reported 1131 when an address mapping is requested (at least at the logical level) 1132 for a host with no previous active mappings, but the total number of 1133 active hosts would exceed an administrative limit if it were added. 1134 The limit is given by object natLimitSubscribers in the natLimits 1135 table of the NAT MIB. MIB counters giving number of packets dropped 1136 due to resource limitations including this one are: 1138 o globally, natResourceErrors in the natCounters table; 1140 o per protocol, natProtocolResourceErrors in natProtocolTable; 1142 o per subscriber, natSubscriberResourceErrors in 1143 natSubscribersTable. 1145 The parameters for this event are: 1147 o NAT instance identifier (CONDITIONAL); 1149 o Index of the affected subscriber (MANDATORY). 1151 Conditions: 1153 o NAT instance identifier REQUIRED if device supports more than one 1154 instance, else MAY appear. 1156 The subscriber index is provided to allow the operator to correlate 1157 the event with any subscriber complaints. 1159 3.3.4. Subscriber-Specific Limit On Number of Address and Port Mappings 1160 Exceeded 1162 The subscriber-specific limit on number of address and port mappings 1163 exceeded event is reported when a new mapping is requested, but the 1164 total number of active mappings for that subscriber would exceed an 1165 administrative limit if it were added. The limit is given by object 1166 natSubscriberLimitMappings in natSubscribersTable in the NAT MIB. 1167 MIB counters giving number of packets dropped due to resource 1168 limitations including this one are: 1170 o globally, natResourceErrors in the natCounters table; 1172 o per protocol, natProtocolResourceErrors in natProtocolTable; 1174 o per subscriber, natSubscriberResourceErrors in 1175 natSubscribersTable. 1177 The parameters for this event are: 1179 o NAT instance identifier (CONDITIONAL); 1181 o Index of the affected subscriber (MANDATORY). 1183 Conditions: 1185 o NAT instance identifier REQUIRED if device supports more than one 1186 instance, else MAY appear. 1188 The subscriber index is provided to allow the operator to take 1189 administrative action or to correlate the event with any subscriber 1190 complaints or possible abuse. 1192 3.3.5. Global Limit On Number Of Fragments Pending Reassembly Exceeded 1194 The global limit on number of fragments pending reassembly exceeded 1195 event is reported when a new fragment is received and the number of 1196 fragments currently awaiting reassembly is already equal to an 1197 administrative limit. That limit is given by the natLimitFragments 1198 object in the natLimits table. This event MUST NOT be reported 1199 unless the NAT supports the "receive fragments out of order" behavior 1200 [RFC4787]. MIB counters giving number of packets dropped due to 1201 resource limitations including this one are: 1203 o globally, natResourceErrors in the natCounters table; 1205 o per protocol, natProtocolResourceErrors in natProtocolTable; 1207 o per subscriber, natSubscriberResourceErrors in 1208 natSubscribersTable. 1210 The parameters for this event provide the contents of the IP header 1211 of the received fragment that triggered it. If the source of the 1212 packet is a subscriber served by the NAT and the subscriber index can 1213 be determined, it MUST also be included. 1215 o NAT instance identifier (CONDITIONAL); 1217 o Source realm of the packet (MANDATORY); 1219 o Packet header IP address type (MANDATORY); 1221 o Packet source IP address (MANDATORY); 1223 o Packet destination IP address (MANDATORY); 1225 o Source subscriber index (CONDITIONAL). 1227 Conditions: 1229 o NAT instance identifier REQUIRED if device supports more than one 1230 instance, else MAY appear. 1232 o Source subscriber index REQUIRED if the source of the packet is a 1233 subscriber served by the NAT and can be determined, else MUST NOT 1234 appear. 1236 4. SYSLOG Applicability 1238 The primary advantage of SYSLOG is the human readability and 1239 searchability of its contents. In addition, it has built-in priority 1240 and other header fields that allow for separate routing of reports 1241 requiring management action. Finally, it has a well-developed 1242 underpinning of transport and security protocol infrastructure. 1244 SYSLOG presents two obstacles to scalability: the fact that the 1245 records will typically be larger than records based on a binary 1246 protocol such as IPFIX, and, depending on the architectural context, 1247 the reduced performance of a router that is forced to do text 1248 manipulation in the data plane. One has to conclude that for larger 1249 message volumes, IPFIX should be preferred as the reporting medium on 1250 the NAT itself. It is possible that SYSLOG could be used as a back- 1251 end format on an off-board device processing IPFIX records in real 1252 time, but this would give a limited boost to scalability. One 1253 concern expressed in list discussion is that when the SYSLOG 1254 formatting process gets overloaded records will be lost. 1256 As a result, the key question is what the practical cutoff point is 1257 for the expected volume of SYSLOG records, on-board or off-board the 1258 NAT. This obviously depends on the computing power of the formatting 1259 platform, and also on the record lengths being generated. 1261 Information has been provided to the BEHAVE list at the time of 1262 writing to the effect that one production application is generating 1263 an average of 150,000 call detail records per second, varying in 1264 length from 500 to 1500 bytes. Capacities several times this level 1265 have been reported involving shorter records, but this particular 1266 application has chosen to limit the average in order to handle peaks. 1268 As illustrated by the example in Section 5.3.1.3, if destination 1269 logging is enabled, typical record sizes for session event logs are 1270 in the order of 300 bytes, so throughput capacity should be higher 1271 than in the call detail case for the same amount of computing power. 1272 However, note that bursts of session deletion events may occur as a 1273 result of deletion of the underlying mapping or address mapping. 1275 In private communication, a discussant has noted a practical limit of 1276 a few hundred thousand SYSLOG records per second on a router. 1278 5. SYSLOG Record Format For NAT Logging 1280 This section describes the SYSLOG record format for NAT logging in 1281 terms of the field names used in [RFC5424] and specified in Section 6 1282 of that document. In particular, this section specifies values for 1283 the APP-NAME and MSGID fields in the record header, the SD-ID 1284 identifying the STRUCTURED-DATA section, and the PARAM-NAMEs and 1285 PARAM-VALUE types for the individual possible parameters within that 1286 section. The specification is in three parts, covering the header, 1287 encoding of the individual parameters, and encoding of the complete 1288 log record for each event type. 1290 5.1. SYSLOG HEADER Fields 1292 Within the HEADER portion of the SYSLOG record, the priority (PRI) 1293 level is subject to local policy, but a Severity value of 6 1294 (Informational) is suggested for the events relating to creation and 1295 deletion of sessions, mappings, address mappings, and port 1296 allocation, combined with a suitable Facility value in the range 1297 16-23 (local use) to ensure routing to a secure collector. The 1298 Facility value(s) for the threshold and limit events will presumably 1299 be chosen to route them to maintenance for immediate action and/or to 1300 provisioning for less urgent consideration. The suggested value of 1301 Severity by event type is shown in Table 1, but in practice has a 1302 clear dependency on the context within which the NAT is operating. 1304 The TIMESTAMP field SHOULD be expressed with sufficient precision to 1305 distinguish non-simultaneous event occurrences, subject to the 1306 accuracy of the local clock. This specification does not assume the 1307 ability to correlate the events reported by the subject device with 1308 events recorded by other devices, although that may be required for 1309 other reasons. Hence from the point of view of this specification 1310 only relative rather than absolute accuracy is of interest. 1312 The HOSTNAME header field MUST identify the NAT device. The value of 1313 the HOSTNAME field is subject to the preferences given in 1314 Section 6.2.4 of [RFC5424]. 1316 The values of the APP-NAME and MSGID fields in the record header 1317 determine the semantics of the record. To simplify log collection 1318 procedures, the APP-NAME value "NAT" MUST be used for the event 1319 reports specified in Section 5.3.1, the APP-NAME value "NATTHR" MUST 1320 be used for the event types defined in Section 5.3.2, and the APP- 1321 NAME value "NATLIM" MUST be used for the event types defined in 1322 Section 5.3.3. 1324 The MSGID values indicate the individual events. They are listed in 1325 Table 1 for each of the events defined in Section 3. The table also 1326 shows the SD-ID value used to label the event-specific STRUCTURED- 1327 DATA element. 1329 +-------------------------+----------+---------+----------+---------+ 1330 | Event | APP-NAME | MSGID | Severity | SD-ID | 1331 +-------------------------+----------+---------+----------+---------+ 1332 | NAT address mapping | NAT | AMADD | 6 info | namap | 1333 | creation | | | | | 1334 | NAT address mapping | NAT | AMDEL | 6 info | namap | 1335 | deletion | | | | | 1336 | NAT address and port | NAT | APMADD | 6 info | napmap | 1337 | mapping creation | | | | | 1338 | NAT address and port | NAT | APMDEL | 6 info | napmap | 1339 | mapping deletion | | | | | 1340 | NAT session creation | NAT | SADD | 6 info | nsess | 1341 | NAT session deletion | NAT | SDEL | 6 info | nsess | 1342 | Port range allocation | NAT | PTADD | 6 info | nprng | 1343 | Port range deallocation | NAT | PTDEL | 6 info | nprng | 1344 | | | | | | 1345 | Address pool high | NATTHR | POOLHT | 4 | npool | 1346 | threshold | | | warning | | 1347 | Address pool low | NATTHR | POOLLT | 6 info | npool | 1348 | threshold | | | | | 1349 | Global address mapping | NATTHR | GAMHT | 4 | ngamht | 1350 | high threshold | | | warning | | 1351 | Global address and port | NATTHR | GAPMHT | 4 | ngapmht | 1352 | mapping high threshold | | | warning | | 1353 | Subscriber-specific | NATTHR | SAPMHT | 5 notice | nsapmht | 1354 | mapping high threshold | | | | | 1355 | | | | | | 1356 | Global address mapping | NATLIM | GAMLIM | 3 error | ngaml | 1357 | limit | | | | | 1358 | Global address and port | NATLIM | GAPMLIM | 3 error | ngapml | 1359 | mapping limit | | | | | 1360 | Global active | NATLIM | GSLIM | 3 error | ngsl | 1361 | subscriber limit | | | | | 1362 | Subscriber-specific | NATLIM | SAPMLIM | 5 notice | nsapml | 1363 | address and port | | | | | 1364 | mapping limit | | | | | 1365 | Pending fragment limit | NATLIM | FRAG | 4 | nfpkt | 1366 | | | | warning | | 1367 +-------------------------+----------+---------+----------+---------+ 1369 Table 1: Recommended MSGID Encodings and Default Severity Values for 1370 the Events Defined In Section 3 1372 5.2. Parameter Encodings 1374 This section describes how to encode the individual parameters that 1375 can appear in NAT-related logs. The parameters are taken from the 1376 event descriptions in Section 3. The PARAM-NAMEs, brief 1377 descriptions, and encoding are listed in Table 2, with reference to 1378 the general and special case encoding rules which follow. 1380 +------------+-----------------------------------------+------------+ 1381 | PARAM-NAME | Description | Encoding | 1382 +------------+-----------------------------------------+------------+ 1383 | | Miscellaneous | | 1384 | | | | 1385 | NATINST | NAT instance identifier | Text | 1386 | TRIG | Trigger for event | Special | 1387 | | | case | 1388 | | | | 1389 | | Subscriber-identifying information | | 1390 | | | | 1391 | SSUBIX | Source subscriber index | 32-bit | 1392 | | | field | 1393 | SIFIX | Source subscriber ingress interface | Special | 1394 | | index list | case | 1395 | SVLAN | Source subscriber ingress VLAN index | 32-bit | 1396 | | | field | 1397 | SVPN | Source subscriber ingress VPN Id | Special | 1398 | | | case | 1399 | SV6ENC | Source subscriber ingress RFC6333 | IPv6 | 1400 | | encapsulating IPv6 address | address | 1401 | DSUBIX | Destination subscriber index | 32-bit | 1402 | | | field | 1403 | DIFIX | Destination subscriber ingress | Special | 1404 | | interface index list | case | 1405 | DVLAN | Destination subscriber ingress VLAN | 32-bit | 1406 | | index | field | 1407 | DVPN | Destination subscriber ingress VPN Id | Special | 1408 | | | case | 1409 | DV6ENC | Destination subscriber ingress RFC6333 | IPv6 | 1410 | | encapsulating IPv6 address | address | 1411 | | | | 1412 | | Internal packet description | | 1413 | | | | 1414 | IRLM | Internal realm | Text | 1415 | IATYP | Internal IP address type | "IPv4" or | 1416 | | | "IPv6" | 1417 | ISADDR | Internal source IP address value | IPv4 or | 1418 | | | IPv6 | 1419 | | | address | 1420 | ISPORT | Internal source port or ICMP identifier | 16-bit | 1421 | | value | field | 1422 | IDADDR | Internal destination IP address value | IPv4 or | 1423 | | | IPv6 | 1424 | | | address | 1425 | IDPORT | Internal destination port or ICMP | 16-bit | 1426 | | identifier value | field | 1427 | PROTO | Protocol identifier (from the IANA | 8-bit | 1428 | | Assigned Internet Protocol Numbers | field | 1429 | | registry) | | 1430 | | | | 1431 | | External (mapped) packet description | | 1432 | | | | 1433 | XRLM | External realm | Text | 1434 | XATYP | External IP address type | "IPv4" or | 1435 | | | "IPv6" | 1436 | XSADDR | External source IP address value | IPv4 or | 1437 | | | IPv6 | 1438 | | | address | 1439 | XSPORT | External source port or ICMP identifier | 16-bit | 1440 | | value | field | 1441 | XDADDR | External destination IP address value | IPv4 or | 1442 | | | IPv6 | 1443 | | | address | 1444 | XDPORT | External destination port or ICMP | 16-bit | 1445 | | identifier value | field | 1446 | | | | 1447 | | Port range description | | 1448 | | | | 1449 | PORTMN | Port range lowest value | 16-bit | 1450 | | | field | 1451 | PORTMX | Port range highest value | 16-bit | 1452 | | | field | 1453 | | | | 1454 | | Values related to thresholds | | 1455 | | | | 1456 | POOLID | Address pool identifier | 32-bit | 1457 | | | field | 1458 | POOLHW | Address pool high water mark threshold | Unsigned | 1459 | | | decimal | 1460 | POOLID | Address pool low water mark threshold | Unsigned | 1461 | | | decimal | 1462 | GAMCNT | Current global number of address | Unsigned | 1463 | | mappings | decimal | 1464 | GAPMCNT | Current global number of address and | Unsigned | 1465 | | port mappings | decimal | 1466 | SAPMCNT | Current subscriber-specific number of | Unsigned | 1467 | | address and port mappings | decimal | 1468 | | | | 1469 | | Specific incoming packet description | | 1470 | | | | 1471 | PSRLM | Packet source realm | Text | 1472 | PATYP | Packet IP address type | "IPv4" or | 1473 | | | "IPv6" | 1474 | PSADDR | Packet source IP address | IPv4 or | 1475 | | | IPv6 | 1476 | | | address | 1477 | PDADDR | Packet destination IP address | IPv4 or | 1478 | | | IPv6 | 1479 | | | address | 1480 +------------+-----------------------------------------+------------+ 1482 Table 2: Parameters Used In NAT-Related Log Reports 1484 5.2.1. General Encoding Rules 1486 All fields MUST be encoded as 7-bit US ASCII [US-ASCII]. 1488 Complete IPv6 addresses MUST be presented according to the rules 1489 specified in Sections 4 and 5 of [RFC5952], without a succeeding 1490 prefix length. The Section 5 rules MUST NOT be applied unless the 1491 address can be distinguished as having an IPv4 address embedded in 1492 the lower 32 bits solely from the IPv6 prefix portion (e.g., based on 1493 well-known prefix, flag), without external information. In such 1494 cases, the IPv6 prefix portion MUST be presented according to the 1495 Section 4 rules. Stand-alone IPv6 prefixes (i.e., outside of special 1496 addresses) MUST be presented according to the Section 4 rules, with 1497 the slash character (/) appended, followed by a decimal value with 1498 leading zeroes suppressed, giving the prefix length (0 to 127) in 1499 bits. 1501 Similarly, complete IPv4 addresses MUST be presented in dotted 1502 decimal format, with no succeeding prefix length. IPv4 prefixes MUST 1503 be presented as if they were full addresses, with the slash character 1504 (/) appended, followed by a decimal value with leading zeroes 1505 suppressed, giving the prefix length (0 to 31) in bits. 1507 N-bit fields and unsigned decimals are both presented as unsigned 1508 decimal integers with no leading zeroes. 1510 5.2.2. Special Cases 1512 Three special cases are identified in Table 2: encoding of the 1513 interface index list (PARAM-NAMEs SIFIX and DIFIX), encoding of the 1514 VPN identifier (PARAM-NAMEs SVPN and DVPN), and encoding of the 1515 trigger for resource allocation events (PARAM-NAME TRIG). 1517 The interface index list is presented as a series of individual 1518 interface indexes separated by commas, e.g., SIFIX="5,15". Each 1519 individual interface index is presented as a 32-bit field (i.e., as 1520 an unsigned decimal integer with no leading zeroes). 1522 The VPN Identifier is standardized in [RFC2685], and consists of a 1523 three octet VPN Authority (Organizationally Unique Identifier, OUI) 1524 followed by a four octet VPN index identifying the VPN according to 1525 OUI. For SYSLOG, the OUI portion is presented as a string of six 1526 hexadecimal digits in lower case. The VPN index is presented as a 1527 32-bit field. A colon (:) is used to separate the OUI from the 1528 succeeding index value. The OUI and separator MAY be omitted. If 1529 so, the applicable OUI is the default value for the NAT instance. 1531 The trigger is an enumeration of text values which were not spelled 1532 out in the table itself for lack of space. The possible values for 1533 TRIG are: 1535 "OPKT": outgoing packet received at NAT. 1537 "IPKT": incoming packet received at NAT. 1539 "ADMIN": administrative action. 1541 "APMDEL": deletion of the underlying address and port mapping. 1543 "AMDEL": deletion of the underlying address mapping. 1545 "AUTO": autonomous action of the NAT. 1547 The values applicable for any specific event are a subset of this 1548 list and are spelled out for each event in Section 5.3. 1550 5.2.3. Relationship To Objects In the NAT MIB 1552 Table 3 lists the parameters in the same order as Table 2 and relates 1553 each parameter to its corresponding object in the NAT MIB. 1555 +------------------------+------------------------------------------+ 1556 | PARAM-NAME | Related MIB Object(s) | 1557 +------------------------+------------------------------------------+ 1558 | Miscellaneous | | 1559 | | | 1560 | NATINST | natInstanceAlias in natInstanceTable | 1561 | TRIG | None | 1562 | | | 1563 | Subscriber-identifying | | 1564 | information | | 1565 | | | 1566 | SSUBIX | natSubscriberIndex in | 1567 | | natSubscribersTable | 1568 | SIFIX | natSubsInterfaceIndex in | 1569 | | natSubsInterfaceIdentifierTable | 1570 | SVLAN | natSubscriberVlanIdentifier in | 1571 | | natSubscribersTable | 1572 | SVPN | natSubscriberVpnIdentifier in | 1573 | | natSubscribersTable | 1574 | SV6ENC | natSubscriberIPEncapsIdType and | 1575 | | natSubscriberIPEncapsIdAddr in | 1576 | | natSubscribersTable | 1577 | DSUBIX | natSubscriberIndex in | 1578 | | natSubscribersTable | 1579 | DIFIX | natSubsInterfaceIndex in | 1580 | | natSubsInterfaceIdentifierTable | 1581 | DVLAN | natSubscriberVlanIdentifier in | 1582 | | natSubscribersTable | 1583 | DVPN | natSubscriberVpnIdentifier in | 1584 | | natSubscribersTable | 1585 | DV6ENC | natSubscriberIPEncapsIdType and | 1586 | | natSubscriberIPEncapsIdAddr in | 1587 | | natSubscribersTable | 1588 | | | 1589 | Internal packet | | 1590 | description | | 1591 | | | 1592 | IRLM | natSubscriberRealm in | 1593 | | natSubscribersTable | 1594 | IATYP | natMapIntAddrIntType in | 1595 | | natMapIntAddrTable or | 1596 | | natMappingIntAddressType in | 1597 | | natMappingTable | 1598 | ISADDR | natMapIntAddrInt in natMapIntAddrTable | 1599 | | or natMappingIntAddress in | 1600 | | natMappingTable | 1601 | ISPORT | natMappingIntPort in natMappingTable | 1602 | IDADDR | None | 1603 | IDPORT | None | 1604 | PROTO | natMappingProto in natMappingTable | 1605 | | | 1606 | External (mapped) | | 1607 | packet description | | 1608 | | | 1609 | XRLM | natPoolRealm in natPoolTable | 1610 | XATYP | natMapIntAddrExtType in | 1611 | | natMapIntAddrTable or | 1612 | | natMappingExtAddressType in | 1613 | | natMappingTable | 1614 | XSADDR | natMapIntAddrExt in natMapIntAddrTable | 1615 | | or natMappingExtAddress in | 1616 | | natMappingTable | 1617 | XSPORT | natMappingExtPort in natMappingTable | 1618 | XDADDR | None | 1619 | XDPORT | None | 1620 | | | 1621 | Port range description | | 1622 | | | 1623 | PORTMN | None | 1624 | PORTMX | None | 1625 | | | 1626 | Values related to | | 1627 | thresholds | | 1628 | | | 1629 | POOLID | natPoolIndex in natPoolTable | 1630 | POOLHW | natPoolWatermarkHigh in natPoolTable | 1631 | POOLLW | natPoolWatermarkLow in natPoolTable | 1632 | GAMCNT | natAddressMappingCreations - | 1633 | | natAddressMappingRemovals in | 1634 | | natCountersTable | 1635 | GAPMCNT | natMappingCreations - natMappingRemovals | 1636 | | in natCountersTable | 1637 | SAPMCNT | natSubscriberMappingCreations - | 1638 | | natSubscriberMappingRemovals in | 1639 | | natSubscribersTable | 1640 | | | 1641 | Specific incoming | | 1642 | packet description | | 1643 | | | 1644 | PSRLM | natSubscriberRealm in | 1645 | | natSubscribersTable in the case of a | 1646 | | packet originated by an identifiable | 1647 | | subscriber | 1648 | PATYP | None | 1649 | PSADDR | None | 1650 | PDADDR | None | 1651 +------------------------+------------------------------------------+ 1653 Table 3: Relationship of Parameters To Objects In the NAT MIB 1655 5.3. Encoding Of Complete Log Report For Each Event Type 1657 This section describes the complete NAT-related contents of the logs 1658 used to report the events listed in Table 1. 1660 5.3.1. Encoding of Events Relating To Allocation Of Resources To Hosts 1662 As indicated in Section 5.1, the event reports specified in this 1663 section MUST have APP-NAME="NAT" in the message header. 1665 5.3.1.1. NAT Address Mapping Creation and Deletion 1667 As shown in Table 1: 1669 o NAT address mapping creation event is indicated by MSGID set to 1670 "AMADD"; 1672 o NAT address mapping deletion event is indicated by MSGID set to 1673 "AMDEL". 1675 For both events, the associated SD-ELEMENT is tagged by SD-ID 1676 "namap". The contents of the namap SD-ELEMENT are shown in Table 4. 1677 The requirements for these contents are derived from the description 1678 in Section 3.1.1. 1680 +------------------------------------+----------------+-------------+ 1681 | Description | PARAM-NAME | Requirement | 1682 +------------------------------------+----------------+-------------+ 1683 | NAT instance identifier | NATINST | CONDITIONAL | 1684 | Source subscriber index | SSUBIX | MANDATORY | 1685 | Additional source subscriber | One of SIFIX, | CONDITIONAL | 1686 | classifier value as recognized at | SVLAN, SVPN, | | 1687 | the ingress to the internal realm | or SV6ENC | | 1688 | Internal realm | IRLM | CONDITIONAL | 1689 | Internal address type | IATYP | MANDATORY | 1690 | Internal source IP address | ISADDR | MANDATORY | 1691 | External realm | XRLM | CONDITIONAL | 1692 | External address type | XATYP | MANDATORY | 1693 | External source IP address | XSADDR | MANDATORY | 1694 | Trigger for address mapping | TRIG | OPTIONAL | 1695 | creation or deletion | | | 1696 +------------------------------------+----------------+-------------+ 1698 Table 4: Contents Of the SD-ELEMENT Section For Logging the Address 1699 Mapping Creation and Deletion Events 1701 Conditions: 1703 o NATINST REQUIRED if device supports more than one instance, else 1704 MAY appear. 1706 o One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the internal 1707 source IP address is not enough to identify the subscriber 1708 unambiguously, else MUST NOT appear. 1710 o IRLM or XRLM REQUIRED if not the default internal or external 1711 realm, respectively, else MAY appear. 1713 For the AMADD event type (MSGID), TRIG can take on the values "OPKT" 1714 or "ADMIN". For the AMDEL event type, TRIG can take on the values 1715 "ADMIN" or "AUTO". 1717 Example: DS-Lite AFTR. One NAT instance. Multiple internal IPv4 1718 realms containing the subscribers, divided by higher-level IPv6 1719 prefix (details unnecessary). One default global IPv4 external 1720 realm. Intra-subscriber sessions use mappings into this realm. 1722 Subscriber A in realm Internal05 sends an outgoing packet, causing 1723 the creation of an address mapping from the DS-Lite well-known 1724 address 192.0.0.2 to the global IPv4 address 198.51.100.127. 1725 Subscriber A's encapsulating IPv6 tunnel address is 1726 2001:db8:a5e6:39b0:bd6a:35ad:1d33:6df6. 1728 The event report for the address mapping creation is as follows (line 1729 folded into several for presentation): 1731 <142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063 1732 AMADD [namap SSUBIX="489321" 1733 SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05" 1734 IATYP="IPv4" ISADDR="192.0.0.2" XATYP="IPv4" 1735 XSADDR="198.51.100.127" 1736 TRIG="OPKT"] 1738 Character count is about 240. 1740 5.3.1.2. NAT Address and Port Mapping Creation and Deletion 1742 As shown in Table 1: 1744 o NAT address and port mapping creation event is indicated by MSGID 1745 set to "APMADD"; 1747 o NAT mapping deletion event is indicated by MSGID set to "APMDEL". 1749 For both events, the associated SD-ELEMENT is tagged by SD-ID 1750 "napmap". The contents of the nmap SD-ELEMENT are shown in Table 5. 1751 The requirements for these contents are derived from the description 1752 in Section 3.1.2. 1754 +------------------------------------+----------------+-------------+ 1755 | PARAM-NAME | Description | Requirement | 1756 +------------------------------------+----------------+-------------+ 1757 | NAT instance identifier | NATINST | CONDITIONAL | 1758 | Source subscriber index | SSUBIX | MANDATORY | 1759 | Additional source subscriber | One of SIFIX, | CONDITIONAL | 1760 | classifier value as recognized at | SVLAN, SVPN, | | 1761 | the ingress to the internal realm | or SV6ENC | | 1762 | Internal realm | IRLM | CONDITIONAL | 1763 | Internal address type | IATYP | MANDATORY | 1764 | Internal source IP address | ISADDR | MANDATORY | 1765 | Internal source port or ICMP | ISPORT | MANDATORY | 1766 | identifier | | | 1767 | External realm | XRLM | CONDITIONAL | 1768 | External address type | XATYP | MANDATORY | 1769 | External source IP address | XSADDR | MANDATORY | 1770 | External source port or ICMP | XSPORT | MANDATORY | 1771 | identifier | | | 1772 | Protocol identifier | PROTO | MANDATORY | 1773 | Trigger for address and port | TRIG | OPTIONAL | 1774 | mapping creation or deletion | | | 1775 +------------------------------------+----------------+-------------+ 1777 Table 5: Contents Of the SD-ELEMENT Section For Logging the mapping 1778 Creation and Deletion Events 1780 Conditions: 1782 o NATINST REQUIRED if device supports more than one instance, else 1783 MAY appear. 1785 o One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the internal 1786 source IP address is not enough to identify the subscriber 1787 unambiguously, else MUST NOT appear. 1789 o IRLM or XRLM REQUIRED if not the default internal or external 1790 realm, respectively, else MAY appear. 1792 For the APMADD event type (MSGID), TRIG can take on the values 1793 "OPKT", IPKT", or "ADMIN". 1795 Note: it is not clear how the internal source port is selected if 1796 an address and port mapping is triggered by an incoming TCP 1797 packet. The NAT could select one based on its knowledge of 1798 subscriber port usage, but this knowledge may be incomplete. Some 1799 type of negotiation may be necessary, or else TCP address and port 1800 mappings can only be triggered by outbound packets as in the 1801 example below. 1803 For the APMDEL event type, TRIG can take on the values "ADMIN", 1804 "AMDEL", or "AUTO". 1806 Example: The triggering outgoing packet in the previous case was a 1807 TCP packet with internal source port 49178. As well as triggering 1808 the creation of an address mapping, the packet triggers the creation 1809 of an address and port mapping between that port and an external 1810 source port 6803. The corresponding mapping creation report would 1811 look like this: 1813 <142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063 1814 APMADD [napmap SSUBIX="489321" 1815 SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05" 1816 IATYP="IPv4" ISADDR="192.0.0.2" ISPORT="49178" 1817 XATYP="IPv4" XSADDR="198.51.100.127" XSPORT=6803" 1818 PROTO="6" TRIG="OPKT"] 1820 Character count is about 280. 1822 5.3.1.3. NAT Session Creation and Deletion 1824 As shown in Table 1: 1826 o NAT session creation event is indicated by MSGID set to "SADD"; 1828 o NAT session deletion event is indicated by MSGID set to "SDEL". 1830 For both events, the associated SD-ELEMENT is tagged by SD-ID 1831 "nsess". The contents of the nsess SD-ELEMENT are shown in Table 6. 1832 The requirements for these contents are derived from the description 1833 in Section 3.1.3. 1835 +-------------------------------------+---------------+-------------+ 1836 | PARAM-NAME | Description | Requirement | 1837 +-------------------------------------+---------------+-------------+ 1838 | NAT instance identifier | NATINST | CONDITIONAL | 1839 | Source subscriber index | SSUBIX | MANDATORY | 1840 | Additional source subscriber | One of SIFIX, | CONDITIONAL | 1841 | classifier value as recognized at | SVLAN, SVPN, | | 1842 | the ingress to the internal realm | or SV6ENC | | 1843 | Internal realm | IRLM | CONDITIONAL | 1844 | Internal address type | IATYP | MANDATORY | 1845 | Internal source IP address | ISADDR | MANDATORY | 1846 | Internal source port or ICMP | ISPORT | MANDATORY | 1847 | identifier | | | 1848 | External realm | XRLM | CONDITIONAL | 1849 | External address type | XATYP | MANDATORY | 1850 | External source IP address | XSADDR | MANDATORY | 1851 | External source port or ICMP | XSPORT | MANDATORY | 1852 | identifier | | | 1853 | Protocol identifier | PROTO | MANDATORY | 1854 | Internal destination IP address | IDADDR | CONDITIONAL | 1855 | Internal destination port or ICMP | IDPORT | CONDITIONAL | 1856 | identifier | | | 1857 | Destination subscriber index | DSUBIX | CONDITIONAL | 1858 | Additional destination subscriber | One of DIFIX, | CONDITIONAL | 1859 | classifier value as recognized at | DVLAN, DVPN, | | 1860 | the ingress to the external realm | or DV6ENC | | 1861 | External destination IP address | XDADDR | CONDITIONAL | 1862 | External destination port or ICMP | XDPORT | CONDITIONAL | 1863 | identifier | | | 1864 | Trigger for session creation or | TRIG | OPTIONAL | 1865 | deletion | | | 1866 +-------------------------------------+---------------+-------------+ 1868 Table 6: Contents Of the SD-ELEMENT Section For Logging the Session 1869 Creation and Deletion Events 1871 Conditions: 1873 o NATINST REQUIRED if device supports more than one instance, else 1874 MAY appear. 1876 o One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the internal 1877 source IP address is not enough to identify the subscriber 1878 unambiguously, else MUST NOT appear. 1880 o IRLM or XRLM REQUIRED if not the default internal or external 1881 realm, respectively, else MAY appear. 1883 o IDADDR and IDPORT REQUIRED if destination logging is enabled and 1884 these need to be remapped to external destination address and 1885 port. Otherwise, if destination logging is disabled, they MUST 1886 NOT appear, and if destination logging is enabled, they SHOULD NOT 1887 appear because of redundancy. 1889 o DSUBIX REQUIRED if destination logging is enabled and the 1890 destination is a subscriber served by the NAT, else MUST NOT 1891 appear. 1893 o One of DIFIX, DVLAN, DVPN, or DV6ENC REQUIRED if destination 1894 logging is enabled and the destination is a subscriber served by 1895 the NAT and the external destination address is not enough to 1896 identify the external destination subscriber unambiguously, else 1897 MUST NOT appear. 1899 o XDADDR and XDPORT REQUIRED if destination logging is enabled, else 1900 MUST NOT appear. 1902 For the SADD event type (MSGID), TRIG can take on the values "OPKT", 1903 IPKT", or "ADMIN". For the SDEL event type, TRIG can take on the 1904 values "ADMIN", "MDEL", or "AUTO". 1906 Example: destination logging is enabled. The outgoing packet that 1907 triggered the address and port mapping in the previous section was 1908 sent to 192.0.2.57 port 80. The session creation event report 1909 appears as follows: 1911 <142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063 1912 SESSADD [nsess SSUBIX="489321" 1913 SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05" 1914 IATYP="IPv4" ISADDR="192.0.0.2" ISPORT="49178" 1915 XATYP="IPv4" XSADDR="198.51.100.127" XSPORT=6803" 1916 PROTO="6" XDADDR="192.0.2.57" XDPORT="80" TRIG="OPKT"] 1918 Character count is about 310. 1920 5.3.1.4. Port Range Allocation and Deallocation 1922 As shown in Table 1: 1924 o Port range allocation event is indicated by MSGID set to "PTADD"; 1926 o Port range deallocation event is indicated by MSGID set to 1927 "PTDEL". 1929 For both events, the associated SD-ELEMENT is tagged by SD-ID 1930 "nprng". The contents of the npset SD-ELEMENT are shown in Table 7. 1932 The requirements for these contents are derived from the description 1933 in Section 3.1.4. 1935 +------------------------------------+----------------+-------------+ 1936 | PARAM-NAME | Description | Requirement | 1937 +------------------------------------+----------------+-------------+ 1938 | NAT instance identifier | NATINST | CONDITIONAL | 1939 | Source subscriber index | SSUBIX | MANDATORY | 1940 | Additional source subscriber | One of SIFIX, | CONDITIONAL | 1941 | classifier value as recognized at | SVLAN, SVPN, | | 1942 | the ingress to the internal realm | or SV6ENC | | 1943 | Internal realm | IRLM | CONDITIONAL | 1944 | Internal address type | IATYP | MANDATORY | 1945 | Internal source IP address | ISADDR | MANDATORY | 1946 | External realm | XRLM | CONDITIONAL | 1947 | External address type | XATYP | MANDATORY | 1948 | External source IP address | XSADDR | MANDATORY | 1949 | Port range lowest value | PORTMN | MANDATORY | 1950 | Port range highest value | PORTMX | MANDATORY | 1951 | Trigger for port range allocation | TRIG | OPTIONAL | 1952 | or deallocation | | | 1953 +------------------------------------+----------------+-------------+ 1955 Table 7: Contents Of the SD-ELEMENT Section For Logging the Port Set 1956 Allocation and Deallocation Events 1958 Conditions: 1960 o NATINST REQUIRED if device supports more than one instance, else 1961 MAY appear. 1963 o One of SIFIX, SVLAN, SVPN, or SV6ENC REQUIRED if the internal 1964 source IP address is not enough to identify the subscriber 1965 unambiguously, else MUST NOT appear. 1967 o IRLM or XRLM REQUIRED if not the default internal or external 1968 realm, respectively, else MAY appear. 1970 For the PTADD event type (MSGID), TRIG can take on the values "OPKT", 1971 "IPKT", "ADMIN", or "AUTO". For the PTDEL event type, TRIG can take 1972 on the values "ADMIN" or "AUTO". 1974 Consider an example where the range 1024-1535 is allocated to the 1975 address mapping on which the example in Section 5.3.1.1 is based. 1976 The corresponding port range allocation report would look like this: 1978 <142>1 2013-05-07T22:14:15.03487Z record.example.net NAT 5063 1979 PTADD [nprng SSUBIX="489321" 1980 SV6ENC="2001:db8:a5e6:3900:bd6a:35ad:1d33:6df6" IRLM="Internal05" 1981 IATYP="IPv4" ISADDR="192.0.0.2" XATYP="IPv4" 1982 XSADDR="198.51.100.127" 1983 PORTMN="1024" PORTMX="1535" TRIG="OPKT"] 1985 Character count is about 270. 1987 5.3.2. Encoding of Threshold Events 1989 As indicated in Section 5.1, the event reports specified in this 1990 section MUST have APP-NAME="NATTHR" in the SYSLOG message header. 1992 5.3.2.1. NAT Address Pool High- and Low-Water-Mark Threshold Events 1994 As shown in Table 1: 1996 o NAT address pool high-water-mark threshold event is indicated by 1997 MSGID set to "POOLHT"; 1999 o NAT address pool low-water-mark threshold event is indicated by 2000 MSGID set to "POOLLT". 2002 For both events, the associated SD-ELEMENT is tagged by SD-ID 2003 "npool". The contents of the npool SD-ELEMENT are shown in Table 8. 2004 The requirements for these contents are derived from the description 2005 in Section 3.2.1. 2007 +------------------------------+----------------------+-------------+ 2008 | PARAM-NAME | Description | Requirement | 2009 +------------------------------+----------------------+-------------+ 2010 | NAT instance identifier | NATINST | CONDITIONAL | 2011 | Pool identifier | POOLID | MANDATORY | 2012 | The threshold value set by | POOLHW or POOLLW as | CONDITIONAL | 2013 | the administrator | applicable | | 2014 +------------------------------+----------------------+-------------+ 2016 Table 8: Contents Of the SD-ELEMENT Section For Logging the Address 2017 Pool High- and Low-Water-Mark Threshold Events 2019 Conditions: 2021 o NATINST REQUIRED if device supports more than one instance, else 2022 MAY appear. 2024 o POOLHW REQUIRED for high-water-mark event, else MUST NOT appear. 2026 o POOLLW REQUIRED for low-water-mark event, else MUST NOT appear. 2028 Example, assuming a high-water-mark threshold of 80% aggregate 2029 address-port utilization:: 2031 <132>1 2013-08-15T09:15:16.08716Z record.example.net NATTHR 5025 2032 POOLHT [npool POOLID="13" POOLHW="80"] 2034 Character count is about 105. 2036 5.3.2.2. Global Address Mapping High-Water-Mark Threshold Exceeded 2038 As shown in Table 1: 2040 o Global address mapping high-water-mark threshold event is 2041 indicated by MSGID set to "GAMHT"; and 2043 o the associated SD-ELEMENT is tagged by SD-ID "ngamht". 2045 The contents of the ngamht SD-ELEMENT are shown in Table 9. The 2046 requirements for these contents are derived from the description in 2047 Section 3.2.2. 2049 +---------------------------------------+-------------+-------------+ 2050 | PARAM-NAME | Description | Requirement | 2051 +---------------------------------------+-------------+-------------+ 2052 | NAT instance identifier | NATINST | CONDITIONAL | 2053 | Current number of active address | GAMCNT | MANDATORY | 2054 | mappings | | | 2055 +---------------------------------------+-------------+-------------+ 2057 Table 9: Contents Of the SD-ELEMENT Section For Logging the Global 2058 Address Map High-Water-Mark Threshold Event 2060 Conditions: 2062 o NATINST REQUIRED if device supports more than one instance, else 2063 MAY appear. 2065 Example, assuming a threshold was set to 690000, already exceeded. 2066 As a result, prior events of this type were detected and logged, 2067 unless they were suppressed by the sort of controls discussed in 2068 Section 6. 2070 <132>1 2013-08-15T09:15:16.08716Z record.example.net NATTHR 5025 2071 GAMHT [ngamht GAMCNT="690015"] 2073 Character count is about 95. 2075 5.3.2.3. Global Address and Port Mapping High-Water-Mark Threshold 2076 Event 2078 As shown in Table 1: 2080 o Global address and port mapping high-water-mark threshold event is 2081 indicated by MSGID set to "GAPMHT"; and 2083 o the associated SD-ELEMENT is tagged by SD-ID "ngapmht". 2085 The contents of the ngmht SD-ELEMENT are shown in Table 10. The 2086 requirements for these contents are derived from the description in 2087 Section 3.2.3. 2089 +---------------------------------------+-------------+-------------+ 2090 | PARAM-NAME | Description | Requirement | 2091 +---------------------------------------+-------------+-------------+ 2092 | NAT instance identifier | NATINST | CONDITIONAL | 2093 | Current global number of address and | GAPMCNT | MANDATORY | 2094 | port mappings | | | 2095 +---------------------------------------+-------------+-------------+ 2097 Table 10: Contents Of the SD-ELEMENT Section For Logging the Global 2098 Address and Port Mapping High-Water-Mark Threshold Event 2100 Conditions: 2102 o NATINST REQUIRED if device supports more than one instance, else 2103 MAY appear. 2105 Example: suppose the threshold was set to 2000000, so it has already 2106 been exceeded. As in the previous section, prior events of this type 2107 were detected and logged, unless they were suppressed by the sort of 2108 controls discussed in Section 6. 2110 <132>1 2013-08-15T09:15:16.08716Z record.example.net NATTHR 5025 2111 GAPMHT [ngapmht GAPMCNT="2000023"] 2113 Character count is about 100. 2115 5.3.2.4. Subscriber-Specific Address and Port Mapping High-Water-Mark 2116 Threshold Event 2118 As shown in Table 1: 2120 o Subscriber-specific address and port mapping high-water-mark 2121 threshold event is indicated by MSGID set to "SAPMHT"; and 2123 o the associated SD-ELEMENT is tagged by SD-ID "nsapmht". 2125 The contents of the nsapmht SD-ELEMENT are shown in Table 11. The 2126 requirements for these contents are derived from the description in 2127 Section 3.2.4. 2129 +---------------------------------------+-------------+-------------+ 2130 | PARAM-NAME | Description | Requirement | 2131 +---------------------------------------+-------------+-------------+ 2132 | NAT instance identifier | NATINST | CONDITIONAL | 2133 | Index of the affected subscriber | SSUBIX | MANDATORY | 2134 | Current number of address and port | SAPMCNT | MANDATORY | 2135 | mappings for this subscriber | | | 2136 +---------------------------------------+-------------+-------------+ 2138 Table 11: Contents Of the SD-ELEMENT Section For Logging the 2139 Subscriber-Specific Address and Port Mapping High-Water-Mark 2140 Threshold Event 2142 Conditions: 2144 o NATINST REQUIRED if device supports more than one instance, else 2145 MAY appear. 2147 Example: suppose the threshold was set to 1500 and the number of 2148 mappings for this subscriber has been increasing. Then this is the 2149 first threshold-exceeded event detected of what could possibly be a 2150 series of such events until subscriber consumption of outgoing ports 2151 drops below threshold again. 2153 <133>1 2013-08-15T09:15:16.08853Z record.example.net NATTHR 5025 2154 SAPMHT [nsapmht SSUBIX="489321" SAPMCNT="1501"] 2156 Character count is about 115. 2158 5.3.3. Encoding of Limit Events 2160 As indicated in Section 5.1, the event reports specified in this 2161 section MUST have APP-NAME="NATLIM" in the SYSLOG message header. 2163 5.3.3.1. Global Address Mapping Limit Exceeded 2165 As shown in Table 1: 2167 o Global address mapping limit exceeded event is indicated by MSGID 2168 set to "GAMLIM"; and 2170 o the associated SD-ELEMENT is tagged by SD-ID "ngaml". 2172 The contents of the ngaml SD-ELEMENT are shown in Table 12. The 2173 requirements for these contents are derived from the description in 2174 Section 3.3.1. 2176 +----------------------------------+-------------+-------------+ 2177 | PARAM-NAME | Description | Requirement | 2178 +----------------------------------+-------------+-------------+ 2179 | NAT instance identifier | NATINST | CONDITIONAL | 2180 | Index of the affected subscriber | SSUBIX | MANDATORY | 2181 +----------------------------------+-------------+-------------+ 2183 Table 12: Contents Of the SD-ELEMENT Section For Logging the Global 2184 Address Map Limit Exceeded Event 2186 Conditions: 2188 o NATINST REQUIRED if device supports more than one instance, else 2189 MAY appear. 2191 Example: 2193 <131>1 2013-08-15T09:15:16.08716Z record.example.net NATLIM 5025 2194 GAMLIM [ngaml NATINST="VRF-Cust-X" SSUBIX="278067"] 2196 Character count is about 115. 2198 5.3.3.2. Global Address and Port Mapping Limit Exceeded 2200 As shown in Table 1: 2202 o Global adress and port mapping limit exceeded event is indicated 2203 by MSGID set to "GAPMLIM"; and 2205 o the associated SD-ELEMENT is tagged by SD-ID "ngapml". 2207 The contents of the ngapml SD-ELEMENT are shown in Table 13. The 2208 requirements for these contents are derived from the description in 2209 Section 3.3.2. 2211 +---------------------------------------+-------------+-------------+ 2212 | PARAM-NAME | Description | Requirement | 2213 +---------------------------------------+-------------+-------------+ 2214 | NAT instance identifier | NATINST | CONDITIONAL | 2215 | Index of the internal subscriber | SSUBIX | CONDITIONAL | 2216 | Index of the external subscriber | DSUBIX | CONDITIONAL | 2217 | Source realm of the triggering packet | PSRLM | MANDATORY | 2218 | Incoming packet header IP address | PATYP | CONDITIONAL | 2219 | type | | | 2220 | Incoming packet source IP address | PSADDR | CONDITIONAL | 2221 +---------------------------------------+-------------+-------------+ 2223 Table 13: Contents Of the SD-ELEMENT Section For Logging the Global 2224 Address and Port Mapping Limit Exceeded Event 2226 Conditions: 2228 o NATINST REQUIRED if device supports more than one instance, else 2229 MAY appear. 2231 o SSUBIX REQUIRED if the mapping was triggered by a packet outgoing 2232 from the internal to the external realm, else MUST NOT appear. 2234 o DSUBIX is REQUIRED if the mapping was triggered by a packet 2235 incoming from a subscriber served by the NAT and located in the 2236 external realm (i.e., using an address mapping created previously 2237 by the internal subscriber), else MUST NOT appear. 2239 o PATYP and PSADDR from the initiating packet are REQUIRED if the 2240 mapping was triggered by a packet incoming from a purely external 2241 realm (i.e., using an address mapping created previously by the 2242 internal subscriber), else MAY appear. 2244 Example: limit event triggered by a packet coming from 192.0.2.57 in 2245 realm "externv4". 2247 <131>1 2013-08-15T09:15:16.08716Z record.example.net NATLIM 5025 2248 GAPMLIM [ngapml NATINST="VRF-Cust-X" PSRLM="externv4" 2249 PATYP="IPv4" PSADDR="192.0.2.57"] 2251 Character count is about 150. 2253 5.3.3.3. Global Limit On Number of Active Hosts Exceeded 2255 As shown in Table 1: 2257 o Global active hosts limit exceeded event is indicated by MSGID set 2258 to "GSLIM"; and 2260 o the associated SD-ELEMENT is tagged by SD-ID "ngsl". 2262 The contents of the ngsl SD-ELEMENT are shown in Table 14. The 2263 requirements for these contents are derived from the description in 2264 Section 3.3.3. 2266 +----------------------------------+-------------+-------------+ 2267 | PARAM-NAME | Description | Requirement | 2268 +----------------------------------+-------------+-------------+ 2269 | NAT instance identifier | NATINST | CONDITIONAL | 2270 | Index of the affected subscriber | SSUBIX | MANDATORY | 2271 +----------------------------------+-------------+-------------+ 2273 Table 14: Contents Of the SD-ELEMENT Section For Logging the Global 2274 Active Host Limit Exceeded Event 2276 Conditions: 2278 o NATINST REQUIRED if device supports more than one instance, else 2279 MAY appear. 2281 An example would look exactly like that in Section 5.3.3.1 with the 2282 substitution of GSLIM for GAMLIM and ngsl for ngaml. 2284 5.3.3.4. Subscriber-Specific Limit On Number of Address and Port 2285 Mappings Exceeded 2287 As shown in Table 1: 2289 o Subscriber-specific mapping limit exceeded event is indicated by 2290 MSGID set to "SMLIM"; and 2292 o the associated SD-ELEMENT is tagged by SD-ID "nsml". 2294 The contents of the nsml SD-ELEMENT are shown in Table 15. The 2295 requirements for these contents are derived from the description in 2296 Section 3.3.4. 2298 +----------------------------------+-------------+-------------+ 2299 | PARAM-NAME | Description | Requirement | 2300 +----------------------------------+-------------+-------------+ 2301 | NAT instance identifier | NATINST | CONDITIONAL | 2302 | Index of the affected subscriber | SSUBIX | MANDATORY | 2303 +----------------------------------+-------------+-------------+ 2305 Table 15: Contents Of the SD-ELEMENT Section For Logging the 2306 Subscriber-Specific Mapping Limit Exceeded Event 2308 Conditions: 2310 o NATINST REQUIRED if device supports more than one instance, else 2311 MAY appear. 2313 An example would look exactly like that in Section 5.3.3.1 with the 2314 substitution of SAPMLIM for GAMLIM and nsapml for ngaml. 2316 5.3.3.5. Pending Fragment Limit Exceeded 2318 As shown in Table 1: 2320 o Pending fragment limit exceeded event is indicated by MSGID set to 2321 "FRAG"; and 2323 o the associated SD-ELEMENT is tagged by SD-ID "nfpkt". 2325 The contents of the nfpkt SD-ELEMENT are shown in Table 16. The 2326 requirements for these contents are derived from the description in 2327 Section 3.3.5. 2329 +-------------------------------+-------------+-------------+ 2330 | PARAM-NAME | Description | Requirement | 2331 +-------------------------------+-------------+-------------+ 2332 | NAT instance identifier | NATINST | CONDITIONAL | 2333 | Source realm of the packet | PSRLM | MANDATORY | 2334 | Packet header IP address type | PATYP | MANDATORY | 2335 | Packet source IP address | PSADDR | MANDATORY | 2336 | Packet destination IP address | PDADDR | MANDATORY | 2337 | Source subscriber index | SSUBIX | CONDITIONAL | 2338 +-------------------------------+-------------+-------------+ 2340 Table 16: Contents Of the SD-ELEMENT Section For Logging the Pending 2341 Fragment Limit Exceeded Event 2343 Conditions: 2345 o NAT instance identifier REQUIRED if device supports more than one 2346 instance, else MAY appear. 2348 o Source subscriber index REQUIRED if the source of the packet is a 2349 subscriber served by the NAT and can be determined, else MUST NOT 2350 appear. 2352 Example: assuming the packet passing the limit came from an internal 2353 host and was dropped as a result of the limit. 2355 <132>1 2013-08-15T09:15:16.08Z record.example.net NATLIM 5025 2356 FRAG [nfpkt PSRLM="DsLite-089" PATYP="IPv4" PSADDR="192.0.0.2" 2357 PDADDR="203.0.113.26" SSUBIX="32791"] 2359 Character count is about 160. 2361 6. Management Considerations 2363 This section considers requirements for management of the log system 2364 to support logging of the events described above. It first covers 2365 requirements applicable to log management in general. Any additional 2366 standardization required to fulfil these requirements is out of scope 2367 of the present document. Subsequent sub-sections discuss management 2368 issues related to specific event report types. The identifiers PRI, 2369 APP-NAME, and MSGID used below refer to fields in the SYSLOG header 2370 [RFC5424] 2372 6.1. General Requirements For Control Of Logging 2374 This document assumes that any implementation provides the following 2375 capabilities, discussed in more detail below: 2377 o ability to configure the PRI value of each event report type at 2378 the granularity of (APP-NAME, MSGID) combination; 2380 o ability at each collector to determine that event reports that it 2381 should have received have been lost. The required granularity is 2382 at least at the level of PRI and may be finer for some event 2383 types. 2385 o ability to configure criteria to automatically suppress the 2386 generation of event reports while the criteria are met, at the 2387 granularity of (APP-NAME, MSGID) combination. 2389 6.1.1. Configuration of PRI Value 2391 The PRI value is composed of two numbers, the Facility value and the 2392 Severity. It may be used at the origin for selecting logs to streams 2393 being dispatched to different collectors, and in applications beyond 2394 the collectors to prioritize display of logs to operators. The event 2395 reports in this document have been structured such that the Severity 2396 level varies between event types as represented by (APP-NAME, MSGID) 2397 combination. As an extreme example, the address pool high-water-mark 2398 threshold event (APP-NAME="NATTHR", MSGID="POOLHT") is obviously more 2399 urgent than the low-water-mark threshold event (APP-NAME="NATTHR", 2400 MSGID="POOLLT"). 2402 To some extent, this document tries to simplify message routing by 2403 making a general distinction between event types recording the 2404 allocation of resources to hosts (with APP-NAME="NAT") and events of 2405 interest to operations and maintenance (with APP-NAME="NATTHR" and 2406 APP-NAME="NATLIM"). The need to provide different Severity levels 2407 for different event types remains. 2409 6.1.2. Ability For Each Collector To Detect Lost Event Reports 2411 Operators have a need to know when a given collector has not received 2412 all of the event reports it should have. It probably does not matter 2413 if less-important events are tracked at the granularity of event type 2414 (APP-NAME, MSGID combination), by APP-NAME, or just by PRI value. 2416 The event types defined in this document relating to allocation of 2417 resources to hosts are a special case. Regulatory requirements or 2418 the possibility that such reports might be introduced into court in 2419 cases such as abuse impose a requirement that the record of 2420 allocations to a particular host be complete. This requirement is 2421 important enough to be stated in the Security Considerations section 2422 (Section 7), where the implementation of signed SYSLOG messages 2423 [RFC5848], which also provides message sequencing, is mandated as 2424 part of this specification. 2426 In deploying [RFC5848], the operator needs to decide the level of 2427 granularity of tracking, whether it should be over the whole set of 2428 reports covered by APP-NAME="NAT" or at a finer level. This 2429 judgement has to be tempered by local circumstances. One point to 2430 note is that since both creations/allocations and deletions/ 2431 deallocations are recorded, a certain amount of redundancy is 2432 available in the reports being generated. However, without both the 2433 creation and deletion timestamps, there is no definitive evidence of 2434 the specific period of time during which the resources concerned were 2435 allocated to a specific host. 2437 6.1.3. Ability To Rate Limit Or Disable Event Reports 2439 The event report types specified with APP-NAME="NATTHR" and APP- 2440 NAME="NATLIM" all relate to thresholds or limits. By their nature, 2441 events of this sort will come in bursts. The threshold or limit will 2442 be hit, the resource concerned will remain busy for a period, then 2443 pressure on the resource will ease. Depending on the resource, 2444 possibly hundreds of instances of the event concerned will be 2445 detected during a single busy period. 2447 Where repeated events involve the same resource, it makes little 2448 sense to report all of them, since the NAT MIB counters provide the 2449 necessary information more succinctly. On the other hand, it can be 2450 useful to know that the fragmentation limit, for instance, is being 2451 hit by successive packets from the same source address. 2453 As a result of these considerations, this document requires that 2454 implementations MUST provide means to configure limits on the rate at 2455 which event reports of a given type (APP-NAME, MSGID combination) are 2456 generated. It is RECOMMENDED that it be possible to specify two 2457 values per (APP-NAME, MSGID) combination: 2459 o minimum time between initial instances of a given event report 2460 type; 2462 o maximum number of instances of the event report to generate per 2463 busy period. 2465 Regardless of the detailed method the implementation provides for 2466 specifying the rate limiting of individual event report types, all 2467 implementations MUST allow the operator to indicate through 2468 configuration that a given event report type is to be completely 2469 disabled. This is particularly required to disable logging of either 2470 session or mapping creations and deletions when not required (see 2471 discussion in Section 3.1.2). It is also required when the operator 2472 prefers to receive threshold event notifications via SNMP rather than 2473 SYSLOG. 2475 The ability to rate limit or disable event reports MUST NOT interfere 2476 with the requirement to detect lost messages. This has implications 2477 for any sequence numbering used for that purpose. It is RECOMMENDED 2478 in any event that the implementation provide MIB counters of numbers 2479 of messages not generated due to rate limiting by event type 2480 supported. If this is done, counters for disabled event report types 2481 SHOULD NOT be incremented, since that could require keeping 2482 unnecessary additional state. 2484 6.2. Setting Limits and Thresholds 2486 The "NATTHR" and "NATLIM" events specified in this document depend on 2487 the thresholds and limits configured in the NAT MIB 2488 [I-D.behave-NAT-MIB]. The limits have to do with policy in some 2489 cases (e.g., most especially the subscriber-specific limits), but 2490 generally depend on the implementation and the device in which it is 2491 deployed. 2493 The purpose of high-water-mark thresholds is, of course, to give 2494 sufficient advance warning that utilization of a particular resource 2495 is approaching its limit, so that appropriate provisioning or 2496 reconfiguration action can be undertaken to preserve target service 2497 levels on the NAT device. Thus the following general principles 2498 apply: 2500 o A high-water-mark threshold should be derived as a percentage of 2501 the relevant limit. 2503 o The more quickly that utilization of a given resource can build 2504 up, the lower the threshold must be to provide an adequate 2505 response time. 2507 o Some limits are more important than others in terms of their 2508 effect on overall service levels provided by the NAT device. To 2509 focus attention on the more important limits, their corresponding 2510 thresholds should be set lower than those for less-important 2511 limits, all other things being equal. 2513 In practice, thresholds will require tuning to fit the particular 2514 characteristics of the NAT device and its users. 2516 The setting of the high-water-mark-thresholds for address pools 2517 (Section 3.2.1) poses additional challenges. The problem is that the 2518 bottleneck for port availability will generally be a single protocol, 2519 which may vary from one time to another. However, the threshold is 2520 based on overall port utilization. If port usage is such that one 2521 protocol generally predominates, the required threshold value has to 2522 be lower than if usage is more balanced between protocols. Clearly 2523 the appropriate threshold value depends on the characteristics of the 2524 traffic handled by the particular address pool concerned. 2526 Pooling behaviour adds another factor for consideration. With a 2527 pooling behaviour of "arbitrary" [RFC4787], port utilization for the 2528 bottleneck protocol can be quite high before service levels offered 2529 by the pool are in danger. On the other hand, with a pooling 2530 behaviour of "paired", possible utilization levels will be much lower 2531 because typically a number of port values will be reserved to each 2532 address mapping and only some of those will be in use on the average. 2533 The difference between "arbitrary" and "paired" utilization for a 2534 given level of service may be quite dramatic. 2536 6.3. Other Management Requirements 2538 The identification of internal realms is contingent on the the 2539 existence and applicability of default internal and external realms. 2540 If the implementation is capable of supporting more than one internal 2541 or external realm, it MUST provide the means for the operator to 2542 specify which realm is the default internal and/or external realm, as 2543 the case may be. 2545 7. Security Considerations 2547 When logs are being recorded for regulatory reasons or as potential 2548 evidence in abuse cases, preservation of their integrity and 2549 authentication of their origin is essential. To achieve this result, 2550 signed SYSLOG messages [RFC5848] MUST be implemented as part of this 2551 specification. It is RECOMMENDED that the operator deploy [RFC5848] 2552 where local requirements on integrity and authentication of origin 2553 are stringent. In conjunction with [RFC5848] and as recommended in 2554 Section 3 of that document, TLS transport as specified in [RFC5425] 2555 SHOULD be used between the origin and the collector(s) and MUST be 2556 implemented. Section 5.2.1 of [RFC5848] specifies the minimum 2557 support for Key Blob Type that must be provided by implementations of 2558 that specification. 2560 Access to the logs defined in Section 3.1 and Section 5.3.1 while the 2561 reported assignments are in force could improve an attacker's chance 2562 of hijacking a session through port-guessing. Even after an 2563 assignment has expired, the information in the logs SHOULD be treated 2564 as confidential, since, if revealed, it could help an attacker trace 2565 sessions back to a particular user or user location. It is therefore 2566 RECOMMENDED that these logs be transported securely, using [RFC5425], 2567 for example, even if [RFC5848] is not deployed, that they be stored 2568 securely at the collector, and that access to them at the collector 2569 and in applications be tightly controlled. 2571 The logs defined in Section 3.2 and Section 3.3 are less sensitive in 2572 general, but since many of them contain the subscriber identifier, 2573 they could be used to get some sense of subscriber activity. The 2574 fragmentation limit event provides actual packet header contents. 2575 Operators SHOULD at the least deploy secure transport to ensure that 2576 this information is not misused. 2578 8. IANA Considerations 2580 This document requests IANA to make the following assignments to the 2581 SYSLOG Structured Data ID Values registry. RFCxxxx refers to the 2582 present document when approved. 2584 Some PARAM-NAMES appear under more than one SD-ID in Table 17. 2585 Formally, a parameter used with more than one event is registered as 2586 multiple separate parameters, one for each event report in which it 2587 is used. However, there is no reason to change either the PARAM-NAME 2588 or the encoding of the PARAM-VALUE between different instances of the 2589 same parameter if the parameters have the same meaning in both event 2590 reports. 2592 While a number of parameters are marked CONDITIONAL in the body of 2593 this document, the SYSLOG registry provides only for MANDATORY and 2594 OPTIONAL parameters. All CONDITIONAL parameters have been placed in 2595 the OPTIONAL category in Table 17. 2597 +----------------+--------------------+-----------------+-----------+ 2598 | Structured | Structured Data | Required or | Reference | 2599 | Data ID | Parameter | Optional | | 2600 +----------------+--------------------+-----------------+-----------+ 2601 | namap | | OPTIONAL | RFCxxxx | 2602 | | NATINST | OPTIONAL | RFCxxxx | 2603 | | SSUBIX | MANDATORY | RFCxxxx | 2604 | | SIFIX | OPTIONAL | RFCxxxx | 2605 | | SVLAN | OPTIONAL | RFCxxxx | 2606 | | SVPN | OPTIONAL | RFCxxxx | 2607 | | SV6ENC | OPTIONAL | RFCxxxx | 2608 | | IRLM | OPTIONAL | RFCxxxx | 2609 | | IATYP | MANDATORY | RFCxxxx | 2610 | | ISADDR | MANDATORY | RFCxxxx | 2611 | | XRLM | OPTIONAL | RFCxxxx | 2612 | | XATYP | MANDATORY | RFCxxxx | 2613 | | XSADDR | MANDATORY | RFCxxxx | 2614 | | TRIG | OPTIONAL | RFCxxxx | 2615 | ---- | ---- | ---- | ---- | 2616 | napmap | | OPTIONAL | RFCxxxx | 2617 | | NATINST | OPTIONAL | RFCxxxx | 2618 | | SSUBIX | MANDATORY | RFCxxxx | 2619 | | SIFIX | OPTIONAL | RFCxxxx | 2620 | | SVLAN | OPTIONAL | RFCxxxx | 2621 | | SVPN | OPTIONAL | RFCxxxx | 2622 | | SV6ENC | OPTIONAL | RFCxxxx | 2623 | | IRLM | OPTIONAL | RFCxxxx | 2624 | | IATYP | MANDATORY | RFCxxxx | 2625 | | ISADDR | MANDATORY | RFCxxxx | 2626 | | ISPORT | MANDATORY | RFCxxxx | 2627 | | XRLM | OPTIONAL | RFCxxxx | 2628 | | XATYP | MANDATORY | RFCxxxx | 2629 | | XSADDR | MANDATORY | RFCxxxx | 2630 | | XSPORT | MANDATORY | RFCxxxx | 2631 | | PROTO | MANDATORY | RFCxxxx | 2632 | | TRIG | OPTIONAL | RFCxxxx | 2633 | ---- | ---- | ---- | ---- | 2634 | nsess | | OPTIONAL | RFCxxxx | 2635 | | NATINST | OPTIONAL | RFCxxxx | 2636 | | SSUBIX | MANDATORY | RFCxxxx | 2637 | | SIFIX | OPTIONAL | RFCxxxx | 2638 | | SVLAN | OPTIONAL | RFCxxxx | 2639 | | SVPN | OPTIONAL | RFCxxxx | 2640 | | SV6ENC | OPTIONAL | RFCxxxx | 2641 | | IRLM | OPTIONAL | RFCxxxx | 2642 | | IATYP | MANDATORY | RFCxxxx | 2643 | | ISADDR | MANDATORY | RFCxxxx | 2644 | | ISPORT | MANDATORY | RFCxxxx | 2645 | | XRLM | OPTIONAL | RFCxxxx | 2646 | | XATYP | MANDATORY | RFCxxxx | 2647 | | XSADDR | MANDATORY | RFCxxxx | 2648 | | XSPORT | MANDATORY | RFCxxxx | 2649 | | PROTO | MANDATORY | RFCxxxx | 2650 | | IDADDR | OPTIONAL | RFCxxxx | 2651 | | IDPORT | OPTIONAL | RFCxxxx | 2652 | | DSUBIX | OPTIONAL | RFCxxxx | 2653 | | DIFIX | OPTIONAL | RFCxxxx | 2654 | | DVLAN | OPTIONAL | RFCxxxx | 2655 | | DVPN | OPTIONAL | RFCxxxx | 2656 | | DV6ENC | OPTIONAL | RFCxxxx | 2657 | | XDADDR | OPTIONAL | RFCxxxx | 2658 | | XDPORT | OPTIONAL | RFCxxxx | 2659 | | TRIG | OPTIONAL | RFCxxxx | 2660 | ---- | ---- | ---- | ---- | 2661 | nprng | | OPTIONAL | RFCxxxx | 2662 | | NATINST | OPTIONAL | RFCxxxx | 2663 | | SSUBIX | MANDATORY | RFCxxxx | 2664 | | SIFIX | OPTIONAL | RFCxxxx | 2665 | | SVLAN | OPTIONAL | RFCxxxx | 2666 | | SVPN | OPTIONAL | RFCxxxx | 2667 | | SV6ENC | OPTIONAL | RFCxxxx | 2668 | | IRLM | OPTIONAL | RFCxxxx | 2669 | | IATYP | MANDATORY | RFCxxxx | 2670 | | ISADDR | MANDATORY | RFCxxxx | 2671 | | XRLM | OPTIONAL | RFCxxxx | 2672 | | XATYP | MANDATORY | RFCxxxx | 2673 | | XSADDR | MANDATORY | RFCxxxx | 2674 | | PORTMN | MANDATORY | RFCxxxx | 2675 | | PORTMX | MANDATORY | RFCxxxx | 2676 | | TRIG | OPTIONAL | RFCxxxx | 2677 | ---- | ---- | ---- | ---- | 2678 | npool | | OPTIONAL | RFCxxxx | 2679 | | NATINST | OPTIONAL | RFCxxxx | 2680 | | POOLID | MANDATORY | RFCxxxx | 2681 | | POOLLT | OPTIONAL | RFCxxxx | 2682 | | POOLHT | OPTIONAL | RFCxxxx | 2683 | ---- | ---- | ---- | ---- | 2684 | ngamht | | OPTIONAL | RFCxxxx | 2685 | | NATINST | OPTIONAL | RFCxxxx | 2686 | | GAMCNT | MANDATORY | RFCxxxx | 2687 | ---- | ---- | ---- | ---- | 2688 | ngapmht | | OPTIONAL | RFCxxxx | 2689 | | NATINST | OPTIONAL | RFCxxxx | 2690 | | GAPMCNT | MANDATORY | RFCxxxx | 2691 | ---- | ---- | ---- | ---- | 2692 | nsapmht | | OPTIONAL | RFCxxxx | 2693 | | NATINST | OPTIONAL | RFCxxxx | 2694 | | SSUBIX | MANDATORY | RFCxxxx | 2695 | | SAPMCNT | MANDATORY | RFCxxxx | 2696 | ---- | ---- | ---- | ---- | 2697 | ngaml | | OPTIONAL | RFCxxxx | 2698 | | NATINST | OPTIONAL | RFCxxxx | 2699 | | SSUBIX | MANDATORY | RFCxxxx | 2700 | ---- | ---- | ---- | ---- | 2701 | ngapml | | OPTIONAL | RFCxxxx | 2702 | | NATINST | OPTIONAL | RFCxxxx | 2703 | | SSUBIX | OPTIONAL | RFCxxxx | 2704 | | DSUBIX | OPTIONAL | RFCxxxx | 2705 | | PSRLM | MANDATORY | RFCxxxx | 2706 | | PATYP | OPTIONAL | RFCxxxx | 2707 | | PSADDR | OPTIONAL | RFCxxxx | 2708 | ---- | ---- | ---- | ---- | 2709 | ngsl | | OPTIONAL | RFCxxxx | 2710 | | NATINST | OPTIONAL | RFCxxxx | 2711 | | SSUBIX | MANDATORY | RFCxxxx | 2712 | ---- | ---- | ---- | ---- | 2713 | nsapml | | OPTIONAL | RFCxxxx | 2714 | | NATINST | OPTIONAL | RFCxxxx | 2715 | | SSUBIX | MANDATORY | RFCxxxx | 2716 | ---- | ---- | ---- | ---- | 2717 | nfpkt | | OPTIONAL | RFCxxxx | 2718 | | NATINST | OPTIONAL | RFCxxxx | 2719 | | PSRLM | MANDATORY | RFCxxxx | 2720 | | PATYP | MANDATORY | RFCxxxx | 2721 | | PSADDR | MANDATORY | RFCxxxx | 2722 | | PDADDR | MANDATORY | RFCxxxx | 2723 | | SSUBIX | OPTIONAL | RFCxxxx | 2724 +----------------+--------------------+-----------------+-----------+ 2726 Table 17: NAT-Related STRUCTURED-DATA Registrations 2728 9. References 2730 9.1. Normative References 2732 [I-D.behave-NAT-MIB] 2733 Perreault, S., Tsou, T., and S. Sivakumar, "Additional 2734 Managed Objects for Network Address Translators (NAT) 2735 (Work in progress)", September 2013. 2737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2738 Requirement Levels", BCP 14, RFC 2119, March 1997. 2740 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2741 Translator (NAT) Terminology and Considerations", RFC 2742 2663, August 1999. 2744 [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks 2745 Identifier", RFC 2685, September 1999. 2747 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 2748 MIB", RFC 2863, June 2000. 2750 [RFC4265] Schliesser, B. and T. Nadeau, "Definition of Textual 2751 Conventions for Virtual Private Network (VPN) Management", 2752 RFC 4265, November 2005. 2754 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed 2755 Objects for Bridges with Traffic Classes, Multicast 2756 Filtering, and Virtual LAN Extensions", RFC 4363, January 2757 2006. 2759 [RFC4784] Carroll, C. and F. Quick, "Verizon Wireless Dynamic Mobile 2760 IP Key Update for cdma2000(R) Networks", RFC 4784, June 2761 2007. 2763 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2764 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2765 RFC 4787, January 2007. 2767 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 2769 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 2770 Security (TLS) Transport Mapping for Syslog", RFC 5425, 2771 March 2009. 2773 [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog 2774 Messages", RFC 5848, May 2010. 2776 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2777 Address Text Representation", RFC 5952, August 2010. 2779 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 2780 Algorithm", RFC 6145, April 2011. 2782 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2783 NAT64: Network Address and Protocol Translation from IPv6 2784 Clients to IPv4 Servers", RFC 6146, April 2011. 2786 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2787 Stack Lite Broadband Deployments Following IPv4 2788 Exhaustion", RFC 6333, August 2011. 2790 [US-ASCII] 2791 American National Standards Institute, , "Coded Character 2792 Set -- 7-bit American Standard Code for Information 2793 Interchange", ANSI X3.4, 1986. 2795 9.2. Informative References 2797 [I-D.behave-ipfix-nat-logging] 2798 Sivakumar, S. and R. Penno, "IPFIX Information Elements 2799 for logging NAT Events (Work in progress)", August 2013. 2801 [I-D.pcp-port-set] 2802 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 2803 and S. Perreault, "Port Control Protocol (PCP) Extension 2804 for Port Set Allocation (Work in progress)", July 2013. 2806 [I-D.softwire-lw4over6] 2807 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 2808 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 2809 Architecture (Work in progress)", July 2013. 2811 [I-D.softwire-map] 2812 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 2813 Murakami, T., and T. Taylor, "Mapping of Address and Port 2814 with Encapsulation (MAP) (Work in progress)", August 2013. 2816 [I-D.tsou-behave-natx4-log-reduction] 2817 Tsou, T., Li, W., and T. Taylor, "Port Management To 2818 Reduce Logging In Large-Scale NATs (Work in progress)", 2819 July 2013. 2821 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2822 Address Translator (Traditional NAT)", RFC 3022, January 2823 2001. 2825 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 2826 Private Network (VPN) Terminology", RFC 4026, March 2005. 2828 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 2829 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 2830 RFC 5382, October 2008. 2832 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 2833 Infrastructures (6rd) -- Protocol Specification", RFC 2834 5969, August 2010. 2836 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 2837 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 2838 June 2011. 2840 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 2841 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 2842 July 2012. 2844 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 2845 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2846 2013. 2848 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 2849 and H. Ashida, "Common Requirements for Carrier-Grade NATs 2850 (CGNs)", BCP 127, RFC 6888, April 2013. 2852 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 2853 the IP Flow Information Export (IPFIX) Protocol for the 2854 Exchange of Flow Information", STD 77, RFC 7011, September 2855 2013. 2857 [RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 2858 IPv4-over-IPv6 Access Network", RFC 7040, November 2013. 2860 Authors' Addresses 2862 Zhonghua Chen 2863 China Telecom 2864 P.R. China 2866 Email: 18918588897@189.cn 2868 Cathy Zhou 2869 Huawei Technologies 2870 Bantian, Longgang District 2871 Shenzhen 518129 2872 P.R. China 2874 Email: cathy.zhou@huawei.com 2875 Tina Tsou 2876 Huawei Technologies 2877 Bantian, Longgang District 2878 Shenzhen 518129 2879 P.R. China 2881 Email: tina.tsou.zouting@huawei.com 2883 T. Taylor (editor) 2884 Huawei Technologies 2885 Ottawa 2886 Canada 2888 Email: tom.taylor.stds@gmail.com