Re: SOVC - BGp RPKI

[Compton, Rich via NANOG]

I think it hallucinated.
When asked to site its sources:

“I apologize for the confusion, but my response about "SOVC" in the context of 
RPKI on Cisco routers was based on general knowledge of RPKI and networking 
principles, not from a specific source. The explanation combined standard 
practices and concepts in network security and routing, especially as they 
relate to RPKI and BGP.
Since the acronym "SOVC" is not a standard or widely recognized term in the 
context of RPKI, it's possible that it might be specific to certain 
environments or proprietary to certain Cisco router models or software 
versions. For the most accurate and detailed information, it's always best to 
consult the official Cisco documentation or support resources, especially for 
terms that might be specific to their products.”

From: NANOG  on behalf of 
Justin H. 
Date: Wednesday, January 31, 2024 at 3:06 PM
To: NANOG list 
Subject: Re: SOVC - BGp RPKI
I'd be curious to know why it thinks that the S is "Stale".  I don't
suppose it cites its sources?

Compton, Rich via NANOG wrote:
>
> ChatGPT says:
>
> SOVC in the context of RPKI (Resource Public Key Infrastructure) on a
> Cisco router stands for "Stale Origin Validation Cache". RPKI is a
> security framework designed to secure the Internet's routing
> infrastructure, primarily through route origin validation. It ensures
> that the Internet number resources (like IP addresses and AS numbers)
> are used by the legitimate owners or authorized AS (Autonomous System).
>
> In RPKI, Route Origin Authorizations (ROAs) are used to define which
> AS is authorized to announce a specific IP address block. Network
> devices, like Cisco routers, use these ROAs to validate the
> authenticity of BGP (Border Gateway Protocol) route announcements.
>
> The term "stale" in SOVC refers to a situation where the router's
> RPKI-to-Router protocol client has lost its connection to the RPKI
> server, or when the RPKI cache data is outdated and not refreshed for
> some reason. This can happen due to network issues, configuration
> errors, or problems with the RPKI server itself. When the RPKI cache
> is stale, the router cannot reliably validate BGP route announcements
> against the latest ROA data, potentially affecting routing decisions.
>
> In a network security context, maintaining an up-to-date RPKI cache is
> crucial for ensuring that the network only accepts legitimate routing
> announcements, thereby reducing the risk of routing hijacks or
> misconfigurations. As a network security engineer, managing and
> monitoring the RPKI status on routers is an important aspect of
> ensuring network security and integrity.
>
> I see it mentioned in this doc:
>
> https://urldefense.com/v3/__https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf__;!!CQl3mcHX2A!EB5iIYDDpnRMSM7Gjvy11sMoEsjEDlXtTpfipi4l735bx04IY-dD73vWGCbiDZvoRR6kTse35whqa8dH1cN_Ya9j$<https://urldefense.com/v3/__https:/www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf__;!!CQl3mcHX2A!EB5iIYDDpnRMSM7Gjvy11sMoEsjEDlXtTpfipi4l735bx04IY-dD73vWGCbiDZvoRR6kTse35whqa8dH1cN_Ya9j$>
>
> *From: *NANOG  on
> behalf of Mohammad Khalil 
> *Date: *Wednesday, January 31, 2024 at 10:35 AM
> *To: *NANOG list 
> *Subject: *SOVC - BGp RPKI
>
> Greetings Am have tried to find out what is the abbreviation for SOVC
> with no luck. #sh bgp ipv4 unicast rpki servers  BGP SOVC neighbor is
> X. X. X. 47/323 connected to port 323 Anyone have encountered this?
> Thanks! ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
>
> Greetings
>
> Am have tried to find out what is the abbreviation for SOVC with no luck.
>
> #sh bgp ipv4 unicast rpki servers
>
> BGP SOVC neighbor is X.X.X.47/323 connected to port 323
>
> Anyone have encountered this?
>
> Thanks!
>

Re: SOVC - BGp RPKI

[Compton, Rich via NANOG]

ChatGPT says:
SOVC in the context of RPKI (Resource Public Key Infrastructure) on a Cisco 
router stands for "Stale Origin Validation Cache". RPKI is a security framework 
designed to secure the Internet's routing infrastructure, primarily through 
route origin validation. It ensures that the Internet number resources (like IP 
addresses and AS numbers) are used by the legitimate owners or authorized AS 
(Autonomous System).
In RPKI, Route Origin Authorizations (ROAs) are used to define which AS is 
authorized to announce a specific IP address block. Network devices, like Cisco 
routers, use these ROAs to validate the authenticity of BGP (Border Gateway 
Protocol) route announcements.
The term "stale" in SOVC refers to a situation where the router's 
RPKI-to-Router protocol client has lost its connection to the RPKI server, or 
when the RPKI cache data is outdated and not refreshed for some reason. This 
can happen due to network issues, configuration errors, or problems with the 
RPKI server itself. When the RPKI cache is stale, the router cannot reliably 
validate BGP route announcements against the latest ROA data, potentially 
affecting routing decisions.
In a network security context, maintaining an up-to-date RPKI cache is crucial 
for ensuring that the network only accepts legitimate routing announcements, 
thereby reducing the risk of routing hijacks or misconfigurations. As a network 
security engineer, managing and monitoring the RPKI status on routers is an 
important aspect of ensuring network security and integrity.



I see it mentioned in this doc:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf


From: NANOG  on behalf of 
Mohammad Khalil 
Date: Wednesday, January 31, 2024 at 10:35 AM
To: NANOG list 
Subject: SOVC - BGp RPKI
Greetings Am have tried to find out what is the abbreviation for SOVC with no 
luck. #sh bgp ipv4 unicast rpki servers  BGP SOVC neighbor is X. X. X. 47/323 
connected to port 323 Anyone have encountered this? Thanks! ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

Greetings
Am have tried to find out what is the abbreviation for SOVC with no luck.

#sh bgp ipv4 unicast rpki servers
BGP SOVC neighbor is X.X.X.47/323 connected to port 323

Anyone have encountered this?

Thanks!

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Compton, Rich A]

No, Charter doesn't use those.  Charter runs its own anycasted recursive 
nameservers.

On 10/30/23, 2:46 PM, "NANOG on behalf of Livingood, Jason via NANOG" 
mailto:charter@nanog.org> on behalf of nanog@nanog.org 
> wrote:


CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.


On 10/30/23, 16:02, "John R. Levine" mailto:jo...@iecc.com> 
>> wrote:


> I have no idea whether Charter uses one of these, some other third party, 
or their own. 


They don't use those providers as far as I am aware. I've alerted someone from 
CHTR of this thread. 


JL







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.

Re: [EXTERNAL] Re: Charter DNS servers returning invalid IP addresses

[Compton, Rich A]

VirusTotal and other domain reputation sites say the domain is malicious.  
Specifically there have been multiple malware samples that were scanned (latest 
was 10-09-2023) that had this domain hard coded in it. 
https://www.virustotal.com/gui/domain/bonesinjars.com
You may want to get a new domain.  Other option is to contact Akamai and see if 
they can whitelist this domain.  Charter uses threat intel from Akamai to block 
certain "malicious" domains.

