CGN Source Port Logging - Re-Identification Part 1

CGN Source Port Logging - Re-Identification Part 1 Image by USGS (Public Domain)

I am of the opinion that the best approach that is available to address the Carrier-Grade NAT information gap is source port logging at Internet-facing servers. A question arose during a recent discussion on this topic where it was asserted to me that the storage of source port in Internet-facing server logs would necessarily increase the ability of a nefarious actor with access to the logs to re-identify someone from their activity at that Internet-facing server.

Notwithstanding the point that source port logging is the “least worst” of the available options issue from a privacy point of view for addressing the Carrier-Grade NAT information gap, I am not willing to accept the assertion that source port logging increases re-identification power of Internet-facing server logs without seeing some evidence to support the claim. No evidence was provided at the time of the discussion, and although it is not my claim and the burden of proof should really be on the person making the claim, I am willing to investigate this matter and see where the available evidence leads me.

I originally intended to write the entire analysis in a single article but it was getting far too long, so I have broken it up into several pieces. In this first post I describe some of the complexities of how NATs select external ports when they are performing mappings.

Defining the problem

The assertion is that the storage of source port in Internet-facing server logs increases the resolving power of logs to re-identify people. Crucially, this must be done in the absence of access to any other source of information (e.g. ISP records) and also cannot take into account anything that would be present in the logs anyway (e.g. resolving based on URLs requested or other application layer information – because this information will be present in the logs whether source port is logged or not).

Therefore what is required is to measure the differential resolving power of Internet facing logs that contain source IP address versus those that contain source IP address and source port but are in all other ways identical.

How could this be measured?

Suppose there are X people sharing a particular IP address, A, behind a Carrier-Grade NAT. If only IP address is recorded then it is not possible, using only the IP address, to tell which of those X people was responsible for a given log entry. To what extent would the logging of the source port enable identification of one or more of the X people using the IP address?

A second approach that could be considered is whether, with access to a substantial amount of logs, whether it is possible to correlate entries that would enable association of multiple log entries with a specific individual where such a correlation would not be possible of source ports are not logged.

How NATs create internal-external mappings

RFC6888 defines the common requirements for Carrier-Grade NATs. The first requirement is that “If a CGN forwards packets containing a given transport protocol, then it must fulfil that transport protocol’s behavioural requirements.”

For the purposes of this article, TCP and UDP behavioural requirements are considered.

RFC4787 (NAT behavioural requirements for unicast UDP) defines the following port mapping behaviours:

  • Endpoint-independent mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port to any external IP address and port. In other words, an internal IP address and port always map to the same external IP address and port. RFC7857 (Updates to NAT behavioural requirements) clarifies that this behaviour may be extended to connections originating from different internal source IP addresses and ports as long as their destinations are different.
  • Address-dependent mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port to the same external IP address, regardless of the external port. In other words, an internal IP address and port number always map to the same port number from the perspective of a specific IP address on the Internet.
  • Address and port-dependent mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP and port to the same external IP and port while the mapping is still active. In other words, separate external port numbers are used for each mapping through the NAT.

RFC5382 (NAT behavioural requirements for TCP) adds an additional port mapping behaviour:

  • Connection-dependent mapping: The NAT never reuses a port mapping. In other words, for each connection a new mapping is allocated.

How NATs select external ports for mappings

RFC4787 (NAT behavioural requirements for unicast UDP) describes the following port selection behaviours:

  • Port preservation: The NAT attempts to preserve the port number that was used internally when assigning a mapping to an external IP address and port. In cases of a port collision - where two internal IP addresses attempt to use the same port number - some NATs will override the previous mapping to preserve the same port, others will assign a different IP address from the pool of external IP addresses (presuming other addresses are available) and finally the NAT will pick a different port.
  • Port overloading: Some NATs always use port preservation even in cases of collision. This is known as port overloading. RFC4787 recommends that port overloading is not done and RFC5382 (NAT behavioural requirements for TCP) requires that NATs must not perform port overloading.
  • Parity preservation: Some NATs will preserve the parity of the internal port when selecting an external port. In other words an even numbered internal port will be mapped to an even numbered external port, and similarly for odd numbered ports.
  • Port randomisation: In cases where port preservation is not being performed, RFC6056 (Port randomisation recommendations) recommends that the NAT should obfuscate selection of the external port. If port preservation is being used, RFC6056 further recommends that the NAT should obfuscate the selection of the external port if the port needs to be changed. The algorithms described in RFC6056 can also be adapted to preserve port parity if necessary while still obfuscating the external port. RFC7857 (Updates to NAT behavioural requirements) also recommends that NATs should follow these port randomisation recommendations.

In the case of Carrier-Grade NAT, RFC6888 (common requirements for Carrier-Grade NATs) touches on the topic of port selection only by describing that there are three competing requirements, without commenting or making recommendations on appropriate balance:

  • Carrier-Grade NAT port allocation scheme should maximise port utilisation.
  • Carrier-Grade NAT port allocation scheme should minimise log volume.
  • Carrier-Grade NAT port allocation scheme should make it hard for attackers to guess port numbers.

Detailed discussion of the issues arising from attempts to balance these three requirements in practice has already been carried out. Briefly, what this document describes are two categories of port assignment methodology:

  • Dynamic assignment: whereby port allocations are made per-session or per-customer as required. This maximises port utilisation but generates substantial volumes of logs. To reduce the log volume, it is possible to allocate of a port range to each subscriber, rather than an individual port per session.
  • Static assignment: whereby ports or port ranges are reserved for each internal address before subscriber connections are initiated. Port ranges can either be contiguous or non-contiguous.

The security considerations of the document also touch on port randomisation. Port randomisation can be performed within blocks of ports assigned to a specific subscriber.

Summary

This article describes some of the complexity of port assignment to NAT mappings. In the next article I will consider the implication for re-identification resolving power.

 

 

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site you are accepting the use of cookies in accordance with our privacy policy.
Privacy Policy Accept