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? -e
On Mon, Jan 21, 2013 at 12:18 PM, Nick Hilliard <nick@foobar.org> 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 Thanks. -e
-----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
On Jan 23, 2013, at 4:52 AM, Dan Wing wrote:
If using the CGN configuration, then no logging event needs to be generated.
Behavioral/statistical telemetry is very important for security, traffic engineering/capacity planning, and troubleshooting purposes. The overwhelming need for it is orthogonal to any schemes for hashing NAT source/dest ports. What's needed in this regard for CGNs (for any NATs/proxies, really) is something analogous to Cisco's NSEL for ASA, hopefully implemented as IPFIX EEs. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 23/01/2013 02:57, Dobbins, Roland wrote:
The overwhelming need for it is orthogonal to any schemes for hashing NAT source/dest ports.
There are several conflicting requirements, including: - requirement to run a business which makes money - constraints on IPv4 addresses which mandate NAT - law enforcement requirements, mandating either logging / port tracking - network telemetry law enforcement requirements aren't generally an issue until you get hit up by a LEA / court order, at which point they become critical to ensuring that your management doesn't end up displaying contempt of court. For some reason, management can get quite excited about this - more so than any enthusiasm they might ever show for good quality network telemetry. Nick
Hi,
There are several conflicting requirements, including:
- requirement to run a business which makes money - constraints on IPv4 addresses which mandate NAT - law enforcement requirements, mandating either logging / port tracking - network telemetry
law enforcement requirements aren't generally an issue until you get hit up by a LEA / court order, at which point they become critical to ensuring that your management doesn't end up displaying contempt of court. For some reason, management can get quite excited about this - more so than any enthusiasm they might ever show for good quality network telemetry.
I am so glad that Dutch law enforcement officially confirmed that logging is not allowed by law because of privacy impact, and that port tracking is not required. Yes: they see that this will cause problems. But "it's the law" (at least, the current law). - Sander
On 23/01/2013 14:17, Randy Bush wrote:
I am so glad that Dutch law enforcement officially confirmed that logging is not allowed by law because of privacy impact, and that port tracking is not required.
wow! is there enough of what they are drinking to be shared widely?
This probably would be covered in Europe by the EU Data Retention Directive. The European Court of Justice - whose judgements are binding on EU member states - has been requested by both the austrian supreme court and the irish high court for its opinion on the directive. This judgement will probably form the basis of EU-wide law in the area and could cause the directive to be overturned, whether wholly or in part. Separate to this, the german constitutional court and the romanian supreme court have ruled to one degree or other that the data retention directive is incompatible with human rights. https://publicaffairs.linx.net/news/?p=9385 Nick
Question abbout CGN: Generally speaking for CGN setups, how many end users are NATed to a single public IP address ? In terms of traceability, there is a huge difference between loading 200k end users onto 1 public IP and putting say 5 end users per public IP. In the later case, it becomes possible to assign a good range of ports to each of the 5 users on that IP address. In the former case, it isn't. An ISP who nats 5 customers to each public IP address reduces fivefold the need for pulic IP addresses, which is still a major accomplishement.
On Wed, Jan 23, 2013 at 4:31 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
Generally speaking for CGN setups, how many end users are NATed to a single public IP address ?
In terms of traceability, there is a huge difference between loading 200k end users onto 1 public IP and putting say 5 end users per public IP.
In the later case, it becomes possible to assign a good range of ports to each of the 5 users on that IP address. In the former case, it isn't.
An ISP who nats 5 customers to each public IP address reduces fivefold the need for pulic IP addresses, which is still a major accomplishement.
If you'll entertain a guess, it'll shake out around 64:1. If I were designing it (I'm not) it might look something like this: A CIDR block of customer private IPs will map to a particular CGN box. (e.g. 100.67.64.0/18, 16,000ish customers) That box will have roughly 6 bits fewer public IPs available for the translations (64:1 ratio, e.g. 203.0.113.0/24). Multiple such mappings allowed per CGN box. The box will algorithmically allocate 256 ports to each interior IP, consuming about 1/4 of the exterior ports. All 256 are on the same exterior IP. No logging need be generated where customers need fewer than 256 translations at once. Which is most people all the time and many of the rest most of the time. The algorithm will exclude the .0 and .255 external addresses from use, mapping the respective internal IPs to the other externals. The box will dynamically allocate port ranges in blocks of 256ish ports to the very active interior customers upon demand when no further translations are available in that customer's existing blocks. It will log once upon allocation of the port range and once again upon release of the range when no translations are active for a timeout period. When allocating dynamic port ranges it will try to match the algorithmically picked IP address if port blocks are available but will fail over to other IP addresses rather than refuse an outbound connection. I note that any algorithmic assignment is going to come up weak on draft-ietf-behave-lsn-requirements's REQ-15 but that's a "should" anyway and I'm willing to risk it. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Hi, On Wed, 23 Jan 2013, William Herrin wrote: <snipp/>
The algorithm will exclude the .0 and .255 external addresses from use, mapping the respective internal IPs to the other externals. <snipp/>
why would you want to do that. .0 and .255 are perfectly valid ips. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
On Wed, Jan 23, 2013 at 6:21 PM, Christian Kratzer <ck-lists@cksoft.de> wrote:
On Wed, 23 Jan 2013, William Herrin wrote:
The algorithm will exclude the .0 and .255 external addresses from use, mapping the respective internal IPs to the other externals.
why would you want to do that. .0 and .255 are perfectly valid ips.
Except for the machines which will refuse to talk to them. There's no excuse for post-classful stacks failing to work with those IPs but some do anyway. Enough that you don't want to waste your support staff's time dealing with the fallout. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Tue, Jan 22, 2013 at 4:52 PM, Dan Wing <dwing@cisco.com> wrote:
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.
I thought this was desirable behavior for a CGN since effective port prediction facilitates p2p nat traversal? Bear in mind that Windows XP uses a dynamic port range between 1024 and 5000 and allocates them linearly. Small range and trivially predictable. Were it practical to use this knowledge for much more than denial of service I tend to think we'd have noticed by now. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, Jan 23, 2013 at 8:32 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2013-01-23 14:22, William Herrin a écrit :
I thought this was desirable behavior for a CGN since effective port prediction facilitates p2p nat traversal?
NAT traversal using port prediction is a Worst Current Practice.
In other words, it works well enough that CGN's predicted total destruction of p2p may be just slightly overblown. In fact, were someone to use those "worst current practices" to build some generic p2p VPN software, even old games could leverage it to allow someone behind a CGN to host. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Le 2013-01-23 16:37, William Herrin a écrit :
NAT traversal using port prediction is a Worst Current Practice.
In fact, were someone to use those "worst current practices" to build some generic p2p VPN software, even old games could leverage it to allow someone behind a CGN to host.
Have a look at this: http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements These are the IETF's requirements for CGNs. The intent is to provide guidelines to vendors so that their CGNs can be as harmless as possible. A CGN that obeys these requirements will allow NAT traversal by virtue of having an Endpoint-Independent Mapping behaviour. That is the BCP. Not port prediction. Simon
On Wed, Jan 23, 2013 at 10:54 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2013-01-23 16:37, William Herrin a écrit :
In fact, were someone to use those "worst current practices" to build some generic p2p VPN software, even old games could leverage it to allow someone behind a CGN to host.
http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements
A CGN that obeys these requirements will allow NAT traversal by virtue of having an Endpoint-Independent Mapping behaviour. That is the BCP. Not port prediction.
Even better. So, architecturally P2P compatibility with CGNs is a solved problem waiting only for the software to shake out. Expect some growing pains in the first generation CGNs which largely vanish in the second. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (10)
-
Christian Kratzer -
Dan Wing -
Dobbins, Roland -
Eric Oosting -
Jean-Francois Mezei -
Nick Hilliard -
Randy Bush -
Sander Steffann -
Simon Perreault -
William Herrin