-Rich


On 10/25/23, 1:54 PM, "NANOG on behalf of Bryan Fields" 
mailto:charter@nanog.org> on behalf of br...@bryanfields.net 
> wrote:


CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.


On 10/25/23 2:41 PM, Greg Dickinson wrote:
> If it helps troubleshooting, when I click the domain in the email Mimecast
> tells me:
> 
> “We checked the website you are trying to access for malicious and
> spear-phishing content and found it likely to be unsafe.”


I saw nothing referencing Mimecast in the original email. Where did you see 
this?


bonesinjars.com is not signed with DNSSEC. This is trivial to setup and might 
prevent some of this.


Probably not a good idea for your customers to rely on $BIGCABLE DNS servers.
-- 
Bryan Fields


727-409-1194 - Voice
http://bryanfields.net 





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.

Re: [EXTERNAL] Re: BCP38 For BGP Customers

[Compton, Rich A]

Hi Joel, can you please point us to the IETF draft document that describes how 
a "combination of ASPA and RPKI can be used to help with DDoS prevention".  I 
was not able to find it. 
Thanks!
-Rich

On 11/8/22, 8:05 AM, "NANOG on behalf of Joel Halpern" 
 wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

There is work a tthe IETF on an addon to RPKI called ASPA.  There is a 
draft that describes how the combiantion of ASPA and RPKI can be used to 
help with DDOS prevention.

There is also a working group at the IETF called SAVNET that is looking 
at what technological additions can be made to address the shortcomings 
in BCP 38.  In fairness, there is distinct disagreement as to what those 
shortcomings are, and whether the ideas being presented can help.  Input 
from more operators would be great.  (For completeness, I am a co-chair 
of that working group.)

Yours,

Joel

On 11/8/2022 9:39 AM, Brian Turnbow via NANOG wrote:
> Hi Mike
>
>
>
>> This may not exist yet, but what about a uRPF-like feature that uses 
RPKI, IRR, etc. instead of current BGP feed?
>
> There is rfc8704 that extends urpf
> But I do not know of any commercial available solutions
>
>
> Brian

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.

Re: [EXTERNAL] Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Compton, Rich A]

DDoS traffic coming from legit/botted sources that is not spoofed is not DDoS 
amplification.  DDoS amplification requires spoofing.  If everyone did 
BCP38/84, there would be no DDoS amplification attacks.  

-Rich

On 10/4/22, 1:14 PM, "NANOG on behalf of Robert Blayzor via NANOG" 
 
wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

On 10/4/22 09:19, Mike Hammett wrote:
> Sorta like in the IP world, if everyone did BCP38/84, amplification 
> attacks wouldn't exist. Not everyone does, so...


Wouldn't exist? Maybe only in part, BCP38/84 does nothing for a majority 
of DDoS amp attacks. Most traffic is coming from legit/botted sources.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/


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.

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Compton, Rich A]

I was under the impression that ASPA could prevent route leaks as well as path 
spoofing.  This "BGP Route Security Cycling to the Future!" presentation from 
NANOG seems to indicate this is the case: https://youtu.be/0Fi2ghCnXi0?t=1093
Also, can't the path spoofing protection that BGPsec provides be defeated by an 
attacker advertising a hijacked prefix with a forged AS_PATH without BGPsec?  
In order to get around this vulnerability, all of the Internet would have to 
only perform BGPsec which doesn't seem realistic.  Security solutions where 
everyone has to implement the control before it works effectively are rarely 
adopted.

-Rich

On 8/23/22, 2:49 AM, "NANOG on behalf of Job Snijders via NANOG" 
 
wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

Dear Siyuan, others,

Thank you for the elaborate write-up and the log snippets. You
contributed a comprehensive overview of what transpired from a
publicly-visible perspective, what steps led up to the strike.

I want to jump in on one small point which I often see as a point of
confusion in our industry:

On Tue, Aug 23, 2022 at 01:54:50AM +0200, Siyuan Miao wrote:
> Nowadays hijacking a service by forging AS path is pretty easy and
> RPKI won't be able to solve this (as it validates origin AS and
> prefixes only) :-(

I do think RPKI can help solve this! The "RPKI" is a cryptographically
secured distributed database of authorizations for Internet Resource
Numbers (IP addresses & AS numbers). (((yikes, that's a mouthful :-)))

Another way of looking at the RPKI is as a "general purpose framework",
a framework on top of which the Internet community can build multiple
"applications". These applications include:

A) Route Origin Validation (aka "BGP Prefix Origin Validation", RFC 6811)
B) BGPSec (AS Path validation, RFC 8205)
C) ASPA (draft-ietf-sidrops-aspa-{profile,verification}, combating
 routeleaks by publishing what ASNs are your upstreams)
D) .. and others: https://datatracker.ietf.org/wg/sidrops/documents/

Nowadays Item A ("BGP Origin Validation") is widely deployed: all major
IP Transit carriers & major IX Route Server operators use RPKI ROAs to
filter out BGP announcements which have the wrong BGP Origin AS in the
AS_PATH. This is fantastic (and relatively recent) news!

Item B ("BGPsec") and C ("ASPA") are "work in progress": people are
building software, running experiments, studying what it would take to
get those technologies deployed in the wild (the 'production Internet'). 

BGPSec and ASPA are complementary solutions, each has its challenges and
opportunities. BGPsec prevents path spoofing, while ASPA can prevent
route leaks. These are similar but not identical threats that are often
conflated. ASPA and BGPsec should not be thought of as mutually
exclusive or incompatible; both of these technologies will support
routing security in the long term.

I recently co-authored an elaboration to the FCC on where the industry
stands and how some technologies relate to each other, this might be of
interest to some folks:

https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf

Kind regards,

Job


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.

Re: [EXTERNAL] Re: Free-ish Linux Netflow collector/analyser options

[Compton, Rich A]

The ELK stack does a good job of collecting netflow records with the addition 
of Filebeat.  Check out my tattle-tale tool that collects netflow data: 
https://github.com/racompton/tattle-tale It has numerous rules in 
logstash/conf.d to try to just look for spoofed DDoS amplification requests but 
if you remove those rules (except for 
40-ifName.conf
and 
50-reverse-dns.conf)
 it should be a pretty nice netflow collection solution.  If you are looking 
for a free solution to identify DDoS attacks from netflow and generate Flowspec 
rules, check out https://github.com/pavel-odintsov/fastnetmon
Also, here’s a doc for best practices when implementing Flowspec: 
https://www.m3aawg.org/flowspec-BP

-Rich

From: NANOG  on behalf of Joe 
Loiacono 
Date: Monday, May 16, 2022 at 1:11 PM
To: NANOG list , Matthew Crocker 
Subject: [EXTERNAL] Re: Free-ish Linux Netflow collector/analyser options

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.

Try FlowViewer (analyzing, graphing, tending software) + SiLK (robust, 
high-performance capture software from Carnegie-Mellon).

Pretty full netflow analysis package; free.

See: http://flowviewer.net

Joe
On 5/16/2022 2:34 PM, Matthew Crocker wrote:

