A lot depends on the CGNAT features you are looking to support, some considerations: - Are you looking for port block allocation for bulk logging, where a given subscriber is given a block of source TCP/UDP ports on a translated IP address - How many translations and session rate are you looking to support - Do you require Port Control Protocol (PCP) support for inbound pinholing reservations? Do your subscribers support uPnP to PCP translation? - Are you looking to support RFC 6598 (carrier use of 100.64.0.0/10 for CGNAT)? - Are you looking to support DS-Lite (RFC 6333) or lw4o6 (RFC 7596)? Both have significantly different requirements relative to CGNAT (DS-Lite assumes translation of subscriber RFC 1918 addresses tracking their IPv6 address in the translation table, lw4o6 assumes translation from RFC 1918 to RFC 6598 at the subscriber/B4 prior to IPv6 encapsulation plus translation of RFC 6598 to public at the CGNAT/AFTR) Generally, I tend to recommend F5 BIG-IP from a CGNAT feature standpoint - Ed On Fri, Apr 7, 2017 at 1:48 PM, Aaron Gould <aaron1@gvtc.com> wrote:
Thanks Rich, you bring up some good points. Yes it would seem that an attack aimed at a target IP address would in-fact now have a greater surface since that IP address is being used by many people. When we remotely-trigger-black-hole (RTBH) route an ip address (/32 host route) into a black hole to stop an attack.... you're right, now you've completed the ddos, not only for one customer, but hundreds or thousands that were using that public ip address through the NAT appliance. ...to which I've told my NOC to not act on any of the /24's-worth of address space the we use for NAT.
Interestingly, the nature of NAT is that it doesn't allow in-bound traffic unless a previous out-bound packet had been sent from customer-side to internet-side and caused the NAT translation to be built.... therefore, an outside-initiated DDoS attack would be automatically blocked by a NAT boundary*. This would cause the DDoS to not go as far as it did in the non-nat scenario. ...so with cgnat you've caused your reach of DDoS to be shortened. ...but of course this doesn't cause the DDoS to not occur and to not reach the NAT boundary...the attack still arrives. You have to continue with other layers of security, defense and mitigation in other areas/layers of your network.
- Aaron
* (I guess unless they were able to guess-spoof the exact ip address and port number of an existing nat session, but then it would seem that they would only reach that same port-address-translated session destination...which I think would be a single ip address endpoint and port number)
-- *Ed Lopez* | *Security Architect* ed.lopez@corsa.com |11 Hines Rd (suite 203) | Ottawa, Ontario K2K 2X1 Canada Mobile +1.703.220.0988 | www.corsa.com *Provide line-rate mitigation against DDoS attacks using the Corsa NSE7000 Series. <https://www.corsa.com/red-armor-security/nse7000/>* *Learn how to make your network better with Corsa Performance SDN <http://www.corsa.com/sdn-done-right/>. * *This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments and delete this message and any attachments immediately.*