Re: Seeking Feedback on Mitigation of New BGP-driven Attack

[Job Snijders]

Dear Jared,

This was a very interesting read. Thank you for sharing it with us. The
paper contained new information for me, if I hope I summarize it correctly:
by combining AS_PATH poisoning and botnets, the botnet’s firing power can
be more precisely aimed at a specific target.

Can you clarify what the definition of a “link” is? Is it the logical
interconnection between two ASNs (many pairs of ASNs interconnect in many
places), or is it a reference to a specific physical interconnection
between two routers, each in a different ASN?

The paper mentions that if the top 20 transit-free (“tier-1”) networks
protect each other against poisoning, the Maestro attack is drastically
reduced in effectiveness. I have good news, amongst this set of networks,
there already is a widely deployed anti poisoning mechanism, sometimes
referred to as “Peerlock”. https://www.youtube.com/watch?v=CSLpWBrHy10 /
https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf
. I think this paper suggests the Peerlock practice should be promoted
more, and perhaps automated.

Kind regards,

Job

On Fri, 10 May 2019 at 15:27, Jared Smith  wrote:

> Hello,
>
> Our research lab at the University of Tennessee (volsec.org) has recently
> completed
> a study on channeling link-flooding attack (transit link DDoS) flows
> via BGP poisoning: the Maestro attack. We are seeking feedback on
> mitigation (see below). A brief summary from the abstract:
>
> "Executed from a compromised or malicious Autonomous System (AS),
> Maestro advertises specific-prefix routes poisoned for selected ASes
> to collapse inbound traffic paths onto a single target link. A greedy
> heuristic fed by publicly available AS relationship data iteratively
> builds the set of ASes to poison. Given a compromised BGP speaker with
> advantageous positioning relative to the target link in the Internet
> topology, an adversary can expect to enhance flow density by more than 30%.
> For a large botnet (e.g., Mirai), the bottom line result is augmenting a
> DDoS by more than a million additional infected hosts. Interestingly, the
> size of the adversary-controlled AS plays little role in this
> amplification effect. Devastating attacks on core links can be executed by
> small, resource-limited ASes."
>
> We are seeking feedback from operators on the attack and the proposed
> mitigations we have identified. While we have worked with our campus BGP
> operators, we are reaching out to the broader community for
> additional insights.
>
> Other than general notes/comments, we have two specific questions that we
> would
> like to include feedback for in the final paper soon to be submitted:
>
> 1) Do you already filter poisoned/path prepend advertisements? This would
> mitigate the attack.
>
> 2) After seeing this attack, would you consider adding poison filtering or
> some other Day mitigation?
>
> The preprint is available at: tiny.utk.edu/maestro. See Section 7 on
> defenses.
>
> Please reply with any thoughts. Thank you in advance for comments,
> insight, and general feedback.
>
> Best,
> Tyler McDaniel, Jared Smith, and Max Schuchard
> UT Computer Security Lab
> volsec.org
>

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco.

[Jacques Latour]

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco.

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, 
in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
are planning a DNSSEC Workshop during the ICANN65 meeting held from 24-27 June 
2019 in Marrakech, Morocco.  The DNSSEC Workshop has been a part of ICANN 
meetings for several years and has provided a forum for both experienced and 
new people to meet, present and discuss current and future DNSSEC deployments.  
For reference, the most recent session was held at the ICANN Community Forum in 
Kobe, Japan on 13 March 2019. The presentations and transcripts are available 
at:  https://64.schedule.icann.org/meetings/961937, 
https://64.schedule.icann.org/meetings/961938,
and https://64.schedule.icann.org/meetings/961939.

The DNSSEC Workshop Program Committee is developing a 3-hour program.  
Proposals will be considered for the following topic areas and included if 
space permits.  In addition, we welcome suggestions for additional topics 
either for inclusion in the ICANN65 workshop, or for consideration for future 
workshops.

1.  DNSSEC Activities Panel (Regional and global)
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment in the region and also from those who have not deployed 
DNSSEC but who have a keen interest in the challenges and benefits of 
deployment, including Root Key Signing Key (KSK) Rollover activities.   Now 
that DNSSEC has become an operational norm for many registries, registrars, and 
ISPs, what have we learned about how we manage DNSSEC? What is the best 
practice around key rollovers? How often do you review your disaster recovery 
procedures? Is there operational familiarity within your customer support 
teams? What operational statistics have we gathered about DNSSEC? Are there 
experiences being documented in the form of best practices, or something 
similar, for transfer of signed zones?
If you have a specific concern about the Root Key Rollover, or believe you have 
a method or solution to help address impacts, we would like to hear from you.

2. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the nature:
- Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
- What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
- What do you expect DNSSEC to do for you and what doesn't it do?
- What do you see as the most important trade-offs with respect to doing or not 
doing DNSSEC?

We are interested in presentations related to any aspect of DNSSEC such as zone 
signing, DNS response validation, applications use of DNSSEC, 
registry/registrar DNSSEC activities, etc.  In addition, we welcome suggestions 
for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-marrak...@isoc.org by **Friday, 17 May 
2019**

Thank you,
Jacques

On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, Chinese Academy of Sciences (CAS)
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society

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 11 May, 2019

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

Analysis Summary


