May 2016 - NANOG - lists.nanog.org

Re: BGP peering strategies for smaller routers
by Ken Chase 03 May '16

03 May '16

got a quagga router in my life where bgpd+zebra takes up 1gig for 4.5 full tables. Rest of the OS easily lives in 1 gig (could probably be much less.) big-vendor solutions always seem much bloatier - same deal on power usage. just a data point. /kc -- Ken Chase - math(a)sizone.org Toronto

1 0

CFP: DNS Track at NANOG 67
by Wessels, Duane 03 May '16

03 May '16

Greetings, For our upcoming meeting in Chicago I'm looking for folks willing to give brief presentations during a proposed DNS Track. Possible topics include: - Operational experiences - New & interesting software features - Protocol advancements - Research results - Performance & compliance testing - Insights into DNS-related attacks I'm expecting to have about 90 minutes to fill with presentations of about 15 minutes or less. If you're interested in presenting please respond to me directly. Duane W.

1 0

BGP FlowSpec
by Martin Bacher 03 May '16

03 May '16

Dear Nanog Members, My name is Martin Bacher. I am a Student at UAS Technikum-Wien and I am currently writing my master’s thesis with topic "Addressing DDoS Attacks with BGP FlowSpec“. It would be very helpful for me if some of you could share information about the following topics: - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind of attacks are you using it? Are you only dropping or rate-limiting certain traffic or are you also using the redirect/remark capabilities? What are the limitations from your perspective? Are you facing any operational issues? How are you injecting the FlowSpec routes? - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is your experience? Are there any concerns regarding Inter-AS deployments? Has anyone done interop tests? FlowSpec is usually only one part of the whole anti DDoS toolset. So I would also be interested in your answers to the following questions: - How are you detecting DDoS attacks (Netflow, in-line probes, ..?) and which applications are you using for the analysis (Peakflow, Open-Source tools, ..?) - Which countermeasures are you deploying in case of DDoS attacks? ACLs, FlowSpec, Blackhole routes, RTBH, scrubbing center, Cloud based DDoS services or anything else? - What is your operational experience? How fast are you in deploying countermeasures? Do you have any automation or is this always triggered by people? Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if someone would be able to share such data. Please send me your answers either via pn or directly to the list. Please also let me know if you think that there is something missing. Any comment or answer is highly appreciated. Looking forward to your replies. Many thanks. Greetings, Martin

8 19

Standards for last mile performance
by Jean-Francois Mezei 02 May '16

02 May '16

The CRTC hearing went well (thanks for all your help). One of the unanswered questions was how to set performance standards for the last mile to ensure people get advertised speeds (within reason). I had asked the question about contention ratio and it appears there is no proper way to set such a moving target as a regulatory standard. During the hearing, someone suggested that advertised speeds be achievable 80% of the time. (chairman then asked if "time" was 24 hours, or just the time you needed to use the internet (aka: peak). Out of curiosity, could such a thing be measured by the last mile operator ? There is the easy answer of synch. For DSL, non delivery of advertised speed is easy since that metric is on the modem statistics. However, for fixed wireless, would a customer too far from tower see a lower synch rate or would he just see poor performance due to lots of retransmits ? So some generic questions: What are the different ways used to determine if the last mile is congested and needs to be upgraded ? >From the network operator's point of view, would it not be looking at 5 minute throughput samples and trigger upgrades when it sees throughput reaching x% of last mile segment capacity for more than X minutes per day ? What other means do network admins use to monitor when it is time to upgrade shared last mile segments such as coax or fixed wireless ? from a policy point of view, is it possible to set the same standard for different technologies or should each (dsl, coax, fixed wireless and satellite) have they own standards and methods of measurements before of intrinsic differences in how they work ? In the case of Rogers (canadian cableco), the CRTC record shows that they trigger node split process when capacity reaches 60%. This is because it takes them so long to do all the paperwork, committees etc that by the time the node split is done, that segment has grown to about 75% utilisation. Would that be a sound basis to set a policy ? For shared last mile, would different technologies have similar thresholds that trigger the need for upgrades or would coax start to degrade at 75% whereas fixed wireless or satellite start to degrade at lower/higher number ? For FTTP, while likely not a big problem yet, would similar number apply when the ~2gbps download and ~1gbps upload start to get filled by the 32 homes served ?

4 7

[NANOG-announce] NANOG On The Road Comes to Denver!
by Valerie Wittkop 02 May '16

02 May '16

We are very excited to be holding the next NOTR event in Denver <http://nanog.org/meetings/road11/home> on May 10, 2016, and we invite you to join us! Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry? If so, the NANOG On The Road Denver event is perfect for you! Date: May 10, 2016 Time: Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM Location: Denver Marriott Westminster <http://nanog.org/meetings/road11/hotel> - 7000 Church Ranch Boulevard, Westminster, CO 80021 The FREE to attend event is open for registration. Register Now! <https://www.cvent.com/events/notr-denver/registration-ca6e1607497d49cc9d0bd…> Agenda Topics <http://nanog.org/meetings/road11/agenda> are posted, which include: - Life After IPv4 - DNSSEC & RPKI - Traceroute Tutorial - IPv6 Tutorial - BGP Tutorial If you are, or will be, in the Denver area, we invite you to attend. And don’t forget to share the invitation with your colleagues or others you feel may benefit from attending. Make NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet. Learn more about On The Road events here <https://www.nanog.org/meetings/road/home>. Feel free to contact us at nanog-support(a)nanog.org if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program Director Tel: +1 866 902 1336, ext 103 _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Re: Frontier Internet Outage
by Josh Reynolds 02 May '16

02 May '16

Something else you may want to look for in the future is an email report from the puck.nether.net outages list. On May 2, 2016 8:54 AM, "Matt Hoppes" <mattlists(a)rivervalleyinternet.net> wrote: > Yes yes yes, Josh :) Jeff got me the info I was looking for. > > On 5/2/16 9:47 AM, Josh Reynolds wrote: > >> From where? To what? Have you checked any carrier's looking glass? >> >> On May 2, 2016 8:45 AM, "Matt Hoppes" <mattlists(a)rivervalleyinternet.net >> <mailto:mattlists@rivervalleyinternet.net>> wrote: >> >> Is anyone else seeing major routing issues across the Frontier IP >> network this morning? >> >> I have been unable to get ahold of anyone at Frontier as of yet. >> >>