I’m looking for a free-ish Linux open sources Netflow collector/analyser.  I 
have 5 Juniper MX routers that will send IPFIX flows to for an ISP network.
I’m hoping it is something I can run in AWS/EC2 as I don’t want to worry about 
storage again in my lifetime.  Does anyone have any recommendations?

For reporting I would like to generate basic  usage reports to/from 
IP/Subnet/ASN.  It would be great if it could also detect DDoS and activate 
flowspec back into my core routers but that isn’t a requirement

Thanks

-Matt

Re: [EXTERNAL] Re: Flow collection and analysis

[Compton, Rich A]

Elastiflow is pretty cool.  https://www.elastiflow.com  or the old open source 
version: https://github.com/robcowart/elastiflow
You can pretty much do the same thing with Elastic’s filebeat 
(https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-netflow.html).
Pmacct is also good for grabbing netflow http://www.pmacct.net  and sending it 
somewhere (file, database, kafka, etc.) You can also grab BMP and streaming 
telemetry with it.
If you’re looking for open source DDoS detection using netflow, check out 
https://github.com/pavel-odintsov/fastnetmon
Shameless plug, check out my tool to look for spoofed UDP amplification request 
traffic coming into your network https://github.com/racompton/tattle-tale
FYI, you can send netflow to multiple collectors with 
https://github.com/sleinen/samplicator

-Rich

From: NANOG  on behalf of 
David Bass 
Date: Tuesday, January 25, 2022 at 11:06 AM
To: Christopher Morrow 
Cc: NANOG list 
Subject: [EXTERNAL] Re: Flow collection and analysis

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
Most of these things, yes.

Add:
Troubleshooting/operational support
Customer reporting




On Tue, Jan 25, 2022 at 1:38 PM Christopher Morrow 
mailto:morrowc.li...@gmail.com>> wrote:


On Tue, Jan 25, 2022 at 10:53 AM David Bass 
mailto:davidbass...@gmail.com>> wrote:
Wondering what others in the small to medium sized networks out there are using 
these days for netflow data collection, and your opinion on the tool?

a question not asked, and answer not provided here, is:
  "What are you actually trying to do with the netflow?"

Answers of the form:
  "Dos detection and mitigation planning"
  "Discover peering options/opportunities"
  "billing customers"
  "traffic analysis for future network planning"
  "abuse monitoring/management/investigations"
  "pretty noc graphs"

are helpful.. I'm sure other answers would as well.. but: "how do you collect?" 
is "with a collector" and isn't super helpful if the collector can't feed into 
the tooling / infrastructure / long-term goal you have.
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.

Re: [EXTERNAL] Re: VoIP Provider DDoSes

[Compton, Rich A]

