CGNAT

Thu Feb 7 20:03:09 UTC 2019

Hi, I would suggest that you test fragmented traffic as well to your NAT device.  Fragment packets (that are not the first packet) don't have the L4 info so the NAT device will have to keep them in memory until the first fragment comes in w/ the L4 info.  This can cause a DoS condition if the NAT device doesn't adequately prune fragmented packets from the memory when there is a flood of these type of packets.

On 2/7/19, 11:47 AM, "Aaron Gould" <aaron1 at gvtc.com> wrote:

    Rich, et al, 

    Circling back on some older threads... I'm doing this because I've been
    growing my cgnat environments and needing to remind myself of somethings,
    etc...

    If an attack is targeted at 1 ip address, you would think that if
    would/could affect all the napt-44 (nat overloaded/pat'd) ip's that hide
    behind it... but isn't that *IF* that traffic actually got through the nat
    boundary and flowed to the intended target(s) ?

    Unsolicited outside---->inside traffic I believe results in a deny of
    traffic... and I'm seeing that the nat actually builds those flows as drop
    flows....

    I generated some traffic at a nat destination and I see all my traffic is
    "Drop"... now I wonder if this is a fast path like in asic (pfe) hardware
    being dropped... if so, it would seem that the nat boundary is yet a really
    nice way to quickly drop unsolicited inbound traffic from perhaps bad
    sources.

    My source where I was generating traffic... Hollywood-ip (only works in the
    movies) 256.256.191.133 (bad guy)

    Nat destination where I sending traffic to... 256.256.130.4 (victim/target)

    Now of course the resources/network outside the nat is bogged down, but the
    inside nat domain seems to be unaffected in this case from what I can tell.

    And again, I'm wondering if that "Drop" flow is lightweight/fast processing
    for the ms-mpc-128g juniper gear ?

    {master}
    agould at 960> show services sessions destination-prefix 256.256.130.4/32 |
    grep 256.256.191.133 | refresh 1
    ---(refreshed at 2019-02-07 12:36:45 CST)---
    ---(refreshed at 2019-02-07 12:36:46 CST)---
    ---(refreshed at 2019-02-07 12:36:47 CST)---
    ---(refreshed at 2019-02-07 12:36:48 CST)---
    ---(refreshed at 2019-02-07 12:36:49 CST)---
    ---(refreshed at 2019-02-07 12:36:50 CST)---
    ---(refreshed at 2019-02-07 12:36:51 CST)---
    ---(refreshed at 2019-02-07 12:36:52 CST)---
    TCP        256.256.191.133:54519  ->      256.256.130.4:443    Drop     O
    1
    ICMP       256.256.191.133        ->      256.256.130.4        Drop     O
    1
    ---(refreshed at 2019-02-07 12:36:53 CST)---
    TCP        256.256.191.133:54519  ->      256.256.130.4:443    Drop     O
    1
    ICMP       256.256.191.133        ->      256.256.130.4        Drop     O
    1
    ---(refreshed at 2019-02-07 12:36:54 CST)---
    TCP        256.256.191.133:54519  ->      256.256.130.4:443    Drop     O
    1
    ICMP       256.256.191.133        ->      256.256.130.4        Drop     O
    1
    ---(refreshed at 2019-02-07 12:36:55 CST)---
    TCP        256.256.191.133:54519  ->      256.256.130.4:443    Drop     O
    1
    ICMP       256.256.191.133        ->      256.256.130.4        Drop     O
    1
    ---(refreshed at 2019-02-07 12:36:56 CST)---
    ---(refreshed at 2019-02-07 12:36:57 CST)---
    ---(refreshed at 2019-02-07 12:36:58 CST)---
    UDP        256.256.191.133:12998  ->      256.256.130.4:80     Drop     O
    1
    UDP        256.256.191.133:24444  ->      256.256.130.4:80     Drop     O
    1
    ---(refreshed at 2019-02-07 12:36:59 CST)---
    UDP        256.256.191.133:12998  ->      256.256.130.4:80     Drop     O
    1
    UDP        256.256.191.133:24444  ->      256.256.130.4:80     Drop     O
    1
    ---(refreshed at 2019-02-07 12:37:00 CST)---
    UDP        256.256.191.133:12998  ->      256.256.130.4:80     Drop     O
    1
    UDP        256.256.191.133:24444  ->      256.256.130.4:80     Drop     O
    1
    ---(refreshed at 2019-02-07 12:37:01 CST)---
    UDP        256.256.191.133:12998  ->      256.256.130.4:80     Drop     O
    1
    UDP        256.256.191.133:24444  ->      256.256.130.4:80     Drop     O
    1

    - Aaron

    -----Original Message-----
    From: Compton, Rich A [mailto:Rich.Compton at charter.com] 
    Sent: Thursday, April 6, 2017 3:49 PM
    To: Aaron Gould; 'Ahmed Munaf'; 'Nanog at Nanog'
    Subject: Re: CGNAT

    Hi Aaron, thanks for the info.  I¹m curious what you or others do about
    DDoS attacks to CGNAT devices.  It seems that a single attack could affect
    the thousands of customers that use those devices.  Also, do you have
    issues detecting attacks vs. legitimate traffic when you have so much
    traffic destined to a small group of IPs?

    Rich Compton  |      Principal Eng     |  314.596.2828
    14810 Grasslands  Dr,    Englewood,      CO    80112

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.