Re: QUIC traffic throttled on AT residential

[Łukasz Bromirski]

At this pace and having adopted CI/CD methodology, we may QUICkly run out of 
UDP ports to use.

I’d actually switch to ICMP. Type 8 code 0 and Type 0, code 0. Then staging a 
war on rate-limiters around the world.

Also, 123/udp seems to look interesting ;)

-- 
./

> On 22 Feb 2020, at 00:21, Matthew Petach  wrote:
> 
> 
> 
> 
>> On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski  wrote:
>> 
>> [...]
>> 
>> Now… once we are aware, the only question is — where we go from here?
>> 
>> — 
>> ./
> 
> 
> 
> Well, it's clear the UDP 443 experiment wasn't entirely successful.
> 
> So clearly, it's time to use the one UDP port that is allowed through at the 
> top of everyone's ACL rules, and update QUIC in the next iteration to use 
> UDP/53.
> 
> *THAT* should solve the whole problem, once and for all.
> 
> ;)
> 
> Matt
> 

Re: QUIC traffic throttled on AT residential

[Owen DeLong]

First we moved the entire internet to TCP/443.

Now we propose moving it all to UDP/53.

What’s next? Why not simply eliminate port numbers altogether in favor of a 
single 16-bit client-side unique session identifier.

Owen

> On Feb 21, 2020, at 15:20 , Matthew Petach  wrote:
> 
> 
> 
> On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski  > wrote:
> 
> [...]
> 
> Now… once we are aware, the only question is — where we go from here?
> 
> — 
> ./
> 
> 
> Well, it's clear the UDP 443 experiment wasn't entirely successful.
> 
> So clearly, it's time to use the one UDP port that is allowed through at the 
> top of everyone's ACL rules, and update QUIC in the next iteration to use 
> UDP/53.
> 
> *THAT* should solve the whole problem, once and for all.
> 
> ;)
> 
> Matt
> 

Re: QUIC traffic throttled on AT residential

[Matthew Petach]

On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski  wrote:

>
> [...]
>
> Now… once we are aware, the only question is — where we go from here?
>
> —
> ./
>


Well, it's clear the UDP 443 experiment wasn't entirely successful.

So clearly, it's time to use the one UDP port that is allowed through at
the top of everyone's ACL rules, and update QUIC in the next iteration to
use UDP/53.

*THAT* should solve the whole problem, once and for all.

;)

Matt

[NANOG-announce] NANOG PC Selection

[L Sean Kennedy]

NANOG Community,

Thank you for joining us in San Francisco, and online
,
for NANOG 78!

I am excited to announce that 13 NANOG members accepted appointments to the
Program Committee. 27 highly-qualified volunteers from the NANOG membership
were nominated for this year’s committee selection, so we personally thank
each NANOG member who offered their time and hope they participate in
future committee solicitations.

As an organization, NANOG was founded by volunteers who developed a quality
forum for North America’s operator community. Despite the growth in NANOG’s
programs, volunteers greatly outnumber professional staff, and the
volunteer-only Program Committee (PC) is wholly responsible for soliciting,
developing, and selecting all program content presented at NANOG meetings
and other events.

Please join me in congratulating the appointed PC members:

Aaron Ali Atac, Jason Bothe, Vincent Celindro, Michael Costello, Elizabeth
Culley, Cat Gurinsky, Tom Kacprzynski, John Kristoff, Ognian Mitev, Rekha
Rawat, Michael Voity, Eddy Winstead, and Chris Woodfield.

Please also join me in thanking and recognizing the many contributions of
PC alumni Michaela Clifford, Nagendra Kumar Nainar, Chris Pennisi, and
Steven Schecter.

The PC met and elected the following leaders:

Chair - Vincent Celindro

Vice Chair - Steve Feldman

Secretary - Cat Gurinsky

We are truly excited to see what the community will submit to the PC for
NANOG 79 so please submit talk ideas at
https://nanog.org/meetings/submit-presentation/.


And please join us in June for our first full meeting in Boston if you can!

Thanks,

 Sean

(for the NANOG Board of Directors)
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

NANOG PC Selection

[L Sean Kennedy]

NANOG Community,

Thank you for joining us in San Francisco, and online
,
for NANOG 78!

I am excited to announce that 13 NANOG members accepted appointments to the
Program Committee. 27 highly-qualified volunteers from the NANOG membership
were nominated for this year’s committee selection, so we personally thank
each NANOG member who offered their time and hope they participate in
future committee solicitations.