FYI, UTRS (Unwanted Traffic Removal Service 
https://team-cymru.com/community-services/utrs/) from Team Cymru is a free 
service where you can send a blackhole advertisement (sacrificing the one IP 
that’s under attack to save the rest of the network) and they will propagate 
that via BGP to hundreds of other ASNs which will then blackhole traffic to 
that IP.  This can drastically reduce the amount of DDoS traffic that is 
received by the victim network.

-Rich

From: NANOG  on behalf of 
Mike Hammett 
Date: Wednesday, September 22, 2021 at 9:29 AM
To: Terrance Devor 
Cc: NANOG list 
Subject: [EXTERNAL] Re: VoIP Provider DDoSes

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
Fail2Ban on a couple of dozen servers may not be sufficient to address 400 gigs 
of traffic.


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Terrance Devor" 
To: "Mike Hammett" 
Cc: "NANOG" 
Sent: Wednesday, September 22, 2021 10:24:07 AM
Subject: Re: VoIP Provider DDoSes
Fail2Ban and give ourselves a pat on the back..

On Wed, Sep 22, 2021 at 9:12 AM Mike Hammett 
mailto:na...@ics-il.net>> wrote:
https://twit.tv/shows/security-now/episodes/837?autostart=false


It looks like Security Now covered this yesterday. They claimed that, "There  
is  currently  no  provider of  large  pipe  VoIP  protocol  DDoS  protection."

Are any of the cloud DDoS mitigation services offering a service like this.

From: "Mike Hammett" mailto:na...@ics-il.net>>
To: "NANOG" mailto:nanog@nanog.org>>
Sent: Tuesday, September 21, 2021 4:19:42 PM
Subject: VoIP Provider DDoSes
As many may know, a particular VoIP supplier is suffering a DDoS. 
https://twitter.com/voipms

Are your garden variety DDoS mitigation platforms or services equipped to 
handle DDoSes of VoIP services? What nuances does one have to be cognizant of? 
A WAF doesn't mean much to SIP, IAX2, RTP, etc.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


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.

Re: [EXTERNAL] VoIP Provider DDoSes

[Compton, Rich A]

Something you may want to consider is to put ACLs as far upstream as possible 
from your SBCs and only allow through what you need to the SBCs.  For example, 
apply a filter only permitting UDP 5060 and your RTP port range to your SBCs 
and then blocking everything else.  This is free and should stop a lot of 
common DDoS attacks before they ever get to your SBCs.  Even better if you can 
get your upstream ISP to apply the ACL.  DDoS attack traffic should be dropped 
as close to the source as possible.

-Rich

From: Mike Hammett 
Date: Tuesday, September 21, 2021 at 4:39 PM
To: "Compton, Rich A" 
Cc: NANOG list 
Subject: Re: [EXTERNAL] VoIP Provider DDoSes

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
*nods* We have a Metaswitch SBC.

So as long as the pipe isn't full, an SBC is the buffer one needs? If the pipe 
is filled, pump it through {insert DDoS mitigation service here}?




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Rich A Compton" 
To: "Mike Hammett" , "NANOG" 
Sent: Tuesday, September 21, 2021 4:59:06 PM
Subject: Re: [EXTERNAL] VoIP Provider DDoSes
Most of the larger DDoS mitigation appliances can block malformed SIP traffic 
and also can block volumetric/state exhaustion UDP floods.  A lot of VoIP 
companies have Session Border Controllers (SBCs) to protect public facing VoIP 
services.  SBCs are more application aware.  Kind of like a proxy based 
firewall just for VoIP.

-Rich

From: NANOG  on behalf of 
Mike Hammett 
Date: Tuesday, September 21, 2021 at 3:31 PM
To: NANOG list 
Subject: [EXTERNAL] VoIP Provider DDoSes

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
As many may know, a particular VoIP supplier is suffering a DDoS. 
https://twitter.com/voipms

Are your garden variety DDoS mitigation platforms or services equipped to 
handle DDoSes of VoIP services? What nuances does one have to be cognizant of? 
A WAF doesn't mean much to SIP, IAX2, RTP, etc.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com
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.

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.

Re: [EXTERNAL] VoIP Provider DDoSes

[Compton, Rich A]

Most of the larger DDoS mitigation appliances can block malformed SIP traffic 
and also can block volumetric/state exhaustion UDP floods.  A lot of VoIP 
companies have Session Border Controllers (SBCs) to protect public facing VoIP 
services.  SBCs are more application aware.  Kind of like a proxy based 
firewall just for VoIP.

-Rich

From: NANOG  on behalf of 
Mike Hammett 
Date: Tuesday, September 21, 2021 at 3:31 PM
To: NANOG list 
Subject: [EXTERNAL] VoIP Provider DDoSes

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
As many may know, a particular VoIP supplier is suffering a DDoS. 
https://twitter.com/voipms

Are your garden variety DDoS mitigation platforms or services equipped to 
handle DDoSes of VoIP services? What nuances does one have to be cognizant of? 
A WAF doesn't mean much to SIP, IAX2, RTP, etc.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com
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.

Squat space is now being advertised by AS 749 (DoD Network Information Center)

[Compton, Rich A]

Hi, this week it looks like the DoD owned squat space that was previously 
advertised by AS 8008 (a shadow company called Global Resource Systems, see 
https://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949)
 is now being advertised by AS 749 (DoD Network Information Center).  Does 
anyone have any idea why this change was made?  Is the DoD planning on actually 
legitimately putting services on the space soon instead of using it as a giant 
honeypot?  Or maybe even selling it?

Thanks,
Rich

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.

Re: [EXTERNAL] Re: An update on the AfriNIC situation

[Compton, Rich A]

Can't AfriNIC just create ROAs for the prefixes and point them to AS0?  That 
would pretty much make the prefixes unusable since most tier 1's are doing ROV 
now.

-Rich

On 8/27/21, 10:20 AM, "NANOG on behalf of Aaron Wendel" 
 wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

I suppose people who wanted to take a side could also block traffic to 
and from Cloud Innovations IP blocks.


On 8/27/2021 10:36 AM, Bill Woodcock wrote:
> As many of you are aware, AfriNIC is under legal attack by Heng Lu / 
“Cloud Innovation.”
>
> John Curran just posted an excellent summary of the current state of 
affairs here:
>
> 
https://teamarin.net/2021/08/27/afrinic-and-the-stability-of-the-internet-number-registry-system/
>
> If, like me, you feel like chipping in a little bit of money to help 
AfriNIC make payroll despite Heng having gotten their bank accounts frozen, 
some of the African ISP associations have put together a fund, which you can 
donate to here:
>
> https://www.tespok.co.ke/?page_id=14001
>
> It’s an unfortunate situation, but the African Internet community has 
really pulled together to defend themselves, and they’ve got a lot less 
resources than most of us do.
>
> -Bill


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.

Re: [EXTERNAL] RE: shadowserver.org

[Compton, Rich A]

If you want to identify which peering links are sending you spoofed DDoS 
amplification request traffic and which (Shadowserver identified) IPs in your 
network the traffic is going to, please take a look at my Tattle Tale project: 
https://github.com/racompton/tattle-tale
Identify which peers are sending you the spoofed UDP amplification traffic and 
"encourage" them to follow BCP 38/84! 
The project has this file to identify legitimate scanning traffic: 
https://github.com/racompton/tattle-tale/blob/main/logstash/conf.d/81-filter-scanners.conf

-Rich

On 6/28/21, 1:29 PM, "NANOG on behalf of Jean St-Laurent via NANOG" 
 
wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

Great list. 

ShadowServer is there twice on page 7. They must be noisy 

Jean

-Original Message-
From: NANOG  On Behalf Of Hank 
Nussbacher
Sent: June 28, 2021 2:50 PM
To: nanog@nanog.org
Subject: Re: shadowserver.org

> What is the difference between shodan.io and shadowserver.org ? Jean
Just those 2?  Greynoise maps them all.  See an old preso from 2018:

https://www.slideshare.net/andrewwantsyou/identifying-and-correlating-internetwide-scan-traffic-to-newsworthy-security-events
See slide 7 for a 4 year old list which has only grown :-)

-Hank





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.

Re: [EXTERNAL] Re: Famous operational issues

[Compton, Rich A]

There was the outage in 2014 when we got to 512K routes.  
http://www.bgpmon.net/what-caused-todays-internet-hiccup/


On 2/16/21, 1:04 PM, "NANOG on behalf of Job Snijders via NANOG" 
 
wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

On Tue, Feb 16, 2021 at 01:37:35PM -0600, John Kristoff wrote:
> I'd like to start a thread about the most famous and widespread Internet
> operational issues, outages or implementation incompatibilities you
> have seen.
> 
> Which examples would make up your top three?

This was a fantastic outage, one could really feel the tremors into the
far corners of the BGP default-free zone:


https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/

The experiment triggered a bug in some Cisco router models: affected
Ciscos would corrupt this specific BGP announcement ** ON OUTBOUND **.
Any peers of such Ciscos receiving this BGP update, would (according to
then current RFCs) consider the BGP UPDATE corrupted, and would
subsequently tear down the BGP sessions with the Ciscos. Because the
corruption was not detected by the Ciscos themselves, whenever the
sessions would come back online again they'd reannounce the corrupted
update, causing a session tear down. Bounce ... Bounce ... Bounce ... at
global scale in both IBGP and EBGP! :-)

