idnits 2.17.1 draft-daveor-cgn-logging-00.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 (August 21, 2017) is 2434 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 August 21, 2017 4 Intended status: Informational 5 Expires: February 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-00 11 Abstract 13 The use of large-scale IP address sharing technologies (commonly 14 known as "carrier-grade NAT") 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 http://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 February 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 (http://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. Centralised Connection Logging . . . . . . . . . . . . . . . 4 62 3. Challenges to Capturing Source Port . . . . . . . . . . . . . 6 63 3.1. Lack of Awareness . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Lack of Support for Logging Source Port . . . . . . . . . 7 65 3.3. Additional Storage Requirements . . . . . . . . . . . . . 7 66 3.4. Default Log Formats . . . . . . . . . . . . . . . . . . . 7 67 3.5. Breaking Existing Tooling . . . . . . . . . . . . . . . . 8 68 3.6. Accuracy of Recorded Time . . . . . . . . . . . . . . . . 8 69 4. Comparison Model . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Support for Logging Source Port . . . . . . . . . . . . . . . 9 71 6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 10 72 6.1. Raise Awareness of Logging Source Port in Deployment 73 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. Increase Support for Logging Source Port . . . . . . . . 11 75 6.3. Changing Default Log Formats . . . . . . . . . . . . . . 11 76 6.4. Parallel Logging to a Connection Log . . . . . . . . . . 11 77 6.5. Adequate Timestamp Accuracy in Logs . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Informative References . . . . . . . . . . . . . . . . . 12 82 9.2. Normative References . . . . . . . . . . . . . . . . . . 12 83 Appendix A. Support for Source Port Logging in Various Server 84 Software . . . . . . . . . . . . . . . . . . . . . . 14 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 Large-scale IP address sharing technologies (often collectively 90 referred to as "Carrier-Grade NAT") are a helpful tool for extending 91 the life of IPv4 by allowing multiple endpoints to share a small 92 number of IPv4 addresses, and a number of such technologies have been 93 discussed and deployed [RFC6333], [RFC6146], [I-D.shirasaki-nat444], 94 [RFC7757],[RFC6888]. These technologies involve extending the space 95 of available IPv4 addresses by mapping communication from multiple 96 endpoints to a single, or small number of shared addresses, through 97 the use of port numbers. The detail of how this is achieved in each 98 technology varies, but the principle remains the same in all cases. 100 From the perspective of a server on the Internet, endpoint traffic 101 that has passed through IP address sharing infrastructure appears to 102 be originating from the IP of the address sharing appliance. Common 103 practice at the present time is for servers to log the connection 104 time and source IP address of incoming connections. However, the IP 105 address of the address sharing appliance is not sufficient to 106 identify the true source of the traffic because potentially hundreds 107 or thousands of individual endpoints were using that IP address at 108 the same time. If the need arises during a criminal investigation to 109 identify the source of a specific connection, the source port and 110 exact connection time will also be required. Without this additional 111 information it is highly unlikely that it will be possible for law 112 enforcement authorities to progress their investigations. 114 Information is required from at least two sources to establish the 115 link from the logs of an Internet-facing server to a specific 116 subscriber endpoint: 118 1. The administrator of the Internet-facing server must have logged 119 enough information to enable the operator of the IP address 120 sharing infrastructure to isolate a specific subscriber endpoint. 122 2. The operator of the IP address sharing infrastructure must have 123 logged sufficient information (for a sufficient length of time) 124 to be able, when provided with adequate data by a law enforcement 125 agency, to isolate the relevant subscriber endpoint. 127 The operators of large-scale IP address sharing infrastructure, 128 typically Internet Service Providers, are usually required by law to 129 maintain records of which endpoint was using a particular IP address 130 and port at a particular time. The period of time for which these 131 records must be retained is defined by national legislation. 132 Irrespective of whether (and for how long) these records are 133 available, a starting point is needed to indicate to an investigating 134 law enforcement agency that a particular endpoint was involved in a 135 suspected criminal activity under investigation. Without such a 136 starting point, it would be very difficult to progress the 137 investigation even as far as engagement with the operator of the 138 address sharing infrastructure. The records of Internet-facing 139 servers are often a crucial source of this type of evidence. 141 It has been recognised for some time that IP address sharing presents 142 a challenge to the ability to trace network use and abuse. Further, 143 it has also been recognised that this challenge is likely to become 144 more severe and widespread with the increased use of large-scale 145 address sharing [RFC6269]. More recently, Europol has highlighted 146 the issue of large-scale IP address sharing as a threat to Internet 147 governance [EUROPOL_IOCTA]. It is reported that the problem of crime 148 attribution related to the use of carrier-grade NAT technologies is 149 regularly encountered by 90% of respondents to a survey requesting 150 information on the topic. 152 Previous work has already suggested as best practice the logging by 153 Internet-facing servers of source IP address, source port and exact 154 connection time [RFC6302]. However, no detailed consideration has 155 been given to the possible approaches to and implications of this 156 proposed logging practice. 158 The purpose of this document is to consider in more detail how it 159 might be possible to bring about routine logging by Internet-facing 160 servers of the information needed to re-establish the ability to 161 trace network abuse for criminal investigative purposes. The 162 discussion begins by considering whether centralised connection 163 logging is a viable solution to the problem of subscriber 164 identification in criminal investigations. This is followed by an 165 examination of the reasons why source port logging is not currently 166 routinely carried out. A model has been developed for the comparison 167 of the maturity of various server deployments to log source port and 168 a study of common server software has been performed to assess the 169 status of support for this functionality. Many, but not all, 170 enterprise server solutions that were examined made the logging of 171 source port either "Possible" or "Feasible", as defined in the 172 maturity model. Only one type of server software examined made the 173 logging of source port "Default". 175 2. Centralised Connection Logging 177 When large-scale IP address sharing technologies are used, source IP 178 address is no longer a sufficient identifier of an individual 179 subscriber. At a minimum, source port and accurate timestamp 180 information are also required to distinguish between the potentially 181 large number of individual users of a specific IP address at a 182 particular time. [RFC6269] points out that there are two solutions 183 to the question of how adequate information can be recorded to 184 identify the parties to a particular connection. They are: 186 1. Operators of IP address sharing infrastructure log mappings 187 between (source IP address, source port) combinations and their 188 subscribers. Server operators log the IP address and source port 189 of incoming connections. This is referred to as source port 190 logging. 192 2. Instead of relying on server operators to log the source port of 193 incoming connections, operators of IP address sharing 194 infrastructure log all combinations of (source IP address, source 195 port, destination IP address) for outgoing connections. This is 196 referred to as connection logging. Server operators log only the 197 IP address of incoming connections, which is the common current 198 practice. 200 Two challenges to the use of connection logging by operators of IP 201 address sharing infrastructure are also presented in RFC6269. 202 Briefly: 204 o The volumes of data involved make centralised recording of 205 destination IP addresses infeasible. 207 o Many individuals using the same IP address to access a popular 208 destination (e.g. a popular website) might mean that it is not 209 possible to distinguish between the activity of one subscriber and 210 another, even if connection records are kept by the operator if 211 the address sharing infrastructure. 213 The first issue raised is that the volumes of data involved make 214 centralised recording of destination IP addresses infeasible. In 215 many scenarios, the volume of logs generated by a large-scale IP 216 address sharing infrastructure will be substantial, and some 217 approaches have been proposed to address this hurdle and make central 218 connection logging more feasible, such as deterministic allocation of 219 ports [RFC6269],[RFC7422] or allocation of port ranges [RFC7768], 220 [RFC6346]. While arguments of infeasibility are not arguments in 221 principle why such logging cannot be done, the volumes of data 222 involved in recording every single outgoing connection in a large 223 Internet service provider represent legitimate technical, commercial 224 and operational arguments for why it can not work in practice. Some 225 representative figures for the scales of data involved can be found 226 in [RFC7422], wherein it is estimated that the logging overhead would 227 be of the order of 150MB per subscriber, per month. For a service 228 provider with one million subscribers, this would produce a volume of 229 logs (uncompressed) of the order of 150 terabytes per month. Aside 230 from the technical overhead of storing such a volume of data, 231 searching and locating relevant records over an extended, legally 232 mandated retention period would also present a significant technical 233 challenge. 235 The second point raised in [RFC6269] against connection logging by 236 operators of IP address sharing infrastructure suggests that even if 237 connection logs store all combinations of (timestamp, source IP, 238 source port, destination IP), if this information is queried in the 239 absence of source port because source port has not been recorded by 240 the destination IP, this would not be sufficient to distinguish the 241 activity of one individual from another in cases where the 242 destination IP is a popular one. This problem is further exacerbated 243 in the case of protocols that make multiple connections per session 244 (e.g. HTTP/HTTPS). The implication of this point is that connection 245 logging, despite potential significant technical and operational 246 overhead, cannot guarantee that the information retained is 247 sufficient to identify an individual suspect, even when all required 248 records are available. 250 Finally, the privacy concerns arising from connection logging in this 251 scenario have been repeatedly raised 252 [RFC6888],[I-D.ietf-behave-ipfix-nat-logging]. 254 In summary, it is certainly clear that operators of address sharing 255 infrastructure need to retain records to enable the identification of 256 suspects, and such records must consist of, at least, sufficient 257 information to identify an individual subscriber when provided with a 258 timestamp, source IP, source port and destination IP. However, there 259 is no centralised solution available that removes the need for server 260 operators to retain source port information. 262 3. Challenges to Capturing Source Port 264 It is relatively easy to articulate the reason why the operator of an 265 Internet-facing server would wish to retain source port information 266 for incoming connections. If the server operator (or the users that 267 they serve) finds themselves the victim of a crime, it is preferable 268 that all information that could be needed by the server operator to 269 facilitiate a criminal investigation is available. On the other 270 hand, there are reasons why a server operator might not have the 271 required source port information. This section enumerates the 272 factors that could negatively influence both the ability and the 273 inclination of server operators to capture and record source port 274 information. 276 3.1. Lack of Awareness 278 Server operators are principally focussed on delivering the services 279 for which they are operating their infrastructure. One of the main 280 problems with the increasing use of IP address sharing technologies 281 is the lack of awareness on the part of server operators that there 282 are direct implications for them in case they should become the 283 victim of a crime. 285 At the time of writing, a minimal amount of material is available 286 online concerning this issue, even for those actively seeking to find 287 out about source port logging. Where specific guidance or 288 information has been provided by vendors in relation to the 289 configuration of source port logging, no explanation is provided for 290 why this might be something that server operators might consider 291 desirable. For example [MSDN_IIS_LOG]. 293 There is, therefore, a considerable awareness gap between the 294 importance of this issue for the purpose of investigating criminal 295 activity online and the awareness of those who need to act in advance 296 of any criminality taking place to ensure that the information needed 297 to facilitate a future investigation is available. 299 3.2. Lack of Support for Logging Source Port 301 Before a server operator can decide to log source port information, 302 the server software must support logging of the source port of 303 incoming connections. Many, but not all major software distributions 304 support the logging of the source port of incoming connections. 305 Clearly lack of support in server software is an insurmountable 306 technical obstacle for a server operator. 308 3.3. Additional Storage Requirements 310 In cases where it is possible to simply add source port to the list 311 of fields recorded in log entries, the additional storage required to 312 preserve source port data is minimal; in the region of six bytes per 313 log entry (maximum of five ASCII digits for the source port plus an 314 additional delimiter). 316 However, in some cases where software supports logging source port of 317 incoming connections, it has been noted that this can only be 318 achieved by enabling verbose or debug logging in the software. This 319 would substantially (and unnecessarily) increase the size of logs 320 produced by the server and would also, in all probability, reduce the 321 production performance of the server. These factors would 322 undoubtedly negatively influence the decision by a server operator to 323 log incoming source port. 325 3.4. Default Log Formats 327 Many major software distributions provide default log formats in 328 their configuration files. A review of the default log format of 329 some common server software has been carried out and in only one case 330 was it found that the source port of incoming connections is logged 331 by any of the default log formats. 333 3.5. Breaking Existing Tooling 335 Much commercial and free log analysis software, by default, expects 336 logs to be in a particular format. Consider, for example, the 337 ubiquity of the Apache Common and Extended Log Formats. The software 338 can usually be configured to parse arbitrary log formats, but this is 339 additional configuration work for a server operator. For example: 340 [ANALOG_LOG_CONFIG],[AWSTATS_LOG_CONFIG]. Without migration 341 planning, a change to default log formats would most likely cause 342 substantial disruption to a considerable amount of downstream 343 processing of server log files. In addition to commercially 344 available software, many administrators have developed or downloaded 345 scripts that expect logs to be in a standard log format. 347 Therefore, log processing software, and in particular custom scripts, 348 may break if default log formats change unexpectedly. At least, the 349 tooling may need to be updated to correctly process the additional 350 fields newly present in log file. 352 3.6. Accuracy of Recorded Time 354 As well as recording the IP address and source port of the 355 connection, it is important to record the exact time of the 356 connection. It has been suggested that there is a need for keeping 357 the exact time against some sort of global standard (e.g. NTP) 358 [RFC6302], however this may not be possible for practical, security 359 or legacy reasons. In practice, it is usually not necessary to keep 360 time against a global standard, as long as time is recorded 361 consistently. The reason for this is that any time offset between 362 the server and the time recorded in another organisation's records 363 (running address sharing infrastructure) can be calculated and 364 compensated for manually. Time offsets of this nature are commonly 365 encountered and well understood in the digital forensics world. 367 4. Comparison Model 369 A model has been developed to assist with comparison of the maturity 370 of server software deployments to store and retrieve source port 371 information for incoming connections. The model is depicted in 372 Figure 1. 374 +-------------------------------------------------------------+ 375 | Possible -> Feasible -> Default -> Manageable -> Accessible | 376 +-------------------------------------------------------------+ 378 Figure 1 380 o "Possible": Means that the server software supports, in any way, 381 the ability to record source ports for incoming connections. 383 o "Feasible": Means that it there are no significant performance or 384 storage implications for enabling the storage of source ports. 386 o "Default": Means that, at a minimum, at least one of the default 387 log formats provided with the software distribution enables the 388 storage of source ports. 390 o "Manageable": Means that tooling is, or has been, build or adapted 391 to support the storage of source ports. 393 o "Accessible": Means that it is possible to identify and retrieve 394 relevant records in the stored log data. 396 5. Support for Logging Source Port 398 Open-source research has been conducted to assess the status of 399 support for logging of source port information in common server 400 software. 402 The assessment criteria were as follows: 404 o Server software is categorised as "Possible" if there was any way 405 identified to cause the logging of source port. 407 o Server software is categorised as "Feasible" if the logging of 408 source port does not require increasing the log level to cause the 409 logging of source port to be possible. In other words, if a 410 server requires enabling verbose, debug or audit logging in order 411 to be able to record source port then logging is "Possible" but 412 not "Feasible". 414 o Server sofwtare is categorised as "Default" if at least one of the 415 available default log formats enables logging of the incoming 416 source port, or if source port is logged by default. 418 o The "Manageable" and "Accessible" aspects of the comparison model 419 relate to specific deployments and are therefore not considered in 420 the assessment of server software support. 422 The latest versions of 16 common server software packages have been 423 examined and documentation has been research to identify if and how 424 source port logging can be enabled. The findings are described in 425 Appendix A. Online documentation has been examined to identify if 426 and how source port logging can be enabled. The results are 427 presented in the following table: 429 +----------+----------+---------+------------+------------+ 430 | Possible | Feasible | Default | Manageable | Accessible | 431 +----------+----------+---------+------------+------------+ 432 | 13 | 11 | 1 | N/A | N/A | 433 +----------+----------+---------+------------+------------+ 435 Table 1: Support Table 437 It was noted that only one of the server software packages examined 438 (OpenSSH version 7.5) enables the logging of incoming source port by 439 default. This conclusion has been reached despite using the most 440 generous possible interpretation of "Default", whereby meeting the 441 criteria for "Default" is achieved when logging of source port is 442 offered as a possible default, rather than requiring that logging of 443 source port is enabled by default. In due course, as awareness of 444 this issue increases, it is envisioned that a stricter interpretation 445 of "Default" would be more appropriate, requiring that the logging of 446 source port be enabled by default. 448 6. Conclusions and Next Steps 450 There is clearly substantial work to be done to bring about the 451 regular recording of source port information at Internet-facing 452 servers and there are undoubtedly criminals free right now because 453 the information required to identify them from their online activity 454 is not available. 456 The next steps presented below are some possible courses of action 457 that have been identified based on the current state of source port 458 logging and the challenges described above. 460 6.1. Raise Awareness of Logging Source Port in Deployment Guidance 462 Publishers of both free and commercial software should consider 463 releasing deployment guidance or best practice that describes why 464 server administrators need to be recording source port information, 465 with instructions for how this can be done. This will help to 466 address the lack of awareness of the importance of this issue. 468 Considering also the awareness of those who are building software 469 applications, or otherwise involved with coding of Internet-facing 470 applications, secure coding guidance should be updated to include 471 reference to source port information, particularly where such 472 guidance already touches on the issue of logging. For example the 473 OWASP Secure Coding Practices specifies a list of important log event 474 data [OWASP_SCP]. However the "important log event data" list does 475 not, at the time of writing, include source port. 477 6.2. Increase Support for Logging Source Port 479 Many software packages support logging of source port information, 480 but only ten out of the sixteen examined support logging in a way 481 that would not significantly negatively impact the operation of the 482 server software. Software publishers therefore need to consider 483 their level of support of logging source port. In particular, 484 software should support the logging of source port without needing to 485 enable a verbose logging level. 487 6.3. Changing Default Log Formats 489 In cases where a particular software package has support for logging 490 of incoming source port, one possibility would be to incorporate one 491 or more log formats that include incoming source port as a field 492 logged by default. Obviously this will not have any impact on 493 deployments of the software that are already in place but for future 494 deployments, the incorporation of source port into the log format 495 will mean that those administrators that use the unaltered default 496 log format will automatically store the required information. 498 6.4. Parallel Logging to a Connection Log 500 Where possible, configuring parallel logging of connection 501 information to a separate log stream would be one possible solution 502 to address the fact that changes to log format might break downstream 503 tooling. This would also be a possible solution that could be used 504 by those server software types that log via syslog. In this case, 505 software publishers could produce guidance on how to configure syslog 506 to log connection information parallel to main log files. 508 Such a solution would help to ease the transition to an alternate log 509 format since current log formats would not need to be changed because 510 the required source port information is stored separately, but can 511 still be correlated with the main log files if needed. 513 6.5. Adequate Timestamp Accuracy in Logs 515 Operators of large-scale address sharing infrastructure will, most 516 likely need connection times specified with at least the granularity 517 of a second. Most, but not all, server software will log times with 518 this granularity by default but there is no guarantee that this is 519 the case. 521 Consideration should be given by server operators to making sure that 522 the times that are being recorded in their log files have sufficient 523 accuracy to allow identification of the required records. As 524 mentioned earlier, the times do not necessarily need to be recorded 525 with reference to a centralised time source (e.g. NTP) as long as 526 times are recorded consistently. 528 This factor also needs to be considered by software developers when 529 they are producing software and although the recording of time is 530 mentioned in the OWASP Secure Coding Practices, the required 531 accuracy/granularity of the recorded time is not discussed 532 [OWASP_SCP]. 534 7. IANA Considerations 536 This memo includes no request to IANA. 538 8. Security Considerations 540 This memo does not define any protocol and therefore creates no new 541 security issues. 543 9. References 545 9.1. Informative References 547 [I-D.ietf-behave-ipfix-nat-logging] 548 Sivakumar, S. and R. Penno, "IPFIX Information Elements 549 for logging NAT Events", draft-ietf-behave-ipfix-nat- 550 logging-13 (work in progress), January 2017. 552 [I-D.shirasaki-nat444] 553 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 554 and H. Ashida, "NAT444", draft-shirasaki-nat444-06 (work 555 in progress), July 2012. 557 9.2. Normative References 559 [ANALOG_LOG_CONFIG] 560 Analog, "Analog 6.0: Log formats", 2017, 561 . 563 [AWSTATS_LOG_CONFIG] 564 AWStats, "AWStats Installation, Configuration and 565 Reporting (for version 7.6)", 2017, 566 . 568 [EUROPOL_IOCTA] 569 Europol, "The Internet Organised Crime Threat Assessment", 570 2016, . 574 [MSDN_IIS_LOG] 575 Microsoft, "IIS 8.5 - How to log client port number", 576 2015, . 579 [OWASP_SCP] 580 OWASP, "OWASP Secure Coding Practices Quick Reference 581 Guide", 2010, . 584 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 585 NAT64: Network Address and Protocol Translation from IPv6 586 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 587 April 2011, . 589 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 590 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 591 DOI 10.17487/RFC6269, June 2011, . 594 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 595 "Logging Recommendations for Internet-Facing Servers", 596 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 597 . 599 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 600 Stack Lite Broadband Deployments Following IPv4 601 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 602 . 604 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 605 the IPv4 Address Shortage", RFC 6346, 606 DOI 10.17487/RFC6346, August 2011, 607 . 609 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 610 A., and H. Ashida, "Common Requirements for Carrier-Grade 611 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 612 April 2013, . 614 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 615 and O. Vautrin, "Deterministic Address Mapping to Reduce 616 Logging in Carrier-Grade NAT Deployments", RFC 7422, 617 DOI 10.17487/RFC7422, December 2014, . 620 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 621 Mappings for Stateless IP/ICMP Translation", RFC 7757, 622 DOI 10.17487/RFC7757, February 2016, . 625 [RFC7768] Tsou, T., Li, W., Taylor, T., and J. Huang, "Port 626 Management to Reduce Logging in Large-Scale NATs", 627 RFC 7768, DOI 10.17487/RFC7768, January 2016, 628 . 630 Appendix A. Support for Source Port Logging in Various Server Software 632 The table below enumerates the findings of best-effort, open-source 633 review of documentation of the various products. Where it has been 634 indicated that it is not possible to log source port then either (a) 635 no reference has been identified in online documentation to indicate 636 how source port logging can be enabled, or (b) a reference positively 637 indicating that logging of source port is not possible has been 638 found. 640 +---------+------------+------------+----------+----------+---------+ 641 | Categor | Server | Version | Possible | Feasible | Default | 642 | y | | | | | | 643 +---------+------------+------------+----------+----------+---------+ 644 | HTTP | Apache | 2.4.25 | Yes | Yes | No | 645 | | HTTPD | | | | | 646 | HTTP | IIS | 10 | Yes | Yes | No | 647 | HTTP | Tomcat | 8.5.15 | Yes | Yes | No | 648 | HTTP | Squid | 3.5.25 | Yes | Yes | No | 649 | HTTP | nginx | 1.12.0 | Yes | Yes | No | 650 | Mail | sendmail | 8.15.2 | Yes | Yes | No | 651 | Mail | Microsoft | 2016 | Yes | No | No | 652 | | Exchange | | | | | 653 | | Server | | | | | 654 | Mail | Postfix | 2.10.0 | Yes | Yes | No | 655 | Mail | Exim | 4.89 | Yes | Yes | No | 656 | Mail | Dovecot | 2.2.30.1 | Yes | Yes | No | 657 | Mail | UW IMAP | imap-2007f | No | No | No | 658 | DBase | Oracle | 12.2.0.1 | No | No | No | 659 | DBase | MySQL | 5.7.18 | No | No | No | 660 | DBase | Microsoft | 2016 | Yes | No | No | 661 | | SQL Server | | | | | 662 | DBase | PostgreSQL | 9.6.3 | Yes | Yes | No | 663 | SSH | OpenSSHD | 7.5 | Yes | Yes | Yes | 664 +---------+------------+------------+----------+----------+---------+ 666 Table 2: Support for Logging Incoming Source Port 668 Author's Address 670 David O'Reilly 671 Ireland 673 Email: rfc@daveor.com