Source-port logging

Recording the remote source port and an accurate timestamp alongside the remote address, so that a report about an event remains attributable when the address is shared by many subscribers.

Without the port, an abuse report against a carrier-grade NAT address is unanswerable: the provider can only say that some hundreds of customers were behind that address at that moment. Most internet-facing services still log the address alone, which is why so many reports go nowhere and why blocking by address punishes a whole shared pool. It costs one extra field, and it is the single cheapest thing a service operator can do to make the abuse ecosystem work.

RFC 6302 (June 2011) asks internet-facing servers to record, with each connection, the source port, a timestamp in UTC accurate to the second from a traceable source such as NTP, and the transport and destination port where a service uses several. The same applies to load balancers logging on behalf of servers, and to IPv6 for consistency.

Precision matters because ports are reused. RFC 6888 only asks a CGN to wait 120 seconds before reallocating a port, some reuse ports almost at once, and RFC 6269 warns that even small clock skew between a server and a densely used CGN makes the subscriber ambiguous. The alternative, logging destinations at the CGN, is weaker: it cannot separate subscribers who reach a popular server at nearly the same time, and RFC 6888 says a CGN should not log destinations at all.

Common servers can do it: Apache with %a and %{remote}p in the log format, Postfix with smtpd_client_port_logging, off by default, and OpenSSH with LogLevel VERBOSE. RFC 7768 recorded that IIS, Cyrus IMAP and UW IMAP could not. In Brazil, the Marco Civil's definition of a connection record names date, time, duration and IP address, not the port.

Also known as: rfc 6302, abuse logging, ip plus port plus timestamp

Sources

← All glossary entries