Luckily the industry took these, and many other lessons to heart: in
2015 the IETF published RFC 7606 ("Revised Error Handling for BGP UPDATE
Messages") which specifices far more robust behaviour for BGP speakers.

Kind regards,

Job


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.

Re: [EXTERNAL] Re: Retalitory DDoS

[Compton, Rich A]

FYI, that looks like a Web Services Dynamic Discovery UDP amplification DDoS 
attack.  
https://blogs.akamai.com/sitr/2019/09/new-ddos-vector-observed-in-the-wild-wsd-attacks-hitting-35gbps.html
  Very easily executed by a booter service.
You may want to have your hosting provider block all inbound traffic from 
reaching your server IP except TCP port 443 (or 80 or whatever port you 
actually use) somewhere upstream.  This can help reduce the impact of DDoS 
attacks on your server.

-Rich

From: NANOG  on behalf of 
Mike Hammett 
Date: Monday, February 8, 2021 at 10:58 AM
To: Jean St-Laurent 
Cc: NANOG list 
Subject: [EXTERNAL] Re: Retalitory DDoS

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
I don't have RTBH, no. It's just a web server.

Now how my hosting provider handled it, I'm not sure. I don't know if they just 
dropped me internally, or if they used RTBH with their upstreams and peers. 
Only being 2.5 gigs, that should be well within their ability to handle 
internally, but I guess why would you if you didn't have to?


-
Mike Hammett
Intelligent Computing Solutions
[Image removed by sender.][Image removed by 
sender.][Image 
removed by 
sender.][Image
 removed by sender.]
Midwest Internet Exchange
[Image removed by sender.][Image removed by 
sender.][Image 
removed by sender.]
The Brothers WISP
[Image removed by sender.][Image 
removed by sender.]

From: "Jean St-Laurent" 
To: "Mike Hammett" 
Cc: "NANOG list" 
Sent: Monday, February 8, 2021 11:53:43 AM
Subject: RE: Retalitory DDoS
You got RTBH?

From: Mike Hammett 
Sent: February 8, 2021 12:50 PM
To: Jean St-Laurent 
Cc: NANOG list 
Subject: Re: Retalitory DDoS

In my case, it was against a server not on my own network, so my impact was a 
blackhole for an hour at 4 AM local time. I likely wouldn't have even noticed 
it, had I not received the threat email, nor the ticket my web host's NOC 
opened.


-
Mike Hammett
Intelligent Computing Solutions
[Image removed by sender.][Image removed by 
sender.][Image 
removed by 
sender.][Image
 removed by sender.]
Midwest Internet Exchange
[Image removed by sender.][Image removed by 
sender.][Image 
removed by sender.]
The Brothers WISP
[Image removed by sender.][Image 
removed by sender.]

From: "Jean St-Laurent" 
To: "Mike Hammett" , "NANOG list" 
Sent: Monday, February 8, 2021 11:42:12 AM
Subject: RE: Retalitory DDoS
Nice report,

If you would have to pick up just one vector out of this “multi-vector” attack, 
which one seems to be the one that had the bigger effect on your network or 
service?

Was it degraded or total service interruption?

Jean

From: NANOG  On Behalf Of Mike Hammett
Sent: February 8, 2021 8:43 AM
To: NANOG list 
Subject: Re: Retalitory DDoS

Mike,

I've attached the full information we got from our DDOS protection system below.

We had a large number of ping loss and data loss tickets begin opening up for 
devices sharing the cabinet chi18-313. The high traffic and interference was 
determined to be caused by incoming traffic to the ip address [Not hard to 
find, but redacted anyway]. Our network engineers will be back in after 9am 
until 5pm CST. They have greater access to the network and may be able to give 
you more details.

Location : Chicago
Event Time : 2021-02-08 04:17:38 CST (-0600)
Destination IP: [Not hard to find, but redacted anyway]
Traffic : 2520 Mbps 382880 pps
Fragmentation : 11%
Top Transport Protocol:
. 99% Protocol # 17 (UDP)
TCP Flag: SYN: 100% ACK: 0% RST: 0% FIN: 0%
Top Source Port:
. 61% Port # 3702
. 38% Port # 0
Top Destination Port:
. 38% Port # 0
. 14% Port # 45934
. 9% Port # 23680
. 8% Port # 35023
. 7% Port # 25966
Top Source IP:
. 0% 112.164.127.17
Number of unique IP: 7110
Total Bytes : 1259961437
Total Packets : 1531559
Duration : 4s
Report Run Time : 151.3ms

The 30 day null route count is: 0
Number of 

Re: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

[Compton, Rich A]

Hi, here is a Flowspec best practices document that I helped write that will 
hopefully help folks from shooting themselves in the foot 
http://m3aawg.org/flowspec-BP.  As you stated, route policies can be applied to 
restrict what type of flowspec rules can or can’t be accepted.  For example, 
only allow a rule from the Flowspec controller if it specifies a /32 
destination IP and is tagged with a particular community, reject all else.
Douglas, I think what you are looking for is DOTS: 
https://tools.ietf.org/html/rfc8811  DOTS has a data channel which allows the 
DOTS client and server to communicate telemetry about the attack.  The RFC is 
pretty new.  I don’t think that there are any companies that have implemented 
it yet.  Hopefully this protocol will be adopted by DDoS mitigation companies 
soon.

-Rich Compton

From: NANOG  on behalf of 
Douglas Fischer 
Date: Tuesday, February 2, 2021 at 10:10 AM
To: Tom Beecher 
Cc: NANOG list 
Subject: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the 
attack will over

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.
Well... That is a point of view!
And I must respect that.

Against this position, there are several companies, including some tier 1, that 
sells this as an $extra$.

About the "Please break me at my earliest inconvenience." part:
I believe that the same type of prefix filtering that applies to 
Downstream-BGP-Routes applies to RTBH and Flowspec.
So, exactly as in common BGP Route-Filtering:
- If the network operator does it correctly, it should work correctly.
- If the network operator deals with that without the needed skills, expertise, 
attention+devotion, wrong things will come up.


But, this still does not helps to find a solution do an organization A that 
sends some flowspec our RTBH to organization B(presuming organization B will 
accept that),  and organization B do some reports of what is match with that 
flowspec or RTBH.

That, in my opinion, is the only way to stop guessing how long will an attack 
will last, and start to define the end of a flowspec/RTBH action based on real 
information related to that.
I want to close the feedback loop.


Em ter., 2 de fev. de 2021 às 13:07, Tom Beecher  escreveu:
Personally, I would absolutely, positively, never ever under any circumstances 
provide access to a 3rd party company to push a FlowSpec rule or trigger RTBH 
on my networks. No way.  You would be handing over a nuclear trigger and saying 
"Please break me at my earliest inconvenience."

On Tue, Feb 2, 2021 at 5:56 AM Douglas Fischer 
mailto:fischerdoug...@gmail.com>> wrote:
OK, but do you know any company the sells de Flowspec as a service, in the way 
that the Attack Identifications are not made by their equipment, just receiving 
de BGP-FlowSpec and applying that rules on that equipments... And even then 
give back to the customer some way to access those statistics?

I just know one or two that do that, and(sadly) they do it on fancy web reports 
or PDFs.
Without any chance of using that as structured data do feedback the anomaly 
detection tools to determine if already it is the time to remove that Flowsperc 
rule.

What I'm looking for is something like:
A) XML/JSON/CSV files streamed to my equipment from the Flowspec Upstream 
Equipments saying "Heepend that, that, and that." Almost in real time.
B) NetFlow/IPFIX/SFlow streamed to my equipment from the Upstream Equipment, 
restricted to the DST-Address that matches to the IP blocks that were involved 
to the Flowspec or RTBH that I Annouced to then.
C) Any other idea that does the job of gives me the visibility of what is 
happening with FlowSpec-rules, or RTBH on theyr network.


Em seg., 1 de fev. de 2021 às 22:07, Dobbins, Roland 
mailto:roland.dobb...@netscout.com>> escreveu:



On Feb 2, 2021, at 00:34, Douglas Fischer 
mailto:fischerdoug...@gmail.com>> wrote:

Or even know if already there is a solution to that and I'm trying to invent 
the wheel.

Many flow telemetry export implementations on routers/layer3 switches report 
both passed & dropped traffic on a continuous basis for DDoS 
detection/classification/traceback.

It's also possible to combine the detection/classification/traceback & flowspec 
trigger functions.

[Full disclosure: I work for a vendor of such systems.]




Roland Dobbins mailto:roland.dobb...@netscout.com>>


--
Douglas Fernando Fischer
Engº de Controle e Automação


--
Douglas Fernando Fischer
Engº de Controle e Automação
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 

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Compton, Rich A]

Good luck with that.    As Damian Menscher has presented at NANOG, even if we 
do an amazing job and shut down 99% of all DDoS reflectors, there will still be 
enough bandwidth to generate terabit size attacks. https://stats.cybergreen.net
I think we need to instead collectively focus on stopping the spoofed traffic 
that allows these attacks to be generated in the first place.
-Rich

From: NANOG Email List  on behalf of Bottiger 

Date: Thursday, April 23, 2020 at 3:32 PM
To: Siyuan Miao 
Cc: NANOG list 
Subject: Re: Best way to get foreign ISPs to shut down DDoS reflectors?

