These packets were catured in our inside interface, and came in because have SIP open to the world for some bizarre reason. The host 188.8.131.52 did not have a SIP service running on it, I don't know why it was chosen as a target. What was actually killing our ASA was not the packets themselves, but that it was setting up a connection for each incoming packet. Output from "show conn":
UDP out 127.0.0.1:5066 in 184.108.40.206:0 idle 0:00:05 flags ti UDP out 220.127.116.11:5066 in 18.104.22.168:0 idle 0:00:05 flags ti
There were actually many more connections to 127.0.0.1 than to 22.214.171.124. Anyway, we took the 126.96.36.199 host down, cleared the arp table and put in a block for 188.8.131.52 and that took care of it.
What is strange though, is that even though 184.108.40.206 is gone and cleared from the arp table, if a remove the acces-list rule blocking 220.127.116.11 and let it start spewing SIP packets at the now-nonexistent host 18.104.22.168, it still DoSes the ASA with bogus connections:
UDP out 127.0.0.1:5066 in 22.214.171.124:0 idle 0:00:19 flags ti UDP out 127.0.0.1:5066 in 126.96.36.199:0 idle 0:00:19 flags ti UDP out 127.0.0.1:5066 in 188.8.131.52:0 idle 0:00:19 flags ti
There is still no arp entry for 184.108.40.206 and as far as I can tell these connections are "internal" to the ASA.
Is there a way to get the ASA to not attempt to create these connections? So far, I have been unable to capture any packets now that host 220.127.116.11 is gone. Also, I am mystified by what "18.104.22.168:0" (port 0?) could mean.
The port 0 connections are created bye the SIP inspection as secondary connections to the initial SIP connection. These connections are usually for some voice traffic and are build with a port of 0 indicating that they are the half-open inspection generated connections. Outside of blocking this traffic (which yout should so if that host has no SIP functionality), there isn't much we can do to prevent this at this time. I would highly suggest opening a Service-request for this one so that we can investigate the issue a bit more thoroughly. Once you open that case, please message me the SR number so I can track it.