-----Original Message----- From: Eric Oosting [mailto:eric.oosting@gmail.com] Sent: Monday, January 21, 2013 9:06 AM To: NANOG Subject: CGN fixed/hashed nat question
Let me start out by saying I'm allergic to CGN, but I got to ask the question:
Some of the CGN providers are coming out with "fixed" nat solutions for their IPv6 transition/IPv4 preservation technologies to reduce logging. This appears to provide for a static mapping of outside ports/IPs to a particular customer such that the service provider doesn't need to log literally every session through the box.
At the last nanog, I seem to remember someone stepping up and discussing the problems associated with just taking ports 1025 through 1025+X and giving it to some customer and had brought up the idea of using a hash or salt to map what would appear to be random ports to a customer in such a way that you could reverse the port back to the customer later if need be. For the life of me, I can't find anything on the internets about this concept.
I had it in my head it was a lightning talk or something, but reviewing the agenda doesn't ring any bells. Anyone know what I'm talking about and what it's called?
later, Eric Oosting <eric.oosting@gmail.com> wrote:
draft-donley-behave-deterministic-cgn
That's it. Or more specifically, the section of that draft that points to https://tools.ietf.org/html/rfc6431#section-2.2
I am also not a fan of CGN or NAT, but I co-chair the IETF's BEHAVE working group that works on NAT. draft-donley-behave-deterministic-cgn provides that functionality in an attempt to help randomize ports (see RFC6056). However, because the ports are fixed and there are relatively few ports, an attacker can determine the ports by causing the victim to open a bunch of TCP connections. This can be done by a bunch of "img src" tags in an HTML-encoded email message, among other mechanisms. If the hashing causes no logging, it creates a new requirement for a strong audit trail of the CGN configuration. The hashing provided by draft-donley-behave-deterministic-cgn is not necessary to avoid "logging every session". Rather, the reduction occurs by generating 1 logging event when creating NNNN mapped ports. If using the CGN configuration, then no logging event needs to be generated. To date, the BEHAVE working group has not standardized any of the proposed hashing techniques because several require coordination between the devices (such as CPE and CGN), or between the log generator and log consumer, or are functions self-contained within a device and don't require standards action. -d