As an organization, NANOG was founded by volunteers who developed a quality
forum for North America’s operator community. Despite the growth in NANOG’s
programs, volunteers greatly outnumber professional staff, and the
volunteer-only Program Committee (PC) is wholly responsible for soliciting,
developing, and selecting all program content presented at NANOG meetings
and other events.

Please join me in congratulating the appointed PC members:

Aaron Ali Atac, Jason Bothe, Vincent Celindro, Michael Costello, Elizabeth
Culley, Cat Gurinsky, Tom Kacprzynski, John Kristoff, Ognian Mitev, Rekha
Rawat, Michael Voity, Eddy Winstead, and Chris Woodfield.

Please also join me in thanking and recognizing the many contributions of
PC alumni Michaela Clifford, Nagendra Kumar Nainar, Chris Pennisi, and
Steven Schecter.

The PC met and elected the following leaders:

Chair - Vincent Celindro

Vice Chair - Steve Feldman

Secretary - Cat Gurinsky

We are truly excited to see what the community will submit to the PC for
NANOG 79 so please submit talk ideas at
https://nanog.org/meetings/submit-presentation/.


And please join us in June for our first full meeting in Boston if you can!

Thanks,

 Sean

(for the NANOG Board of Directors)

Re: NANOG 78 Webcasts

[Tom Beecher]

To kinda cross this off the list, the videos of all the individual talks
are up on the Team NANOG Youtube channel.



On Sat, Feb 15, 2020 at 10:12 PM Steve Feldman 
wrote:

>
> On Feb 15, 2020, at 6:21 PM, Joly MacFie  wrote:
>
> My guess is that this is some kind of legal red tape, speakers signed off
> for livestream but not VOD. If just one speaker objects, it can take the
> whole thing down.
>
>
> Yes.
>
> As Tom mentioned in an earlier message, there was apparently some
> confusion about which rights were granted for at least one talk.  So to be
> safe the recorded stream was pulled for the time being, until the
> speaker(s) can confirm their intent.  And with post-conference travel and a
> holiday weekend in the U.S., it's unlikely to be resolved until next week.
>
> Steve
>
>

Re: QUIC traffic throttled on AT residential

[Łukasz Bromirski]

Hi Dan!

> On 21 Feb 2020, at 20:22, Dan Wing  wrote:
> 
> There are choices, such as making connection initiation, connection 
> acceptance, and connection termination parsable by network elements on the 
> path so state can be established, maintained, and cleared, DoS can be 
> identified, and so on.  The decision was to hide all that from network 
> elements.

Because monetization of content delivery should be constrained only
for those, that are able to make new standards, while ignoring
openness and cooperation.

Google is the new AOL? With AMP, QUIC and other nice, shiny,
closed and proprietary stuff? Oh, and BTW, please sync your life
with our cloud.

Now… once we are aware, the only question is — where we go from here?

— 
./

Re: [External] Re: QUIC traffic throttled on AT residential

[Ca By]

On Fri, Feb 21, 2020 at 2:22 PM Hunter Fuller  wrote:

> On Fri, Feb 21, 2020 at 2:42 PM Jared Mauch  wrote:
> > I can already hear the QUIC WG types blaming the network in abstentia,
> because well, why would an operator want to keep their network functioning?
> :-)
>
> In fairness, it's not actually functioning. For one thing, it's
> passing some traffic at an abysmal rate. ;)
>

Life and engineering are full of trade-offs.

Re: [External] Re: QUIC traffic throttled on AT residential

[Hunter Fuller]

On Fri, Feb 21, 2020 at 2:42 PM Jared Mauch  wrote:
> I can already hear the QUIC WG types blaming the network in abstentia, 
> because well, why would an operator want to keep their network functioning? 
> :-)

In fairness, it's not actually functioning. For one thing, it's
passing some traffic at an abysmal rate. ;)

Re: QUIC traffic throttled on AT residential

[Jared Mauch]

> On Feb 21, 2020, at 2:22 PM, Dan Wing  wrote:
> 
> There are choices, such as making connection initiation, connection 
> acceptance, and connection termination parsable by network elements on the 
> path so state can be established, maintained, and cleared, DoS can be 
> identified, and so on.  The decision was to hide all that from network 
> elements.

I think those design choices lead directly to these known cases where a UDP 
policer is encountered.  I can drive along the road and not crash into the 
trees, but when I make a choice to deploy something without the proper safety 
equipment and it crashes, blaming the road seems like a poor response.

I can already hear the QUIC WG types blaming the network in abstentia, because 
well, why would an operator want to keep their network functioning? :-)

- Jared

Re: QUIC traffic throttled on AT residential

[Dan Wing]

