Carrier-grade NAT places hundreds or thousands of subscribers behind a single public IPv4 address. When law enforcement or civil litigants submit a legal demand specifying an IP address and a timestamp — the standard form of a subscriber identification request — that information is no longer sufficient to identify a specific subscriber. The carrier knows who was behind the address. CG-NAT means it cannot tell you which one without additional data most operators are not retaining correctly.
How CG-NAT breaks the standard subscriber lookup model
Before widespread CG-NAT deployment, subscriber identification was straightforward: match the public IP address in the request against DHCP lease records for the timestamp specified. One IP address mapped to one subscriber at any given time. The lookup was deterministic.
Under CG-NAT, the public IP address is shared. The differentiator is the source port number assigned to each subscriber session by the NAT gateway. A subscriber behind CG-NAT is identified not by their IP address alone but by the combination of public IP address, source port range, and timestamp. Without all three, the mapping is ambiguous. With thousands of active sessions sharing a single IP, the ambiguity is not theoretical — it is the normal operating condition.
Why timestamp correlation alone fails
The intuitive response is to use timestamps more precisely. If a session was active at 14:32:07, match that to the NAT binding table at that moment. In practice, this approach fails more often than it should — for reasons that are mundane but consequential.
Port allocation windows in modern CG-NAT implementations can be as short as a few seconds for high-churn connection types. Syslog output from NAT gateways is often batched, delayed, or subject to clock drift relative to the network time source used by the system generating the request. When the requested timestamp falls at the boundary of a port allocation window, or when the requesting system's clock is offset from the carrier's NAT logging clock, the correlation produces the wrong answer. The carrier fulfils the request in good faith. The subscriber identified is not the one who generated the traffic.
What accurate identification actually requires
Reliable subscriber identification under CG-NAT requires logging the complete NAT binding tuple: public IP address, allocated source port or port range, the internal private IP address assigned to the subscriber, the subscriber account identifier, and the start and end time of the binding — at sufficient precision.
Precision matters. Logging at one-second granularity is adequate for many use cases but can be insufficient for high-frequency port churn environments. The retention period also matters: NAT binding logs for legal process purposes need to be retained on a schedule that anticipates the latency between when traffic was generated and when a legal demand arrives. Demands referencing events from 90 or 180 days ago are common. If binding logs are rotated on a 30-day cycle, the data needed to answer the request no longer exists.
The legal and operational exposure telecom operators face
Identifying the wrong subscriber in response to a subpoena or court order is not a minor data quality issue. It has consequences for the wrongly identified individual, for the law enforcement investigation relying on the response, and for the carrier's legal exposure. Civil litigants who receive incorrect subscriber identifications in DMCA or fraud matters have pursued telecom operators. Law enforcement investigations have been compromised by incorrect attribution.
Courts have begun scrutinising whether carrier record-keeping practices for CG-NAT environments actually meet the standard expected of a competent records custodian. A carrier that responds to a legal demand with a subscriber identification that is ambiguous or wrong — because its logging architecture was not built for CG-NAT — is in a materially different legal position than one that can demonstrate a complete, auditable chain from IP address and port to subscriber account.
What a reliable NAT logging architecture looks like
The architecture changes required to support accurate CG-NAT subscriber identification are well understood. The barrier is typically operational, not technical — telecom operators have not prioritised NAT binding log retention as a compliance requirement separate from their DHCP and RADIUS logging practices.
- Log the full five-tuple binding: public IP, external port range, subscriber private IP, subscriber account ID, binding start and end timestamp.
- Align NAT gateway clock sources with the NTP infrastructure used by all upstream logging and correlation systems to eliminate clock skew as a source of error.
- Retain NAT binding logs on a schedule that anticipates realistic legal demand latency — typically 180 days minimum, longer for sectors with higher litigation exposure.
- Build subscriber identification as a deterministic query against the binding log, not a best-effort timestamp correlation against DHCP records that were not designed for this purpose.
- Test the lookup process against synthetic demands before production use — the error cases are predictable and can be identified in advance.
