RE: CGN fixed/hashed nat question

["Dan Wing" <dwing () cisco com>]

> -----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