BGP routing table entries examined:  753151
Prefixes after maximum aggregation (per Origin AS):  288263
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  360475
Total ASes present in the Internet Routing Table: 64188
Prefixes per ASN: 11.73
Origin-only ASes present in the Internet Routing Table:   55224
Origin ASes announcing only one prefix:   23795
Transit ASes present in the Internet Routing Table:8964
Transit-only ASes present in the Internet Routing Table:270
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  34
Max AS path prepend of ASN (  8697)  27
Prefixes from unregistered ASNs in the Routing Table:24
Number of instances of unregistered ASNs:28
Number of 32-bit ASNs allocated by the RIRs:  26896
Number of 32-bit ASNs visible in the Routing Table:   22003
Prefixes from 32-bit ASNs in the Routing Table:   97673
Number of bogon 32-bit ASNs visible in the Routing Table:21
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:259
Number of addresses announced to Internet:   2850178944
Equivalent to 169 /8s, 226 /16s and 71 /24s
Percentage of available address space announced:   77.0
Percentage of allocated address space announced:   77.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.2
Total number of prefixes smaller than registry allocations:  252122

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   203409
Total APNIC prefixes after maximum aggregation:   59122
APNIC Deaggregation factor:3.44
Prefixes being announced from the APNIC address blocks:  199716
Unique aggregates announced from the APNIC address blocks:82255
APNIC Region origin ASes present in the Internet Routing Table:9722
APNIC Prefixes per ASN:   20.54
APNIC Region origin ASes announcing only one prefix:   2722
APNIC Region transit ASes present in the Internet Routing Table:   1448
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4726
Number of APNIC addresses announced to Internet:  77368
Equivalent to 46 /8s, 29 /16s and 107 /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-139577
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:224174
Total ARIN prefixes after maximum aggregation:   104803
ARIN Deaggregation factor: 2.14
Prefixes being announced from the ARIN address blocks:   223364
Unique aggregates announced from the ARIN address blocks:105536
ARIN Region origin ASes present in the Internet Routing Table:18471
ARIN Prefixes per ASN:12.09
ARIN Regio

Re: NTP for ASBRs?

[Christopher Morrow]

On Thu, May 9, 2019 at 4:42 PM Mike Hammett  wrote:
>
> Many systems have less than ideal separation of collection, storage, viewing, 
> export, etc. timezones. I prefer to view in local time. I may wish to export 
> in another. Storage in UTC to facilitate all of this makes sense. Normalizing 
> input timezones would be nice.
>
> A boy can only dream...
>
>
>
> -
> Mike "Dreamer of Dreams" Hammett

There I fixed it for ya! :)
(I agree, btw, that this sort of thing would be nice :) and some folk
can implement that today even :) )

> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> 
> From: "Christopher Morrow" 
> To: "nanog list" 
> Sent: Thursday, May 9, 2019 2:16:59 PM
> Subject: Re: NTP for ASBRs?
>
> On Thu, May 9, 2019 at 3:12 PM Andy Smith  wrote:
> >
> > Hello,
> >
> > On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote:
> > > UTC is nice
> > > EST is nice
> > > PDT is nice..
> > >
> > > pick one, deal with the eccentricities of that decision without
> > > foisting your religion on the rest of me. :)
> >
> > Yes and no. Anything non-UTC can cause issues when working with
> > other organisations.
>
> "deal with the eccentricities of that decision without
> foisting your religion on the rest of me"
>
> I clearly mistyped: "me" at the end there with "us"... Your point is
> squarely on: Hey, you do you... when you talk to me be prepared to
> normalize my TZ and yours.
> (which may mean;: send in UTC store in ElboniaStandardTime"
>
> > More than once I've received logs or incident notifications from
> > suppliers without a time zone stated at all. I've then asked the
> > time zone only to be told "It's PST" when in fact the real answer
> > was PDT as the supplier was currently in DST. Others shouldn't have
> > to work this hard, epseically with DST dates being a matter of local
> > legislation, and one way of helping that to happen from the first
> > line support up is to use UTC.
> >
> > Cheers,
> > Andy
>

Seeking Feedback on Mitigation of New BGP-driven Attack

[Jared Smith]

Hello,

Our research lab at the University of Tennessee (volsec.org) has recently 
completed
a study on channeling link-flooding attack (transit link DDoS) flows
via BGP poisoning: the Maestro attack. We are seeking feedback on mitigation 
(see below). A brief summary from the abstract:

"Executed from a compromised or malicious Autonomous System (AS),
Maestro advertises specific-prefix routes poisoned for selected ASes
to collapse inbound traffic paths onto a single target link. A greedy
heuristic fed by publicly available AS relationship data iteratively
builds the set of ASes to poison. Given a compromised BGP speaker with
advantageous positioning relative to the target link in the Internet
topology, an adversary can expect to enhance flow density by more than 30%.
For a large botnet (e.g., Mirai), the bottom line result is augmenting a
DDoS by more than a million additional infected hosts. Interestingly, the
size of the adversary-controlled AS plays little role in this
amplification effect. Devastating attacks on core links can be executed by
small, resource-limited ASes."

We are seeking feedback from operators on the attack and the proposed
mitigations we have identified. While we have worked with our campus BGP
operators, we are reaching out to the broader community for additional insights.

Other than general notes/comments, we have two specific questions that we would
like to include feedback for in the final paper soon to be submitted:

1) Do you already filter poisoned/path prepend advertisements? This would
mitigate the attack.

2) After seeing this attack, would you consider adding poison filtering or some 
other Day mitigation?

The preprint is available at: tiny.utk.edu/maestro. See Section 7 on defenses.

Please reply with any thoughts. Thank you in advance for comments, insight, and 
general feedback.

Best,
Tyler McDaniel, Jared Smith, and Max Schuchard
UT Computer Security Lab
volsec.org