idnits 2.17.1 draft-zhou-behave-syslog-nat-logging-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2012) is 4243 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: 'I-D.PCP-Base' is mentioned on line 170, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track C. Zhou 5 Expires: March 10, 2013 Huawei Technologies 6 T. Tsou 7 Huawei Technologies (USA) 8 T. Taylor 9 Huawei Technologies 10 September 6, 2012 12 Syslog Format for NAT Logging 13 draft-zhou-behave-syslog-nat-logging-01 15 Abstract 17 Under some circumstances operators will need to maintain a dynamic 18 record of external address and port assignments made by a Carrier 19 Grade NAT (CGN), and will find it feasible and convenient to create 20 such records using SYSLOG (RFC 5424). The present document 21 standardizes a SYSLOG format to meet that recording requirement. It 22 specifies a number of fields that could be a part of the log report, 23 leaving it up to operators to select the fields needed for their 24 specific circumstances. 26 [*** Subject to discussion*** The log format presented here may also 27 be used by PCP server implementations to log the mappings they 28 implement.] 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 10, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. SYSLOG Record Format For NAT Logging . . . . . . . . . . . . . 4 66 2.1. SYSLOG HEADER Fields . . . . . . . . . . . . . . . . . . . 4 67 2.2. STRUCTURED-DATA Fields . . . . . . . . . . . . . . . . . . 5 68 2.2.1. Incoming IP Source Address Parameter . . . . . . . . . 5 69 2.2.2. Outgoing IP Source Address Parameter . . . . . . . . . 5 70 2.2.3. Incoming Source Port Parameter . . . . . . . . . . . . 5 71 2.2.4. Outgoing Source Port Parameter . . . . . . . . . . . . 5 72 2.2.5. Number of Port Numbers Parameter . . . . . . . . . . . 5 73 2.2.6. Highest Outgoing Port Number Parameter . . . . . . . . 5 74 2.2.7. Protocol Parameter . . . . . . . . . . . . . . . . . . 6 75 2.2.8. Subscriber Identifier Parameter . . . . . . . . . . . . 6 76 2.2.9. NAT Identifier Parameter . . . . . . . . . . . . . . . 6 77 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 79 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Operators already need to record the addresses assigned to 85 subscribers at any point in time, for operational and regulatory 86 reasons. When operators introduce Carrier Grade NATs (CGNs) into 87 their network, both addresses and ports on the external side of the 88 CGN are shared amongst subscribers. To trace back from an external 89 address and port observed at a given point in time to a specific 90 subscriber requires additional information: a record of which 91 subscriber was assigned that address and port by the NAT. 93 Address-port assignment strategies present a tradeoff between the 94 efficiency with which available external addresses are used, the cost 95 of maintaining a trace back capability, and the need to make port 96 assignments unpredictable to counter the threat of session hijacking. 97 At one extreme, the operator could make a one-time assignment of an 98 external address and a set of ports to each subscriber. Traceback 99 would then be a matter of retrieving configuration information from 100 the NAT. Even in this situation, it is possible that a request for 101 legal interception is placed against a specific subscriber, such that 102 each session involving that subscriber is recorded. 104 At the opposite extreme, a carrier could assign external addresses 105 and ports to subscribers on demand, in totally random fashion. Such 106 a strategy is not really practical, both because of the volume of 107 records that would be required to support a traceback capability, and 108 because the apparent gain in efficiency with which address-port 109 combinations would be utilized would be attenuated by the need to 110 leave address-port assignments idle for some minimum amount of time 111 after last observed use to make sure they weren't still being used. 113 Between these extremes, operators may choose to assign specific 114 addresses and specific blocks of ports to subscribers when they log 115 on to the network, releasing the assignments when they drop off. 116 Such a strategy could be desirable in networks with mobile 117 subscribers, in particular. Compared with the fully dynamic 118 strategy, this strategy reduces the number of times that assignments 119 have to be recorded by orders of magnitude. 121 The point just made is that under some circumstances operators need 122 to record allocations of external address-port combinations in the 123 NAT dynamically, and the volume of information contained in those 124 records is manageable. Various means are available to create such 125 records. This document assumes that for some operators, the most 126 convenient mechanism to do so will be event logging using SYSLOG 127 [RFC5424], where the SYSLOG records are generated either by the NAT 128 itself or by an off-line device. 130 The next section specifies a SYSLOG record format for logging of NAT 131 address and port assignments and the format of fields that could be 132 used within such a record. It is up to individual operators to 133 choose the fields that match their specific operating procedures. 135 1.1. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in "Key words for use in 140 RFCs to Indicate Requirement Levels" [RFC2119]. 142 2. SYSLOG Record Format For NAT Logging 144 This section describes the SYSLOG record format for NAT logging in 145 terms of the field names used in [RFC5424] and specified in Section 6 146 of that document. In particular, this section specifies values for 147 the APP-NAME and MSGID fields in the record header, the SD-ID 148 identifying the STRUCTURED-DATA section, and the PARAM-NAMEs and 149 PARAM-VALUE types for the individual possible parameters within that 150 section. 152 2.1. SYSLOG HEADER Fields 154 Within the HEADER portion of the SYSLOG record, the priority (PRI) 155 level is subject to local policy, but a default value of 86 is 156 suggested, representing a Facility value of 10 (security/ 157 authorization) and a Severity level of 6 (informational). Depending 158 on where the SYSLOG record is generated, the HOSTNAME field may 159 identify the NAT or an offline logging device. In the latter case, 160 it may be desirable to identify the NAT using the NID field in the 161 STRUCTURED-DATA section (see below). The value of the HOSTNAME field 162 is subject to the preferences given in Section 6.2.4 of [RFC5424]. 164 The values of the APP-NAME and MSGID fields in the record header 165 determine the semantics of the record. The RECOMMENDED APP-NAME 166 value "NAT" indicates that the record relates to an assignment made 167 autonomously by the NAT itself. [*** Subject to discussion*** The 168 RECOMMENDED APP-NAME "PCP" indicates that the assignment to which the 169 record refers was the result of a Port Control Protocol (PCP) 170 [I-D.PCP-Base] command.] The RECOMMENDED MSGID value "ADD" indicates 171 that the assignment took effect at the time indicated by the record 172 timestamp. The RECOMMENDED MSGID value "DEL" indicates that the 173 assignment was deleted at the time indicated by the record timestamp. 175 2.2. STRUCTURED-DATA Fields 177 This document specifies a value of "asgn" (short for "assignment") 178 for the SD-ID field identifying the STRUCTURED-DATA section of the 179 record. In addition it specifies the following parameters for use 180 within that section. All of these parameters are OPTIONAL. All 181 values that are IP addresses are written as a text string in dotted- 182 decimal form (IPv4) or as recommended by [RFC5952] (IPv6). 184 2.2.1. Incoming IP Source Address Parameter 186 PARAM-NAME: iSA. PARAM-VALUE: the incoming IP source address of the 187 packet(s) to which the assignment described by this record applies. 189 2.2.2. Outgoing IP Source Address Parameter 191 PARAM-NAME: oSA. PARAM-VALUE: the outgoing IP source address of the 192 packet(s) to the assignment described by which this record applies. 194 2.2.3. Incoming Source Port Parameter 196 PARAM-NAME: iSP. PARAM-VALUE: the incoming IP source port of the 197 packet(s) to the assignment described by which this record applies. 199 2.2.4. Outgoing Source Port Parameter 201 PARAM-NAME: oSP. PARAM-VALUE: the outgoing IP source port of the 202 packet(s) to which the assignment described by this record applies. 203 If the record pertains to the assignment of a range of ports, this 204 parameter gives the lowest port number in the range. In the case of 205 a range, either parameter oSPct or parameter oSPmx SHOULD also be 206 present in the log record. 208 2.2.5. Number of Port Numbers Parameter 210 PARAM-NAME: oSPct. PARAM-VALUE: used when the record pertains to the 211 assignment of a range of ports (either consecutive or generated by a 212 known algorithm). This parameter gives the number of port numbers in 213 the range. 215 2.2.6. Highest Outgoing Port Number Parameter 217 PARAM-NAME: oSPmx. PARAM-VALUE: used when the record pertains to the 218 assignment of a range of ports (either consecutive or generated by a 219 known algorithm). This parameter gives the highest port number in 220 the range. 222 2.2.7. Protocol Parameter 224 PARAM-NAME: Pr. PARAM-VALUE: an integer indicating the value of the 225 Protocol header field (IPv4) or Next Header field (IPv6) in the 226 incoming packet(s) to which the assignment described by this record 227 applies. 229 2.2.8. Subscriber Identifier Parameter 231 PARAM-NAME: SID. PARAM-VALUE: an arbitrary UTF-8 string identifying 232 the subscriber to which this assignment applies. This is intended to 233 provide flexibility when the incoming source address will not be 234 unique. The value could be a tunnel identifier, layer 2 address, or 235 any other value that is convenient to the operator and associated 236 with incoming packets. 238 2.2.9. NAT Identifier Parameter 240 PARAM-NAME: NID. PARAM-VALUE: an arbitrary UTF-8 string identifying 241 the NAT making the assignment to which this record applies. Needed 242 only if the necessary identification is not provided by the HOSTNAME 243 parameter in the log record header. 245 3. IANA Considerations 247 This document requests IANA to make the following assignments to the 248 SYSLOG Structured Data ID Values registry. RFCxxxx refers to the 249 present document when approved. 251 +----------------+--------------------+-----------------+-----------+ 252 | Structured | Structured Data | Required or | Reference | 253 | Data ID | Parameter | Optional | | 254 +----------------+--------------------+-----------------+-----------+ 255 | asgn | | OPTIONAL | RFCxxxx | 256 | | iSA | OPTIONAL | RFCxxxx | 257 | | oSA | OPTIONAL | RFCxxxx | 258 | | iSP | OPTIONAL | RFCxxxx | 259 | | oSP | OPTIONAL | RFCxxxx | 260 | | oSPct | OPTIONAL | RFCxxxx | 261 | | oSPmx | OPTIONAL | RFCxxxx | 262 | | Pr | OPTIONAL | RFCxxxx | 263 | | SID | OPTIONAL | RFCxxxx | 264 | | NID | OPTIONAL | RFCxxxx | 265 +----------------+--------------------+-----------------+-----------+ 267 Table 1 269 4. Security Considerations 271 When logs are being recorded for regulatory reasons, preservation of 272 their integrity and authentication of their origin is essential. To 273 achieve this result, it is RECOMMENDED that the operator deploy 274 [RFC5848]. 276 Access to the logs defined here while the reported assignments are in 277 force could improve an attacker's chance of hijacking a session 278 through port-guessing. Even after an assignment has expired, the 279 information in the logs SHOULD be treated as confidential, since, if 280 revealed, it could help an attacker trace sessions back to a 281 particular subscriber or subscriber location. It is therefore 282 RECOMMENDED that these logs be transported securely, using [RFC5425], 283 for example, and that they be stored securely at the collector. 285 5. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 292 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 293 Security (TLS) Transport Mapping for Syslog", RFC 5425, 294 March 2009. 296 [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog 297 Messages", RFC 5848, May 2010. 299 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 300 Address Text Representation", RFC 5952, August 2010. 302 Authors' Addresses 304 Zhonghua Chen 305 China Telecom 306 P.R. China 308 Phone: 309 Email: 18918588897@189.cn 310 Cathy Zhou 311 Huawei Technologies 312 Bantian, Longgang District 313 Shenzhen 518129 314 P.R. China 316 Phone: 317 Email: cathy.zhou@huawei.com 319 Tina Tsou 320 Huawei Technologies (USA) 321 2330 Central Expressway 322 Santa Clara, CA 95050 323 USA 325 Phone: +1 408 330 4424 326 Email: tina.tsou.zouting@huawei.com 328 T. Taylor 329 Huawei Technologies 330 Ottawa, 331 Canada 333 Phone: 334 Email: tom.taylor.stds@gmail.com