idnits 2.17.1 draft-daveor-cgn-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 : ---------------------------------------------------------------------------- == There are 2 instances 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 (October 19, 2017) is 2378 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 D. O'Reilly 3 Internet-Draft October 19, 2017 4 Intended status: Informational 5 Expires: April 22, 2018 7 Approaches to Address the Availability of Information in Criminal 8 Investigations Involving Large-Scale IP Address Sharing Technologies 9 draft-daveor-cgn-logging-01 11 Abstract 13 The use of large-scale IP address sharing technologies (commonly 14 known as "Carrier-Grade NAT" and "A+P") presents a challenge for law 15 enforcement agencies due to the fact that incoming source port 16 information is not routinely logged by Internet-facing servers. The 17 absence of this information means that it is becoming increasingly 18 difficult for law enforcement agencies to identify suspects in 19 criminal activity online. This document considers the reasons why 20 source port information is not routinely logged by Internet-facing 21 servers and proposes some immediate-term actions that can be taken to 22 help improve the situation. A deployment maturity model has been 23 developed and a study of the support for logging incoming source port 24 information in common server software is also presented. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 22, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Centralised Connection Logging . . . . . . . . . . . . . . . 5 63 4. Challenges to Capturing Source Port . . . . . . . . . . . . . 7 64 4.1. Lack of Awareness . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Lack of Support for Logging Source Port . . . . . . . . . 8 66 4.3. Additional Storage Requirements . . . . . . . . . . . . . 8 67 4.4. Default Log Formats . . . . . . . . . . . . . . . . . . . 8 68 4.5. Breaking Existing Tooling . . . . . . . . . . . . . . . . 8 69 4.6. Accuracy of Recorded Time . . . . . . . . . . . . . . . . 9 70 5. Comparison Model . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Support for Logging Source Port . . . . . . . . . . . . . . . 10 72 7. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 11 73 7.1. Raise Awareness of the Importance of Logging Source Port 11 74 7.2. Increase Support for Logging Source Port . . . . . . . . 12 75 7.3. Update Default Log Formats . . . . . . . . . . . . . . . 12 76 7.4. Parallel Logging to a Connection Log . . . . . . . . . . 12 77 7.5. Adequate Timestamp Accuracy in Logs . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Informative References . . . . . . . . . . . . . . . . . 13 82 10.2. Normative References . . . . . . . . . . . . . . . . . . 14 83 Appendix A. Support for Source Port Logging in Various Server 84 Software . . . . . . . . . . . . . . . . . . . . . . 16 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 Large-scale IP address sharing technologies (often collectively 90 referred to as "Carrier-Grade NAT", [RFC6888]) are a helpful tool for 91 extending the life of IPv4 addresses by allowing multiple endpoints 92 to share a small number of IPv4 addresses. A number of such 93 technologies have been discussed and deployed, such as Dual-Stack 94 Lite [RFC6333], NAT64 [RFC6146] and NAT444 [I-D.shirasaki-nat444]. A 95 related category of technologies, known as "Address plus Port", or 96 "A+P" [RFC6346], are also used for large-scale IP address sharing, 97 achieved in these cases by using some of the port number bits for 98 addressing purposes. Multiple examples of this category of 99 technologies are also available, including Lightweight 4over6 100 [RFC7596], MAP-E [RFC7597] and MAP-T [RFC7599]. 102 All of these technologies involve extending the space of available 103 IPv4 addresses by mapping communication from multiple endpoints to a 104 single, or small number of shared addresses, through the use of port 105 numbers. The detail of how this is achieved in each technology 106 varies, but the principle remains the same in all cases. 108 From the perspective of a server on the Internet, endpoint traffic 109 that has passed through IP address sharing infrastructure appears to 110 be originating from the IP address of the address sharing appliance. 111 Common practice at the present time is for servers to log the 112 connection time and source IP address of incoming connections. 113 However, the IP address of the address sharing appliance is not 114 sufficient to identify the true source of the traffic because 115 potentially hundreds or thousands of individual endpoints were using 116 that IP address at the same time. If the need arises during a 117 criminal investigation to identify the source of a specific 118 connection, the source port and exact connection time will also be 119 required. Without this additional information it is highly unlikely 120 that it will be possible for law enforcement authorities to progress 121 their investigations. 123 Information is required from at least two sources to establish the 124 link from the logs of an Internet-facing server to a specific 125 subscriber endpoint: 127 1. The administrator of the Internet-facing server must have logged 128 enough information to enable the operator of the IP address 129 sharing infrastructure to isolate a specific subscriber endpoint. 131 2. The operator of the IP address sharing infrastructure must have 132 logged sufficient information (for a sufficient length of time) 133 to be able, when provided with adequate data by a law enforcement 134 agency, to isolate the relevant subscriber endpoint. 136 The operators of large-scale IP address sharing infrastructure, 137 typically Internet Service Providers, are usually required by law to 138 maintain records of which endpoint was using a particular IP address 139 and port at a particular time. The period of time for which these 140 records must be retained is defined by national legislation. 141 Irrespective of whether (and for how long) these records are 142 available, a starting point is needed to indicate to an investigating 143 law enforcement agency that a particular endpoint was involved in a 144 suspected criminal activity under investigation. Without such a 145 starting point, it would be very difficult to progress the 146 investigation even as far as engagement with the operator of the 147 address sharing infrastructure. The records of Internet-facing 148 servers are often a crucial source of this type of evidence. 150 It has been recognised for some time that IP address sharing presents 151 a challenge to the ability to trace network use and abuse [RFC7620]. 152 Further, it has also been recognised that this challenge is likely to 153 become more severe and widespread with the increased use of large- 154 scale address sharing [RFC6269]. More recently, Europol has 155 highlighted the issue of large-scale IP address sharing as a threat 156 to Internet governance [EUROPOL_IOCTA]. It is reported that the 157 problem of crime attribution related to the use of carrier-grade NAT 158 technologies is regularly encountered by 90% of respondents to a 159 survey on the topic. 161 Address sharing, including large-scale address sharing, is required 162 as long as the use of IPv4 continues. Full deployment of IPv6 has 163 the potential to eliminate some of the current attribution issues 164 arising from the use of large-scale address sharing technologies, 165 although presumably new challenges will arise in that case. Since it 166 is impossible to anticipate if or when full migration to IPv6 will 167 take place, it is prudent to consider the implications of the 168 transitionary technologies until the need for them has been 169 eliminated. 171 2. Scope 173 Previous work has already suggested as best practice the logging by 174 Internet-facing servers of source IP address, source port and exact 175 connection time [RFC6302]. However, this continues to be 176 exceptional, rather than routine, logging practice. The purpose of 177 this document is to consider in more detail how it might be possible 178 to bring about routine logging by Internet-facing servers of the 179 information needed to re-establish the ability to trace network abuse 180 for criminal investigative purposes. This document specifically does 181 not address or consider the logging requirements of operators of 182 large-scale address sharing infrastructre. Instead, the focus is on 183 the logging considerations of operators of Internet-facing servers. 184 The main contributions of this document are: 186 1. To consider the reasons why source port logging is not routinely 187 carried out. 189 2. To identify some possible solutions and workarounds for the 190 reasons that source port logging is not routinely carried out. 192 3. To examine the feasibility of source port logging from the 193 perspective of software support for this feature. 195 Clearly no single solution will address the problem of crime 196 attribution on the Internet. Load balancers, proxies and other 197 network infrastructure may also, intentionally or as a side-effect, 198 obfuscate the true source of Internet traffic and these problems will 199 continue to exist with or without the presence of large-scale address 200 sharing technologies (like Carrier-Grade NAT and A+P). Nevertheless, 201 at the time of writing large-scale address sharing technologies 202 present a significant challenge to crime attribution, as highlighted 203 by Europol in the above referenced link, and this document attempts 204 to consider the challenges specifically presented by that category of 205 technologies. 207 The discussion begins by considering whether centralised connection 208 logging is a viable solution to the problem of subscriber 209 identification in criminal investigations. This is followed by an 210 examination of the reasons why source port logging is not currently 211 routinely carried out. A model has been developed for the comparison 212 of the maturity of various server deployments to log source port and 213 a study of common server software has been performed to assess the 214 status of support for this functionality. Many, but not all, 215 enterprise server solutions that were examined made the logging of 216 source port either "Possible" or "Feasible", as defined in the 217 maturity model. Only one type of server software examined made the 218 logging of source port "Default". 220 3. Centralised Connection Logging 222 When large-scale IP address sharing technologies are used, source IP 223 address is no longer a sufficient identifier of an individual 224 subscriber. At a minimum, source port and accurate timestamp 225 information are also required to distinguish between the potentially 226 large number of individual users of a specific IP address at a 227 particular time. [RFC6269] points out that there are two solutions 228 to the question of how adequate information can be recorded to 229 identify the parties to a particular connection. They are: 231 1. Operators of IP address sharing infrastructure log mappings 232 between (source IP address, source port) combinations and their 233 subscribers. Server operators log the IP address and source port 234 of incoming connections. This is referred to as source port 235 logging. 237 2. Instead of relying on server operators to log the source port of 238 incoming connections, operators of IP address sharing 239 infrastructure log all combinations of (external IP address, 240 external port, destination IP address) for outgoing connections. 241 This is referred to as connection logging. Server operators log 242 the IP address and timestamp of incoming connections, which is 243 the common current practice. 245 Two challenges to the use of connection logging by operators of IP 246 address sharing infrastructure are also presented in RFC6269. 247 Briefly: 249 o The volumes of data involved make centralised recording of 250 destination IP addresses infeasible. 252 o Many individuals using the same IP address to access a popular 253 destination (e.g. a popular website) might mean that it is not 254 possible to distinguish between the activity of one subscriber and 255 another, even if connection records are kept by the operator of 256 the address sharing infrastructure. 258 The first issue raised is that the volumes of data involved make 259 centralised recording of destination IP addresses infeasible. 260 Whether destination IP addresses are recorded or not, the volume of 261 logs generated by a large-scale IP address sharing infrastructure 262 will be substantial, and some approaches have been proposed to 263 address this hurdle and make central connection logging more 264 feasible, such as deterministic allocation of ports 265 [RFC6269],[RFC7422] or allocation of port ranges [RFC7768], 266 [RFC6346]. While arguments of infeasibility are not arguments in 267 principle why such logging cannot be done, the volumes of data 268 involved in recording every single outgoing connection in a large 269 Internet service provider represent legitimate technical, commercial 270 and operational arguments for why it can not work in practice. Some 271 representative figures for the scales of data involved can be found 272 in [RFC7422], wherein it is estimated that the logging overhead would 273 be of the order of 150MB per subscriber, per month. For a service 274 provider with one million subscribers, this would produce a volume of 275 logs (uncompressed) of the order of 150 terabytes per month. Aside 276 from the technical overhead of storing such a volume of data, 277 searching and locating relevant records over an extended, legally 278 mandated retention period would also present a significant technical 279 challenge. 281 The second point raised in [RFC6269] against connection logging by 282 operators of IP address sharing infrastructure suggests that even if 283 connection logs store all combinations of (timestamp, source IP, 284 source port, destination IP), if this information is queried in the 285 absence of source port because source port has not been recorded by 286 the destination IP, this would not be sufficient to distinguish the 287 activity of one individual from another in cases where the 288 destination IP is a popular one. This problem is further exacerbated 289 in the case of protocols that make multiple connections per session 290 (e.g. HTTP/HTTPS). The implication of this point is that connection 291 logging, despite potential significant technical and operational 292 overhead, cannot guarantee that the information retained is 293 sufficient to identify an individual suspect, even when all required 294 records are available. 296 Finally, the privacy concerns arising from connection logging in this 297 scenario have been repeatedly raised [RFC6888] and 298 [I-D.ietf-behave-ipfix-nat-logging]. 300 In summary, it is certainly clear that operators of address sharing 301 infrastructure need to retain records to enable the identification of 302 suspects, and such records must consist of, at least, sufficient 303 information to identify an individual subscriber when provided with a 304 timestamp, source IP, source port and destination IP. However, there 305 is no centralised solution available that removes the need for server 306 operators to retain source port information. 308 4. Challenges to Capturing Source Port 310 It is relatively easy to articulate the reason why the operator of an 311 Internet-facing server would wish to retain source port information 312 for incoming connections. If the server operator (or the users that 313 they serve) finds themselves the victim of a crime, it is preferable 314 that all information that could be needed by the server operator to 315 facilitate a criminal investigation is available. On the other hand, 316 there are reasons why a server operator might not have the required 317 source port information. This section enumerates the factors that 318 could negatively influence both the ability and the inclination of 319 server operators to capture and record source port information. 321 4.1. Lack of Awareness 323 Server operators are principally focussed on delivering the services 324 for which they are operating their infrastructure. One of the main 325 problems with the increasing use of IP address sharing technologies 326 is the lack of awareness on the part of server operators that there 327 are direct implications for them in case they should become the 328 victim of a crime. 330 At the time of writing, a minimal amount of material is available 331 online concerning this issue, even for those actively seeking to find 332 out about source port logging. Where specific guidance or 333 information has been provided by vendors in relation to the 334 configuration of source port logging, no explanation is provided for 335 why this might be something that server operators might consider 336 desirable. For example [MSDN_IIS_LOG]. 338 There is, therefore, a considerable awareness gap between the 339 importance of this issue for the purpose of investigating criminal 340 activity online and the awareness of those who need to act in advance 341 of any criminality taking place to ensure that the information needed 342 to facilitate a future investigation is available. 344 4.2. Lack of Support for Logging Source Port 346 Before a server operator can decide to log source port information, 347 the server software must support logging of the source port of 348 incoming connections. Many, but not all major software distributions 349 support the logging of the source port of incoming connections. 350 Clearly lack of support in server software is an insurmountable 351 technical obstacle for a server operator. 353 4.3. Additional Storage Requirements 355 In cases where it is possible to simply add source port to the list 356 of fields recorded in log entries, the additional storage required to 357 preserve source port data is minimal; in the region of six bytes per 358 log entry (maximum of five ASCII digits for the source port plus an 359 additional delimiter). 361 However, in some cases where software supports logging source port of 362 incoming connections, it has been noted that this can only be 363 achieved by enabling verbose or debug logging in the software. This 364 would substantially (and unnecessarily) increase the size of logs 365 produced by the server and would also, in all probability, reduce the 366 production performance of the server. These factors would 367 undoubtedly negatively influence the decision by a server operator to 368 log incoming source port. 370 4.4. Default Log Formats 372 Many major software distributions provide default log formats in 373 their configuration files. A review of the default log format of 374 some common server software has been carried out and in only one case 375 was it found that the source port of incoming connections is logged 376 by any of the default log formats. 378 4.5. Breaking Existing Tooling 380 Much commercial and free log analysis software, by default, expects 381 logs to be in a particular format. Consider, for example, the 382 ubiquity of the Apache Common and Extended Log Formats. The software 383 can usually be configured to parse arbitrary log formats, but this is 384 additional configuration work for a server operator. For example: 385 [ANALOG_LOG_CONFIG],[AWSTATS_LOG_CONFIG]. Without migration 386 planning, a change to default log formats would most likely cause 387 substantial disruption to a considerable amount of downstream 388 processing of server log files. In addition to commercially 389 available software, many administrators have developed or downloaded 390 scripts that expect logs to be in a standard log format. 392 Therefore, log processing software, and in particular custom scripts, 393 may break if default log formats change unexpectedly. At least, the 394 tooling may need to be updated to correctly process the additional 395 fields newly present in log file. 397 4.6. Accuracy of Recorded Time 399 As well as recording the IP address and source port of the 400 connection, it is important to record the exact time of the 401 connection. It has been suggested that there is a need for keeping 402 the exact time against some sort of global standard (e.g. NTP) 403 [RFC6302], however this may not be possible for practical, security 404 or legacy reasons. In practice, it is usually not necessary to keep 405 time against a global standard, as long as time is recorded 406 consistently. The reason for this is that any time offset between 407 the server and the time recorded in another organisation's records 408 (running address sharing infrastructure) can be calculated and 409 compensated for manually. Time offsets of this nature are commonly 410 encountered and well understood in the digital forensics world. 412 5. Comparison Model 414 A model has been developed to assist with comparison of the maturity 415 of server software deployments to store and retrieve source port 416 information for incoming connections. The model is depicted in 417 Figure 1. 419 +-------------------------------------------------------------+ 420 | Possible -> Feasible -> Default -> Manageable -> Accessible | 421 +-------------------------------------------------------------+ 423 Figure 1 425 o "Possible": Means that the server software supports, in any way, 426 the ability to record source ports for incoming connections. 428 o "Feasible": Means that it there are no significant performance or 429 storage implications for enabling the storage of source ports. 431 o "Default": Means that, at a minimum, at least one of the default 432 log formats provided with the software distribution enables the 433 storage of source ports. 435 o "Manageable": Means that tooling is, or has been, build or adapted 436 to support the storage of source ports. 438 o "Accessible": Means that it is possible to identify and retrieve 439 relevant records in the stored log data. 441 6. Support for Logging Source Port 443 Open-source research has been conducted to assess the status of 444 support for logging of source port information in common server 445 software. 447 The assessment criteria were as follows: 449 o Server software is categorised as "Possible" if there was any way 450 identified to cause the logging of source port. 452 o Server software is categorised as "Feasible" if the logging of 453 source port does not require increasing the log level to cause the 454 logging of source port to be possible. In other words, if a 455 server requires enabling verbose, debug or audit logging in order 456 to be able to record source port then logging is "Possible" but 457 not "Feasible". 459 o Server software is categorised as "Default" if at least one of the 460 available default log formats enables logging of the incoming 461 source port, or if source port is logged by default. 463 o The "Manageable" and "Accessible" aspects of the comparison model 464 relate to specific deployments and are therefore not considered in 465 the assessment of server software support. 467 The latest versions of 16 common server software packages have been 468 examined and documentation has been research to identify if and how 469 source port logging can be enabled. The findings are described in 470 Appendix A. Online documentation has been examined to identify if 471 and how source port logging can be enabled. The results are 472 presented in the following table: 474 +----------+----------+---------+------------+------------+ 475 | Possible | Feasible | Default | Manageable | Accessible | 476 +----------+----------+---------+------------+------------+ 477 | 13 | 11 | 1 | N/A | N/A | 478 +----------+----------+---------+------------+------------+ 480 Table 1: Support Table 482 It was noted that only one of the server software packages examined 483 (OpenSSH version 7.5) enables the logging of incoming source port by 484 default. This conclusion has been reached despite using the most 485 generous possible interpretation of "Default", whereby meeting the 486 criteria for "Default" is achieved when logging of source port is 487 offered as a possible default, rather than requiring that logging of 488 source port is enabled by default. In due course, as awareness of 489 this issue increases, it is envisioned that a stricter interpretation 490 of "Default" would be more appropriate, requiring that the logging of 491 source port be enabled by default. 493 7. Conclusions and Next Steps 495 There is clearly substantial work to be done to bring about the 496 regular recording of source port information at Internet-facing 497 servers and there are undoubtedly criminals free right now because 498 the information required to identify them from their online activity 499 is not available. 501 The next steps presented below are some possible courses of action 502 that have been identified based on the current state of source port 503 logging and the challenges described above. 505 7.1. Raise Awareness of the Importance of Logging Source Port 507 Publishers of both free and commercial software should consider 508 releasing deployment guidance or best practice that describes why 509 server administrators need to be recording source port information, 510 with instructions for how this can be done. This will help to 511 address the lack of awareness of the importance of this issue. 513 Considering also the awareness of those who are building software 514 applications, or otherwise involved with coding of Internet-facing 515 applications, secure coding guidance should be updated to include 516 reference to source port information, particularly where such 517 guidance already touches on the issue of logging. For example the 518 OWASP Secure Coding Practices specifies a list of important log event 519 data [OWASP_SCP]. However the "important log event data" list does 520 not, at the time of writing, include source port. 522 7.2. Increase Support for Logging Source Port 524 Many software packages support logging of source port information, 525 but only ten out of the sixteen examined support logging in a way 526 that would not significantly negatively impact the operation of the 527 server software. Software publishers therefore need to consider 528 their level of support of logging source port. In particular, 529 software should support the logging of source port without needing to 530 enable a verbose logging level. 532 7.3. Update Default Log Formats 534 In cases where a particular software package has support for logging 535 of incoming source port, one possibility would be to incorporate one 536 or more log formats that include incoming source port as a field 537 logged by default. Obviously this will not have any impact on 538 deployments of the software that are already in place but for future 539 deployments, the incorporation of source port into the log format 540 will mean that those administrators that use the unaltered default 541 log format will automatically store the required information. 543 7.4. Parallel Logging to a Connection Log 545 Where possible, configuring parallel logging of connection 546 information to a separate log stream would be one possible solution 547 to address the fact that changes to log format might break downstream 548 tooling. This would also be a possible solution that could be used 549 by those server software types that log via syslog. In this case, 550 software publishers could produce guidance on how to configure syslog 551 to log connection information parallel to main log files. 553 Such a solution would help to ease the transition to an alternate log 554 format since current log formats would not need to be changed because 555 the required source port information is stored separately, but can 556 still be correlated with the main log files if needed. 558 7.5. Adequate Timestamp Accuracy in Logs 560 Operators of large-scale address sharing infrastructure will, most 561 likely need connection times specified with at least the granularity 562 of a second. Most, but not all, server software will log times with 563 this granularity by default but there is no guarantee that this is 564 the case. 566 Consideration should be given by server operators to making sure that 567 the times that are being recorded in their log files have sufficient 568 accuracy to allow identification of the required records. As 569 mentioned earlier, the times do not necessarily need to be recorded 570 with reference to a centralised time source (e.g. NTP) as long as 571 times are recorded consistently. 573 This factor also needs to be considered by software developers when 574 they are producing software and although the recording of time is 575 mentioned in the OWASP Secure Coding Practices, the required 576 accuracy/granularity of the recorded time is not discussed 577 [OWASP_SCP]. 579 8. IANA Considerations 581 This memo includes no request to IANA. 583 9. Security Considerations 585 Clearly a balance needs to be struck between individual right to 586 privacy and law enforcement access to data during criminal 587 investigations. On the one hand, the routine logging of any 588 additional information has the potential to introduce risks related 589 to privacy and human rights. On the other hand, it is fair to say 590 that there are criminals free today because the data required to 591 identify them is not available due to the use of large-scale address 592 sharing technologies. Across the world there are also a broad 593 spectrum of legislative regimes and human rights challenges, 594 interpretation of which relate directly to this question. 596 IP addresses are routinely logged today and this information can be 597 used for identification of people online in some cases. The cases in 598 which an IP addresses does not identify an individual directly are 599 not necessarily apparent to the person performing the logging (who 600 cannot tell, for example, if the true source of the traffic is behind 601 a NAT or other form of proxy) and the same is true even if source 602 port is logged. It is not apparent that there is any additional risk 603 to individual privacy between the case when a single piece of 604 endpoint identifying information (source IP address) is logged versus 605 the case when two pieces of endpoint identifying information (source 606 IP address and source port) are logged. Balancing this against the 607 significant advantages from the crime attribution point of view 608 suggests that this may be a worthwhile approach. 610 10. References 612 10.1. Informative References 614 [I-D.ietf-behave-ipfix-nat-logging] 615 Sivakumar, S. and R. Penno, "IPFIX Information Elements 616 for logging NAT Events", draft-ietf-behave-ipfix-nat- 617 logging-13 (work in progress), January 2017. 619 [I-D.shirasaki-nat444] 620 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 621 and H. Ashida, "NAT444", draft-shirasaki-nat444-06 (work 622 in progress), July 2012. 624 10.2. Normative References 626 [ANALOG_LOG_CONFIG] 627 Analog, "Analog 6.0: Log formats", 2017, 628 . 630 [AWSTATS_LOG_CONFIG] 631 AWStats, "AWStats Installation, Configuration and 632 Reporting (for version 7.6)", 2017, 633 . 635 [EUROPOL_IOCTA] 636 Europol, "The Internet Organised Crime Threat Assessment", 637 2016, . 641 [MSDN_IIS_LOG] 642 Microsoft, "IIS 8.5 - How to log client port number", 643 2015, . 646 [OWASP_SCP] 647 OWASP, "OWASP Secure Coding Practices Quick Reference 648 Guide", 2010, . 651 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 652 NAT64: Network Address and Protocol Translation from IPv6 653 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 654 April 2011, . 656 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 657 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 658 DOI 10.17487/RFC6269, June 2011, 659 . 661 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 662 "Logging Recommendations for Internet-Facing Servers", 663 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 664 . 666 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 667 Stack Lite Broadband Deployments Following IPv4 668 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 669 . 671 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 672 the IPv4 Address Shortage", RFC 6346, 673 DOI 10.17487/RFC6346, August 2011, 674 . 676 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 677 A., and H. Ashida, "Common Requirements for Carrier-Grade 678 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 679 April 2013, . 681 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 682 and O. Vautrin, "Deterministic Address Mapping to Reduce 683 Logging in Carrier-Grade NAT Deployments", RFC 7422, 684 DOI 10.17487/RFC7422, December 2014, 685 . 687 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 688 Farrer, "Lightweight 4over6: An Extension to the Dual- 689 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 690 July 2015, . 692 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 693 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 694 Port with Encapsulation (MAP-E)", RFC 7597, 695 DOI 10.17487/RFC7597, July 2015, 696 . 698 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 699 and T. Murakami, "Mapping of Address and Port using 700 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 701 2015, . 703 [RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B., 704 and B. Sarikaya, "Scenarios with Host Identification 705 Complications", RFC 7620, DOI 10.17487/RFC7620, August 706 2015, . 708 [RFC7768] Tsou, T., Li, W., Taylor, T., and J. Huang, "Port 709 Management to Reduce Logging in Large-Scale NATs", 710 RFC 7768, DOI 10.17487/RFC7768, January 2016, 711 . 713 Appendix A. Support for Source Port Logging in Various Server Software 715 The table below enumerates the findings of best-effort, open-source 716 review of documentation of the various products. Where it has been 717 indicated that it is not possible to log source port then either (a) 718 no reference has been identified in online documentation to indicate 719 how source port logging can be enabled, or (b) a reference positively 720 indicating that logging of source port is not possible has been 721 found. 723 +---------+------------+------------+----------+----------+---------+ 724 | Categor | Server | Version | Possible | Feasible | Default | 725 | y | | | | | | 726 +---------+------------+------------+----------+----------+---------+ 727 | HTTP | Apache | 2.4.25 | Yes | Yes | No | 728 | | HTTPD | | | | | 729 | HTTP | IIS | 10 | Yes | Yes | No | 730 | HTTP | Tomcat | 8.5.15 | Yes | Yes | No | 731 | HTTP | Squid | 3.5.25 | Yes | Yes | No | 732 | HTTP | nginx | 1.12.0 | Yes | Yes | No | 733 | Mail | sendmail | 8.15.2 | Yes | Yes | No | 734 | Mail | Microsoft | 2016 | Yes | No | No | 735 | | Exchange | | | | | 736 | | Server | | | | | 737 | Mail | Postfix | 2.10.0 | Yes | Yes | No | 738 | Mail | Exim | 4.89 | Yes | Yes | No | 739 | Mail | Dovecot | 2.2.30.1 | Yes | Yes | No | 740 | Mail | UW IMAP | imap-2007f | No | No | No | 741 | DBase | Oracle | 12.2.0.1 | No | No | No | 742 | DBase | MySQL | 5.7.18 | No | No | No | 743 | DBase | Microsoft | 2016 | Yes | No | No | 744 | | SQL Server | | | | | 745 | DBase | PostgreSQL | 9.6.3 | Yes | Yes | No | 746 | SSH | OpenSSHD | 7.5 | Yes | Yes | Yes | 747 +---------+------------+------------+----------+----------+---------+ 749 Table 2: Support for Logging Incoming Source Port 751 Author's Address 753 David O'Reilly 754 Ireland 756 Email: rfc@daveor.com