There are choices, such as making connection initiation, connection acceptance, 
and connection termination parsable by network elements on the path so state 
can be established, maintained, and cleared, DoS can be identified, and so on.  
The decision was to hide all that from network elements.

-d


> On Feb 20, 2020, at 7:54 PM, Matthew Kaufman  wrote:
> 
> 
> 
> On Thu, Feb 20, 2020 at 8:10 AM Ca By  > wrote:
> 
> 
> Not indiscriminate. 
> 
> As Google was informed by network operators all along since 2014, ipv4 UDP is 
> a major uptime threat via DDoS to access networks.  
> ...
> 
> Google choose not to be sensitive to that, they were told where the landmines 
> were, they choose to go on anyhow. 
> 
> 
> It isn’t like they had a choice. You can’t build a transport protocol like 
> QUIC on top of TCP (I know, I built one of its ancestors, which also uses UDP 
> underneath). And if you think getting UDP through existing networks is hard, 
> try using a novel IP protocol number.
> 
> Matthew Kaufman
> 

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 22 Feb, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  797399
Prefixes after maximum aggregation (per Origin AS):  303488
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  389804
Total ASes present in the Internet Routing Table: 67104
Prefixes per ASN: 11.88
Origin-only ASes present in the Internet Routing Table:   57658
Origin ASes announcing only one prefix:   24213
Transit ASes present in the Internet Routing Table:9446
Transit-only ASes present in the Internet Routing Table:284
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  34
Max AS path prepend of ASN (206156)  26
Prefixes from unregistered ASNs in the Routing Table:  1181
Number of instances of unregistered ASNs:  1186
Number of 32-bit ASNs allocated by the RIRs:  30632
Number of 32-bit ASNs visible in the Routing Table:   25219
Prefixes from 32-bit ASNs in the Routing Table:  115818
Number of bogon 32-bit ASNs visible in the Routing Table:22
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:   1138
Number of addresses announced to Internet:   2853607040
Equivalent to 170 /8s, 22 /16s and 150 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.4
Total number of prefixes smaller than registry allocations:  268351

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   210760
Total APNIC prefixes after maximum aggregation:   61530
APNIC Deaggregation factor:3.43
Prefixes being announced from the APNIC address blocks:  204036
Unique aggregates announced from the APNIC address blocks:85081
APNIC Region origin ASes present in the Internet Routing Table:   10346
APNIC Prefixes per ASN:   19.72
APNIC Region origin ASes announcing only one prefix:   2847
APNIC Region transit ASes present in the Internet Routing Table:   1552
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5410
Number of APNIC addresses announced to Internet:  768263168
Equivalent to 45 /8s, 202 /16s and 196 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:234530
Total ARIN prefixes after maximum aggregation:   107780
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   232216
Unique aggregates announced from the ARIN address blocks:117409
ARIN Region origin ASes present in the Internet Routing Table:18404
ARIN Prefixes per ASN:12.62
ARIN 

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Tom Beecher]

It is spoofing, but it is also absolutely amplification. Look at the preso
that Damien linked :
https://www.usenix.org/conference/woot14/workshop-program/presentation/kuhrer

Hope that this doesn't become one of the 'services' that you provide! :)

On Thu, Feb 20, 2020 at 6:40 PM Jean | ddostest.me via NANOG <
nanog@nanog.org> wrote:

> It doesn't sound to be a real amplification.. If it is, can anyone provide
> the amplification factor? 1x?
>
> It sounds more like a TCP spoofing.
>
> Jean
> On 2020-02-20 18:22, Töma Gavrichenkov wrote:
>
> Peace,
>
> On Fri, Feb 21, 2020, 1:57 AM Filip Hruska  wrote:
>
>> [..] OVH has been offering DDOS protection capable of soaking up hundreds
>> of gigabits+ per second as a standard with all their services for a long
>> time
>>
> They only do it for common trivial vectors like UDP-based amplification —
> and other types easily handleable through flowspec.
>
> Which is honestly not their fault because they try to keep their costs
> down.  (Other means to keep the costs down may be of concern of Ronald G.
> though, but that's a different story.)
>
> However, TCP amplification is not of that sort.
>
> --
> Töma
>
>>

MDXi / Lagos

[Chris Knipe]

Hi Guys,

Sorry for the off-topic post.

I would appreciate it if someone that has rack space in MDXi can please
ping me off list.  I just have a few (two or three) random questions that I
would appreciate some general feedback on.

Many thanks,


-- 

Regards,
Chris Knipe

WISPA/ISP around Memphis

[David Funderburk]

We have been contacted by a manufacturing company in Memphis, TN that
needs WIFI installed throughout their plant.  If you work in or around
Memphis and have an interest in this, please contact me off list. 

-- 
Regards,

David Funderburk
GlobalVision
864-569-0703

--
This message has been scanned by E.F.A. Project and is believed to be clean.

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Selphie Keller]