1 0

Frontier Internet Outage
by Matt Hoppes 02 May '16

02 May '16

Is anyone else seeing major routing issues across the Frontier IP network this morning? I have been unable to get ahold of anyone at Frontier as of yet.

4 3

Superfluous advertisement (was: Friday's Random Comment)
by Jakob Heitz (jheitz) 01 May '16

01 May '16

A use case for a longer prefix with the same nexthop: F / \ D E | | B C \ / A Suppose A is a customer of B and C. B has a large address space: 10.1.0.0/16. B allocates a subset to A: 10.1.1.0/24. B advertises the longer prefix to its backup provider C. C propagates it to E and then to F. B MUST advertise both 10.1.0.0/16 and 10.1.1.0/24 to D. D MUST propagate both of them to F. Otherwise, if F only receives 10.1.0.0/16 from D, then F will have the longer match 10.1.1.0/24 to E, but E is only the backup route. Thanks, Jakob. > -----Original Message----- > Date: Fri, 29 Apr 2016 08:17:41 -0400 > From: Alain Hebert <ahebert(a)pubnix.net> > To: "'NANOG list'" <nanog(a)nanog.org> > Subject: Friday's Random Comment - About: Arista and FIB/RIB's > Message-ID: <00ea292f-e779-25ad-ce89-eae897e9516d(a)pubnix.net> > Content-Type: text/plain; charset=utf-8 > > While following that Arista chat... That reminded me of that little > afternoon project years ago. > > So I decided to find new hamsters, fire up that VM, refresh the DB's and > from the view point of a tiny 7206VXR/G1 with 2 T3 peers... > > The amount of superfluous subnet advertisement drop to ~120k from > ~166k from the previous snapshot. > > And this is the distribution by country. > > country | superfluous > --------------------+------------- > United States | 28254 > Brazil | 10012 > China | 7537 > India | 6449 > Russian Federation | 4524 > Korea, Republic of | 4062 > Saudi Arabia | 3297 > Australia | 2989 > Indonesia | 2878 > Hong Kong | 2251 > Thailand | 2093 > Canada | 2019 > Taiwan | 1955 > Ukraine | 1877 > Singapore | 1856 > Bulgaria | 1488 > Argentina | 1436 > Japan | 1403 > Mexico | 1351 > Chile | 1271 > > (Damn Canada, can't break top 10 again). > > PS: "Superfluous" is a nice way to say that the best path of a > subnet is the same as his supernet. And yes I'm aware of the Weekly > Routing Report, I was just curious to see it by country =D. > > ----- > Alain Hebert ahebert(a)pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

4 7

Re: BGP FlowSpec
by dennis 01 May '16

01 May '16

Hi Amplification attacks and syn floods are just touching the surface of ddos attack vectors. You should look into some industry reports: Here are a couple examples to get you started. https://www.radware.com/ert-report-2015/ http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/ Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone -------- Original message -------- From: Martin Bacher <ti14m028(a)technikum-wien.at> Date: 4/29/2016 2:02 AM (GMT-08:00) To: Tyler Haske <tyler.haske(a)gmail.com> Cc: NANOG list <nanog(a)nanog.org> Subject: Re: BGP FlowSpec Hello Tyler, thanks for your reply. > Am 28.04.2016 um 17:37 schrieb Tyler Haske <tyler.haske(a)gmail.com>: > > Martin, > > > > Last but not least: I am also looking for anonymized statistical data about DDoS attacks which I could use in the thesis. I am mainly interested in data about the > > type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally not shared, so I would really appreciate it if > > someone would be able to share such data. > > Many companies are extremely reluctant to share their attack data. But that's OK, because there are other ways to get it. > > Have you investigated backscatter analysis? It's used to see ongoing and current Internet scope DDoS attacks. I just had a look on that and thought that its only be able to detect some of the attacks. You might not detect large state of the art reflection and amplification attacks with that method. But i think it is useful for some sort of attacks like SYN flood. Do you agree? > > Inferring Internet Denial of Service Activity > https://cseweb.ucsd.edu/~savage/papers/UsenixSec01.pdf > > Analyzing Large DDoS Attacks Using Multiple Data Sources > https://www.cs.utah.edu/~kobus/docs/ddos.lsad.pdf > > ISP Security - Real World Techniques > https://www.nanog.org/meetings/nanog23/presentations/greene.ppt > > A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment > https://www.sans.org/reading-room/whitepapers/intrusion/summary-dos-ddos-pr… > > Maybe you have access to some public IPs, then you can do this data collection yourself. Sure, I will definitely think about hat. Thanks again for your reply and for providing the links. Greetings, Martin > > Regards, > > Tyler >

4 3