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 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.lo...@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.*