Yeah this type of attack is a pain in the ass to deal with.

Attacker is spoofing your IP addresses to millions of random web servers
all over the Internet that see it as a typical SYN Flood those with
automated reporting are likely blowing up OVH's abuse@ making a pain for
them as well.
However, OVH likely could easily check netflow or some other audit means to
see your server didn't actually send out SYN packets to these servers. They
likely are able to confirm the influx of inbound SYN-ACK packets that can
be up to six depending on the TCP/IP stack of the server.
The others are correct if you send out TCP Reset rejections you can tare
down these bad states on the victim reflector's side to avoid getting retry
SYN-ACK's.

At this point I would consider whatever IP that you have that's getting
attacked as burned, you're best bet is to drop those affected subnets and
get new ones and avoid getting them exposed to whoever is attacking you.

Spoofing issues has been the bane of any operator for years, till all the
ASN's are on board with proper anti spoofing, ddos abuse of spoofing will
be on-going and always an issue.

On Thu, 20 Feb 2020 at 15:18, Octolus Development  wrote:

> A very old attack method called TCP-AMP ( https://pastebin.com/jYhWdgHn )
> has been getting really popular recently.
>
> I've been a victim of it multiple times on many of my IP's and every time
> it happens - My IP's end up getting blacklisted in major big databases. We
> also receive tons of abuse reports for "Port Scanning".
>
> Example of the reports we're getting:
> tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV)
> tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV)
>
> OVH are threatening to kick us off their network, because we are victims
> of this attack. And requesting us to do something about it, despite the
> fact that there is nothing you can do when you are being victim of an DDoS
> Attack.
>
> Anyone else had any problems with these kind of attacks?
>
> The attack basically works like this;
> - The attacker scans the internet for TCP Services, i.e port 80.
> - The attacker then sends spoofed requests from our IP to these TCP
> Services, which makes the remote service attempt to connect to us to
> initiate the handshake.. This clearly fails.
> ... Which ends up with hundreds of request to these services, reporting us
> for "port flood".
>
>
>

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Denys Fedoryshchenko]

Good luck responding to such SYN/ACK, when you get 10+Gbps of them (real 
case happened while ago with colleague).
Sure those SYN/ACK are not from single location, and attackers might use 
whole /24 for SYN spoofing.


On 2020-02-21 03:34, Amir Herzberg wrote:

If I read your description correctly:

- Attacker sends spoofed TCP SYN from your IP address(es) and
different src ports, to some TCP servers (e.g. port 80)
- TCP servers respond with SYN/ACK  ; many servers resend the SYN/ACK
hence amplification .
- *** your system does not respond ***
- Servers may think you're doing SYN-Flood against them, since
connection remains in SYN_RCVD, and hence complain. In fact, we don't
really know what is the goal of the attackers; they may in fact be
trying to do SYN-Flood against these servers, and you're just a
secondary victim and not the even the target, that's also possible.

Anyway, is this the case?

If it is... may I ask, do you (or why don't you) respond to the
unsolicited SYN/ACK with RST as per the RFC?

I suspect you don't, maybe due to these packets being dropped by
FW/NAT, that's quite common. But as you should understand by now from
my text, this (non-standard) behavior is NOT recommended. The problem
may disappear if you reconfigure your FW/NAT (or host) to respond with
RST to unsolicited SYN/ACK.

As I explained above, if my conjectures are true, then OVH as well as
the remote servers may have a valid reason to consider you either as
the attacker or as an (unknowning, perhaps) accomplice.

I may be wrong - sorry if so - and would appreciate, in any case, if
you can confirm or clarify, thanks.

--
Amir Herzberg

Comcast professor of Security Innovations, University of Connecticut

Homepage: https://sites.google.com/site/amirherzberg/home

Foundations of Cyber-Security (part I: applied crypto, part II:
network-security):
https://www.researchgate.net/project/Foundations-of-Cyber-Security

On Thu, Feb 20, 2020 at 5:23 PM Octolus Development
 wrote:


A very old attack method called TCP-AMP (
https://pastebin.com/jYhWdgHn ) has been getting really popular
recently.

I've been a victim of it multiple times on many of my IP's and every
time it happens - My IP's end up getting blacklisted in major big
databases. We also receive tons of abuse reports for "Port
Scanning".

Example of the reports we're getting:

tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV)
tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV)