We are unable to upgrade our bandwidth in those areas. There are no providers 
within our budget there at the moment. Surely there must be some way to get 
them to respond.

On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao 
mailto:avel...@misaka.io>> wrote:
It won't work.

Get a good DDoS protection and forget about it.

On Fri, Apr 24, 2020 at 5:17 AM Bottiger 
mailto:bottige...@gmail.com>> wrote:
Is there a guide on how to get foreign ISPs to shut down reflectors used in 
DDoS attacks?

I've tried sending emails listed under abuse contacts for their regional 
registries. Either there is none listed, the email is full, email does not 
exist, or they do not reply. Same results when sending to whatever other email 
they have listed.

Example Networks:

CLARO S.A.
Telefonica
China Telecom
Korea Telecom
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.

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Compton, Rich A]

The answer is “it depends”.  What are you trying to accomplish?  Are you trying 
to detect and surgically mitigate every DDoS attack?  If so, you will need a 
good DDoS attack detection and mitigation solution and a team of people to run 
it or a 3rd party company that can do this for you.  Do you want a cheap 
solution?  There are open source projects that can detect DDoS attacks and 
generate RTBHs, flowspec rules, and inline filters that can block the traffic 
(eg. https://fastnetmon.com).  Also, RTBHs can usually be advertised upstream 
(and to UTRS https://www.team-cymru.com/utrs.html) to reduce the amount of 
attack traffic that the victim network receives.  Some ISPs just do the RTBH to 
the customer’s IP when there’s a DDoS and then force the customer to get 
another IP via DHCP, etc.

-Rich

From: NANOG Email List  on behalf of NANOG list 

Reply-To: Shawn L 
Date: Thursday, April 23, 2020 at 3:39 PM
To: NANOG list 
Subject: Re: Best way to get foreign ISPs to shut down DDoS reflectors?


This brings up an interesting question -- what is "good DDoS protection" on an 
ISP scale?  Apart from having enough bandwidth to weather the attack and having 
upstream providers attempt to filter it for you/




-Original Message-
From: "Bottiger" 
Sent: Thursday, April 23, 2020 5:30pm
To: "Siyuan Miao" 
Cc: "North American Network Operators' Group" 
Subject: Re: Best way to get foreign ISPs to shut down DDoS reflectors?
We are unable to upgrade our bandwidth in those areas. There are no providers 
within our budget there at the moment. Surely there must be some way to get 
them to respond.

On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao 
mailto:avel...@misaka.io>> wrote:
It won't work.
Get a good DDoS protection and forget about it.

On Fri, Apr 24, 2020 at 5:17 AM Bottiger 
mailto:bottige...@gmail.com>> wrote:
Is there a guide on how to get foreign ISPs to shut down reflectors used in 
DDoS attacks?
I've tried sending emails listed under abuse contacts for their regional 
registries. Either there is none listed, the email is full, email does not 
exist, or they do not reply. Same results when sending to whatever other email 
they have listed.
Example Networks:
CLARO S.A.
Telefonica
China Telecom
Korea Telecom
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.

Re: FlowSpec

[Compton, Rich A]

Hi Colton,
It is fairly common to use flowspec internally at an ISP for mitigation of DDoS 
attacks.  eBGP flowspec is not very common though.  I know of only a couple of 
ISPs that allow flowspec rules to be advertised by their customers.  The 
biggest issue with this is that other providers are very hesitant to allow an 
external party to reach into their routers and modify the configuration (add a 
flowspec rule).  I (with others at my company) had attempted to work on this to 
provide a validation mechanism that would be performed on the advertised rules 
before adding them to the router.  We didn’t see much interest at that time on 
this.  https://www.youtube.com/watch?v=rKEz8mXcC7o
From conversations I have had with a couple of large ISPs recently it seems 
like there is an increased interest in this topic.
Here is a document on flowspec best practices that I worked on for M3AAWG that 
may be of interest: 
https://www.m3aawg.org/sites/default/files/m3aawg-flowspec-bp-2019-02.pdf

-Rich

From: NANOG Email List  on behalf of Colton Conor 

Date: Thursday, April 23, 2020 at 9:15 AM
To: NANOG list 
Subject: FlowSpec

Do any of the large transit providers support FlowSpec to transit customers / 
other carriers, or is that not a thing since they want to sell DDoS protection 
services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), 
but I am not sure if  FlowSpec is widely implemented. I see the large router 
manufacturers support it.





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.

Re: UDP/123 policers & status

[Compton, Rich A]

Yes, we still see lots of UDP amplification attacks using NTP monlist.  We use 
a filter to block UDP src 123 packets of 468 bytes in length (monlist reply 
with the max 6 IPs).

-Rich

On 3/17/20, 8:55 AM, "NANOG on behalf of Jared Mauch"  wrote:

I’m curious what people are seeing these days on the UDP/123 policers in 
their networks.

I know while I was at NTT we rolled some out, and there are a number of 
variants that have occurred over the past 6-7 years.  I’ve heard from people at 
the NTP Pool as well as having observed some issues with NTP at Akamai and time 
sync from time to time.

Are you still seeing a lot of NTP attacks in your flows these days?

Should we be looking to remove these, similar to how we did for SQL/Slammer 
after a time?

- Jared

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.

Re: China’s Slow Transnational Network

[Compton, Rich A]

My guess is that it’s all the DDoS traffic coming from China saturating the 
links.

From: NANOG Email List  on behalf of Pengxiong Zhu 

Date: Monday, March 2, 2020 at 8:58 AM
To: NANOG list 
Cc: Zhiyun Qian 
Subject: China’s Slow Transnational Network

Hi all,

We are a group of researchers at University of California, Riverside who have 
been working on measuring the transnational network performance (and have 
previously asked questions on the mailing list). Our work has now led to a 
publication in Sigmetrics 2020 and we are eager to share some
interesting findings.

We find China's transnational networks have extremely poor performance when 
accessing foreign sites, where the throughput is often persistently
low (e.g., for the majority of the daytime). Compared to other countries we 
measured including both developed and developing, China's transnational network 
performance is among the worst (comparable and even worse than some African 
countries).

Measuring from more than 400 pairs of mainland China and foreign nodes over 
more than 53 days, our result shows when data transferring from foreign nodes 
to China, 79% of measured connections has throughput lower than the 1Mbps, 
sometimes it is even much lower. The slow speed occurs only during certain 
times and forms a diurnal pattern that resembles congestion (irrespective of 
network protocol and content), please see the following figure. The diurnal 
pattern is fairly stable, 80% to 95% of the transnational connections have a 
less than 3 hours standard deviation of the slowdown hours each day over the 
entire duration. However, the speed rises up from 1Mbps to 4Mbps in about half 
an hour.

[blob:null/71cf5a6a-3841-41ce-a1d4-207b59182189]

We are able to confirm that high packet loss rates and delays are incurred in 
the foreign-to-China direction only. Moreover, the end-to-end loss rate could 
rise up to 40% during the slow period, with ~15% on average.

There are a few things noteworthy regarding the phenomenon. First of all, all 
traffic types are treated equally, HTTP(S), VPN, etc., which means it is 
discriminating or differentiating any specific kinds of traffic. Second, we 
found for 71% of connections, the bottleneck is located inside China (the 
second hop after entering China or further), which means that it is mostly 
unrelated to the transnational link itself (e.g., submarine cable). Yet we 
never observed any such domestic traffic slowdowns within China.
Assuming this is due to congestion, it is unclear why the infrastructures 
within China that handles transnational traffic is not even capable to handle 
the capacity of transnational links, e.g., submarine cable, which maybe the 
most expensive investment themselves.

Here is the link to our paper:
https://www.cs.ucr.edu/~zhiyunq/pub/sigmetrics20_slowdown.pdf


We appreciate any comments or feedback.
--

Best,
Pengxiong Zhu
Department of Computer Science and Engineering
University of California, Riverside
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.

Any info on devices that are running eBGP on the Internet?

[Compton, Rich A]

Hi, I am working with MANRS (https://www.manrs.org) on a tool for checking 
router configs for BGP security / spoofing prevention (e.g. uRPF) 
https://github.com/manrs-tools/MANRS-validator
We are wondering if there is any research on the percentages of different types 
of devices running BGP on the Internet.
Something like:
Cisco IOS 30%
Junos 30%
Mikrotik 20%
etc…
We are looking to focus our tool on the most prevalent types of devices doing 
BGP (and the most prevalent with BGP security/spoofing issues) so that we can 
have the greatest impact.  Does anyone have any information on this or know 
where I can obtain this information?  Thanks in advance!
 -Rich
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.

Re: AT/as7018 now drops invalid prefixes from peers

[Compton, Rich A]

That's great!  Do you guys have plans to publish ROAs for your own netblocks?  
If so, can you please share info on your process (tools, pitfalls, etc.)?  
Thanks!

On 2/11/19, 7:55 AM, "NANOG on behalf of Jay Borkenhagen" 
 wrote:


FYI:

The AT/as7018 network is now dropping all RPKI-invalid route
announcements that we receive from our peers.  

We continue to accept invalid route announcements from our customers,
at least for now.  We are communicating with our customers whose
invalid announcements we are propagating, informing them that these
routes will be accepted by fewer and fewer networks over time.

Thanks to those of you who are publishing ROAs in the RPKI.  We would
also like to encourage other networks to join us in taking this step
to improve the quality of routing information in the Internet.

Thanks!

Jay B.





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.

Re: CGNAT

[Compton, Rich A]

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"  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@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)---
TCP256.256.191.133:54519  ->  256.256.130.4:443Drop O
1
ICMP   256.256.191.133->  256.256.130.4Drop O
1
---(refreshed at 2019-02-07 12:36:53 CST)---
TCP256.256.191.133:54519  ->  256.256.130.4:443Drop O
1
ICMP   256.256.191.133->  256.256.130.4Drop O
1
---(refreshed at 2019-02-07 12:36:54 CST)---
TCP256.256.191.133:54519  ->  256.256.130.4:443Drop O
1
ICMP   256.256.191.133->  256.256.130.4Drop O
1
---(refreshed at 2019-02-07 12:36:55 CST)---
TCP256.256.191.133:54519  ->  256.256.130.4:443Drop O
1
ICMP   256.256.191.133->  256.256.130.4Drop 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)---
UDP256.256.191.133:12998  ->  256.256.130.4:80 Drop O
1
UDP256.256.191.133:2  ->  256.256.130.4:80 Drop O
1
---(refreshed at 2019-02-07 12:36:59 CST)---
UDP256.256.191.133:12998  ->  256.256.130.4:80 Drop O
1
UDP256.256.191.133:2  ->  256.256.130.4:80 Drop O
1
---(refreshed at 2019-02-07 12:37:00 CST)---
UDP256.256.191.133:12998  ->  256.256.130.4:80 Drop O
1
UDP256.256.191.133:2  ->  256.256.130.4:80 Drop O
1
---(refreshed at 2019-02-07 12:37:01 CST)---
UDP256.256.191.133:12998  ->  256.256.130.4:80 Drop O
1
UDP256.256.191.133:2  ->  256.256.130.4:80 Drop O
1

- Aaron

-Original Message-
From: Compton, Rich A [mailto:rich.comp...@charter.com] 
Sent: Thursday, April 6, 2017 3:49 PM
To: Aaron Gould; 'Ahmed Munaf'; 'Nanog@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 Grass

Re: SP security knowledge build up

[Compton, Rich A]

Barry Greene's site has some good info on ISP security as well: 
http://www.senki.org

On 7/23/18, 8:08 AM, "NANOG on behalf of Christopher Morrow" 
 wrote:

I thought also there was a set of videos from nanog meetings...
I can't find a set, but here are some:

ISP Security 101 primer
https://www.youtube.com/watch?v=ueRminCpnMc

isp security real-world techniques - 2
https://www.youtube.com/watch?v=Ijd9A5wUS_0
https://www.youtube.com/watch?v=T6ZSxgVvjdA (older version of previous?)

ISP Security toolkits
https://www.youtube.com/watch?v=w7XcZS_99WQ

NRIC Best Practices for ISP Security
https://www.youtube.com/watch?v=1bzL5eUGC-0

there are actually quite a few more, searching for 'security nanog' turned
up.

On Mon, Jul 23, 2018 at 9:32 AM Suresh Ramasubramanian 
wrote:

> The usual / canonical sysadmin book might work, there is a lot of security
> related material in there as well.
>
>
> 
https://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668
>
> And this updated for enterprise / devops and other such new fangled things
>
>
> 
https://www.amazon.com/Practice-System-Network-Administration-Enterprise/dp/0321919165/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8=1=2N4F09FPM9FG9VQNT433
>
>
> On 23/07/18, 6:55 PM, "NANOG on behalf of Ramy Hashish"
>  ramy.ihash...@gmail.com> wrote:
>
> Hello All,
>
> I am planning to build up a security team of fresh engineers whom are
> "network oriented", any advice on the knowledge resources we can start
> with? We are looking forward to building a concrete foundation of a
> well-rounded security engineer, we are looking for vendor/operator
> agnostic
> resources.
>
> Thanks,
>
> Ramy
>
>
>
>


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.

Re: BCP38/84 and DDoS ACLs

[Compton, Rich A]

To block UDP port 19 you can add something like:
deny udp any eq 19 any
deny udp any any eq 19

This will prevent the DDoS attack traffic entering your network (source
port 19) as well as the hosts scanning around looking for hosts on your
network that can be used in amplification attacks (destination port 19).
Please note that this will not block the UDP fragments that come with
these attacks which have no L4 port to block.  You can possibly do
policing on UDP fragments to address this.

I¹d also suggest adding:
deny udp any eq 17 any
deny udp any any eq 17

deny udp any eq 123 any packet-length eq 468

deny udp any eq 520 any
deny udp any any eq 520

deny udp any eq 1900 any
deny udp any any eq 1900

Some people will complain that you shouldn¹t block UDP port 1900 because
it¹s above 1023 but believe me it¹s worth it.



also to block invalid source IPs to prevent some spoofed traffic from
coming into your network:

deny ipv4 0.0.0.0 0.255.255.255 any
deny ipv4 10.0.0.0 0.255.255.255 any
deny ipv4 11.0.0.0 0.255.255.255 any
deny ipv4 22.0.0.0 0.255.255.255 any
deny ipv4 30.0.0.0 0.255.255.255 any
deny ipv4 100.64.0.0 0.63.255.255 any
deny ipv4 127.0.0.0 0.255.255.255 any
deny ipv4 169.254.0.0 0.0.255.255 any
deny ipv4 172.16.0.0 0.15.255.255 any
deny ipv4 192.0.0.0 0.0.0.255 any
deny ipv4 192.0.2.0 0.0.0.255 any
deny ipv4 192.168.0.0 0.0.255.255 any
deny ipv4 198.18.0.0 0.1.255.255 any
deny ipv4 198.51.0.0 0.0.0.255 any
deny ipv4 203.0.113.0 0.0.0.255 any
deny ipv4 224.0.0.0 31.255.255.255 any


For BCP38 and 84 you would want to enable uRPF
https://en.wikipedia.org/wiki/Reverse_path_forwarding
https://tools.ietf.org/html/rfc3704



Rich Compton   | Principal Eng |   314.596.2828
14810 Grasslands  Dr,Englewood,  CO80112






On 5/26/17, 11:39 AM, "NANOG on behalf of Graham Johnston"
 wrote:

>I really did try looking before I sent the email but couldn't quickly
>find what I was looking for.
>
>I am looking for information regarding standard ACLs that operators may
>be using at the internet edge of their network, on peering and transit
>connections, wherein you are filtering ingress packets such as those
>sourced from UDP port 19 for instance. I've found incomplete conceptual
>discussions about it nothing that seemed concrete or complete.
>
>This doesn't seem quite like it is BCP38 and more like this is BCP84, but
>it only talks about use of ACLs in section 2.1 without providing any
>examples. Given that it is also 13 years old I thought there might be
>fresher information out there.
>
>Thanks,
>graham 

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.

Re: Financial services BGP hijack last week?

[Compton, Rich A]

The servers where the RPKI data is published (the Trust Anchor and the CAs) are 
referred to using a single URI, meaning that any sort of geographic redundancy 
or failover has to be handled via external means (anycast, load balancing, 
etc.) but rsync isn’t well-suited for this sort of implementation.

[cid:DE8A0963-605D-4E57-8A58-E154EF0E790C]

Rich Compton  |  Principal Eng |  314.596.2828
14810 Grasslands  Dr,Englewood,  CO80112


From: <christopher.mor...@gmail.com<mailto:christopher.mor...@gmail.com>> on 
behalf of Christopher Morrow 
<morrowc.li...@gmail.com<mailto:morrowc.li...@gmail.com>>
Date: Tuesday, May 2, 2017 at 6:34 PM
To: Compton Rich A <rich.comp...@charter.com<mailto:rich.comp...@charter.com>>
Cc: Job Snijders <j...@ntt.net<mailto:j...@ntt.net>>, Nikos Leontsinis 
<nikosi...@gmail.com<mailto:nikosi...@gmail.com>>, NANOG list 
<nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: Re: Financial services BGP hijack last week?



On Tue, May 2, 2017 at 11:21 AM, Compton, Rich A 
<rich.comp...@charter.com<mailto:rich.comp...@charter.com>> wrote:
That¹s the million dollar question.  I think that there will be more
adoption from the Internet at large when some big players adopt it.  Right
now the use of rsync in RPKI is preventing a lot of large ISPs from
implementing it (too difficult to provide redundancy with rsync). There is

how is it hard to provide redundancy with rsync?

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.

Re: Financial services BGP hijack last week?

[Compton, Rich A]

That¹s the million dollar question.  I think that there will be more
adoption from the Internet at large when some big players adopt it.  Right
now the use of rsync in RPKI is preventing a lot of large ISPs from
implementing it (too difficult to provide redundancy with rsync). There is
a protocol called RPKI Repository Delta Protocol (RRDP)
https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08 which will
alleviate these concerns but it is still in draft.  I think once that
becomes an RFC we will see more adoption of RPKI.



Rich Compton  |  Principal Eng |  314.596.2828
14810 Grasslands  Dr,Englewood,  CO80112






On 5/2/17, 6:27 AM, "NANOG on behalf of Job Snijders"
 wrote:

>On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote:
>> it only proves the need for wider RPKI adoption
>
>How can we actually encourage RPKI adoption?
>
>Kind regards,
>
>Job

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.

Re: CGNAT

[Compton, Rich A]

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,  CO80112






On 4/6/17, 2:33 PM, "NANOG on behalf of Aaron Gould"
 wrote:

>Last year I evaluated Cisco ASR9006/VSM-500 and Juniper MX104/MS-MIC-16G
>in
>my lab.
>
>I went with MX104/MS-MIC-16G.  I love it.
>
>I deployed (2) MX104's.  Each MX104 has a single MX-MIC-16G card in it.  I
>integrated this CGNAT with MPLS L3VPN's for NAT Inside vrf and NAT outside
>vrf.  Both MX104's learn 0/0 route for outside and send a 0/0 route for
>inside to all the PE's that have DSLAMs connected to them.  So each PE
>with
>DSL connected to it learns default route towards 2 equal cost MX104's.  I
>could easily add a third MX104 to this modular architecture.
>
>I have 7,000 DSL broadband customers behind it.  Peak time throughput is
>hitting up at 4 gbps... I see a little over 100,000 service flows
>(translations) at peak time
>
>I think each MX104 MS-MIC-16G can able about ~7 million translations and
>about 7 gbps of cgnat throughput... so I'm good.
>
>I have a /25 for each MX104 outside public address pool (so /24 total for
>both MX104's)... pretty sweet how I use /24 for ~7,000 customers :)
>
>I'll freeze this probably for DSL and not put anything else behind it.  I
>want to leave well-enough alone.
>
>If I move forward with CGNAT'ing Cable Modem (~6,000 more subsrcibers)
>I'll
>probably roll-out (2) more MX104's with a new vrf for that...
>
>If I move forward with CGNAT'ing FTTH (~20,000 more subsrcibers) I'll
>probably roll-out (2) MX240/480/960 with MS-MPC... I feel I'd want/need
>something beefier for FTTH...
>
>- Aaron
>
>

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.

Re: did facebook just DoS me?

[Compton, Rich A]

Any proof that you can provide that Facebook did indeed DoS you?  Unless
it is an attack after a tcp 3-way handshake I highly doubt that it was
actually Facebook and probably an attacker spoofing Facebook¹s source IPs
(perhaps in hopes that the source IPs would be on your whitelist and not
be blocked).  

Rich Compton  |  Principal Eng |  314.596.2828
14810 Grasslands  Dr,Englewood,  CO80112






On 4/3/17, 4:46 PM, "NANOG on behalf of Miguel Mata"
 wrote:

>Guys and gals,
>
>just received a DoS from supposedly Facebook. Any contact of way of
>getting in touch with
>them?
>
>Thanks.
>
>

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.