OVH are threatening to kick us off their network, because we are
victims of this attack. And requesting us to do something about it,
despite the fact that there is nothing you can do when you are being
victim of an DDoS Attack.

Anyone else had any problems with these kind of attacks?

The attack basically works like this;
- The attacker scans the internet for TCP Services, i.e port 80.
- The attacker then sends spoofed requests from our IP to these TCP
Services, which makes the remote service attempt to connect to us to
initiate the handshake.. This clearly fails.
... Which ends up with hundreds of request to these services,
reporting us for "port flood".

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Amir Herzberg]

hhh well Damian, Ok, I guess a free service has some costs :)

More seriously, did you try to follow up and explain how dropping your RST
packets may be exactly the reason for the attacker to abuse your IP space
for the attack? Also, you may ask the provider of the victim to block SYN
packets from your IP range (assuming the victim isn't some service that
your clients will want to access). If all fails then all failed.
-- 
Amir Herzberg

Comcast professor of Security Innovations, University of Connecticut

Homepage: https://sites.google.com/site/amirherzberg/home

Foundations of Cyber-Security (part I: applied crypto, part II:
network-security):
https://www.researchgate.net/project/Foundations-of-Cyber-Security



On Thu, Feb 20, 2020 at 11:21 PM Damian Menscher  wrote:

> Amir: you're exactly correct -- but since you asked, here's their answer
> from the last time I suggested they respond with RSTs:
> https://seclists.org/nanog/2020/Jan/612
>
> Damian
>
> On Thu, Feb 20, 2020 at 5:36 PM Amir Herzberg 
> wrote:
>
>> If I read your description correctly:
>>
>> - Attacker sends spoofed TCP SYN from your IP address(es) and different
>> src ports, to some TCP servers (e.g. port 80)
>> - TCP servers respond with SYN/ACK  ; many servers resend the SYN/ACK
>> hence amplification .
>> - *** your system does not respond ***
>> - Servers may think you're doing SYN-Flood against them, since connection
>> remains in SYN_RCVD, and hence complain. In fact, we don't really know what
>> is the goal of the attackers; they may in fact be trying to do SYN-Flood
>> against these servers, and you're just a secondary victim and not the even
>> the target, that's also possible.
>>
>> Anyway, is this the case?
>>
>> If it is... may I ask, do you (or why don't you) respond to the
>> unsolicited SYN/ACK with RST as per the RFC?
>>
>> I suspect you don't, maybe due to these packets being dropped by FW/NAT,
>> that's quite common. But as you should understand by now from my text, this
>> (non-standard) behavior is NOT recommended. The problem may disappear if
>> you reconfigure your FW/NAT (or host) to respond with RST to unsolicited
>> SYN/ACK.
>>
>> As I explained above, if my conjectures are true, then OVH as well as the
>> remote servers may have a valid reason to consider you either as the
>> attacker or as an (unknowning, perhaps) accomplice.
>>
>> I may be wrong - sorry if so - and would appreciate, in any case, if you
>> can confirm or clarify, thanks.
>>
>> --
>> Amir Herzberg
>>
>> Comcast professor of Security Innovations, University of Connecticut
>>
>> Homepage: https://sites.google.com/site/amirherzberg/home
>>
>> Foundations of Cyber-Security (part I: applied crypto, part II:
>> network-security):
>> https://www.researchgate.net/project/Foundations-of-Cyber-Security
>>
>>
>>
>> On Thu, Feb 20, 2020 at 5:23 PM Octolus Development 
>> wrote:
>>
>>> A very old attack method called TCP-AMP ( https://pastebin.com/jYhWdgHn )
>>> has been getting really popular recently.
>>>
>>> I've been a victim of it multiple times on many of my IP's and every
>>> time it happens - My IP's end up getting blacklisted in major big
>>> databases. We also receive tons of abuse reports for "Port Scanning".
>>>
>>> Example of the reports we're getting:
>>> tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV)
>>> tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV)
>>>
>>> OVH are threatening to kick us off their network, because we are victims
>>> of this attack. And requesting us to do something about it, despite the
>>> fact that there is nothing you can do when you are being victim of an DDoS
>>> Attack.
>>>
>>> Anyone else had any problems with these kind of attacks?
>>>
>>> The attack basically works like this;
>>> - The attacker scans the internet for TCP Services, i.e port 80.
>>> - The attacker then sends spoofed requests from our IP to these TCP
>>> Services, which makes the remote service attempt to connect to us to
>>> initiate the handshake.. This clearly fails.
>>> ... Which ends up with hundreds of request to these services, reporting
>>> us for "port flood".
>>>
>>>
>>>