May 2019 - Test - lists.nanog.org

IPv6 ingress filter
by Amos Rosenboim 14 May '19

14 May '19

Hello, As we are trying to tighten the security for IPv6 traffic in our network, I was looking for a reference IPv6 ingress filter. I came up with Job Snijders suggestion (thank you Job) that can be conveniently found at whois -h whois.ripe.net fltr-martian-v6 After applying the filter I noticed some traffic from 6to4 addresses (2002::/16) to our native IPv6 prefixes (residential users in this case). The traffic is a mix of both UDP and TCP but all on high port numbers on both destination and source. It seems to me like some P2P traffic, but I really can’t tell. This got me thinking, why should we filter these addresses at all ? I know 6to4 is mostly dead, but is it inherently bad ? And if so, why is the prefix (2002::/16) still being routed ? I would love to hear some thoughts on this, and understand if others are actually filtering this at both data plane and control plane. Thanks, Amos Rosenboim --

2 2

Re: Charter and Cox contacts
by daniel＠pyranah.com 14 May '19

14 May '19

"On 5/13/19 12:11 PM, daniel(a)pyranah.com wrote: > Does anyone have contacts at Charter (Spectrum) and Cox? For some reason, > our IP has been blocked by them and our customers are unable to send email > via their charter/cox accounts. Thanks Would you be talking about port 25/tcp outbound? Lots of ISPs will block port 25 as a rule; you have to call to have it opened. At the same time, you can request the PTR record you need to keep big mail receivers happy." It's the outgoing smtp ports, 587 for charter and 465 for cox. They are open on my end but our IP address that most of our customers are natted through is blocked by the email servers. Daniel Temple VP of Operations Pyranah Communications, LLC 828-743-2470 ext.205 Pyranah.com Like us on Facebook! -----Original Message----- From: NANOG <nanog-bounces(a)nanog.org> On Behalf Of nanog-request(a)nanog.org Sent: Tuesday, May 14, 2019 8:00 AM To: nanog(a)nanog.org Subject: NANOG Digest, Vol 136, Issue 14 Send NANOG mailing list submissions to nanog(a)nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org You can reach the person managing the list at nanog-owner(a)nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 2. Re: Ownership of Routers on Both Ends of Transnational Links (Pengxiong Zhu) 3. Re: Issues with SIP packets between VZ Fios and NTT (Brielle Bruns) 4. Re: Ownership of Routers on Both Ends of Transnational Links (Christopher Morrow) 5. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 6. Re: Ownership of Routers on Both Ends of Transnational Links (Pengxiong Zhu) 7. Re: Issues with SIP packets between VZ Fios and NTT (Brielle Bruns) 8. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 9. Re: Ownership of Routers on Both Ends of Transnational Links (Christopher Morrow) 10. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 11. Re: Issues with SIP packets between VZ Fios and NTT (Jared Mauch) 12. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) 13. Re: Issues with SIP packets between VZ Fios and NTT (Pete Rohrman) 14. Charter and Cox contacts (daniel(a)pyranah.com) 15. Mostly name and shame... (bzs(a)theworld.com) 16. Re: Ownership of Routers on Both Ends of Transnational Links (Randy Bush) 17. Re: Charter and Cox contacts (Stephen Satchell) 18. RE: FCC Hurricane Michael after-action report (frnkblk(a)iname.com) 19. Re: FCC Hurricane Michael after-action report (Mike Bolitho) 20. Re: Issues with SIP packets between VZ Fios and NTT (Saku Ytti) 21. Re: NTP for ASBRs? (Mark Tinka) 22. Re: NTP for ASBRs? (colin johnston) 23. Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open (Mark Tinka) 24. Re: Issues with SIP packets between VZ Fios and NTT (Dovid Bender) ---------------------------------------------------------------------- Message: 1 Date: Mon, 13 May 2019 11:21:12 -0400 From: Dovid Bender <dovid(a)telecurve.com> To: NANOG <nanog(a)nanog.org> Subject: Issues with SIP packets between VZ Fios and NTT Message-ID: <CAM3TTh2qpkWOD2DPy2GU-9hHkKUX8GVExfjYmmq0YEeCyubaKw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, Over the last 48 hours we have been getting a lot of alerts of customers phones losing registrations to us. All the complaints are coming from customers that are on VZ Fios in the NYC area. Anyone else see anything strange going on? TIA. Dovid

1 0

Issues with SIP packets between VZ Fios and NTT
by Dovid Bender 14 May '19

14 May '19

Hi, Over the last 48 hours we have been getting a lot of alerts of customers phones losing registrations to us. All the complaints are coming from customers that are on VZ Fios in the NYC area. Anyone else see anything strange going on? TIA. Dovid

5 10

Fwd: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open
by Mark Tinka 14 May '19

14 May '19

FYI. Mark. -------- Forwarded Message -------- Subject: [afnog] SAFNOG-5 & iWeek 2019 Registrations Open Date: Mon, 13 May 2019 11:06:53 +0000 From: Portia Rabonda <portia.rabonda(a)safnog.net> To: afnog(a)afnog.org <afnog(a)afnog.org> Greetings All, It gives us great pleasure to announce that the SAFNOG-5 & iWeek 2019 event registration is now open! SAFNOG, in collaboration with iWeek, is proud to announce that this year’s event registration is free of charge. SAFNOG-5 and iWeek 2019 will be held between the 26th- 28th August, 2019, in Johannesburg, South Africa. SAFNOG-5 seats are limited to 120 people, to reserve your spot, register through our website: http://safnog.org/. Please take note to select “SAFNOG-5” as the main event of attendance to secure your free seat. Information about the event programme, the venue, travel information and other important updates will be made available on http://safnog.org/ in due time. We are officially 105 days from the big showdown in Jozi! We look forward to seeing you there! Regards, Portia Rabonda on Behalf of SAFNOG MC

1 0

Re: NTP for ASBRs?
by Scott Weeks 14 May '19

14 May '19

--- bryan(a)shout.net wrote: From: Bryan Holloway <bryan(a)shout.net> On 5/8/19 4:00 PM, Scott Weeks wrote: > --- job(a)ntt.net wrote: > From: Job Snijders <job(a)ntt.net> > > on this topic, i strongly recommend to operate all > devices in the Etc/UTC timezone, this makes > coordination with external entities much easier. > ---------------------------------------- > > > Yes, this! Holy crap I come upon a lot of networks > that don't do this and it's always painful. Now if only we could get rid of Daylight Saving Time ... ------------------------------------------ Luckily, Hawaii doesn't have that problem... https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#Haw… But, that's the thing. One time. No trying to figure out who does DST and who doesn't. >From the above: =========================================== Arizona has not observed DST since 1967 Calif - in 2018, voters ratified a legislative plan for year-round daylight saving time, subject to congressional approval. On March 6, 2018, the Florida Senate approved the "Sunshine Protection Act" which would put Florida on permanent Daylight Saving Time year round...Congress would need to amend the existing 1966 federal law to allow the change. Hawaii has never observed daylight saving time ============================================ etc... scott

9 12

USA to Mexico IXP Equipment Recommendations
by NJ 14 May '19

14 May '19

Advice and/or suggestions wanted. Any input greatly appreciated. *Scenario:* We have run fiber from the USA to Mexico and have an exchange point in place. Our fiber connections are dark and therefore we can use any configuration we want on as many pairs as we want. Currently we have decided to light two 100gig connections and they are piping across the border already. We have 200gig going to Los Angeles (Wilshire Adjacent) and are looking to the mexico interested community of network engineers to identify how our peering point in Tijuana can be made to best service the networks in the region (and abroad if they build in). Our IXP is good, but we want to update/upgrade and put in a future-compatible robust solution instead of what we have in there now. We are an open IXP and are wondering how you would prefer to peer and what your equipment recommendations are and why. We're not afraid to spend (some) money but we do want it to not be complete overkill however should last at least 5 to 10 years before any upgrade would be required. Also to note, we are running our own bandwidth over the pipes as well so we would like to keep them separated. *Norm* A.A.S. R.A. Lifetime Member *Archaeology, Astronautics and SETI Research Association* SETI Project Lifetime Contributor

1 0

Re: Ownership of Routers on Both Ends of Transnational Links
by Pengxiong Zhu 13 May '19

13 May '19

Thanks again for your insightful responses! The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. How about the case that the IP belongs to a Chinese ISP and is located in US(from RTT result), can we say it is very likely or definitely owned/operated by the Chinese ISP? Why would some ISP try to rent routers of Chinese ISP in US? For example, a traceroute from Ohio to an IP in China. Hop 17 and hop 18 should be located in US based on the RTT, and yet they belong to a Chinese AS(China Telecom). Does this mean that Chinese Telecom is managing these two hops? HOST: Loss% Snt Last Avg Best Wrst StDev 6. AS??? 100.65.11.97 0.0% 100 2.0 1.0 0.4 12.6 1.3 7. AS??? 52.93.15.238 0.0% 100 2.4 2.0 1.5 11.4 1.1 8. AS??? 52.93.14.134 0.0% 100 21.9 26.3 4.2 54.4 11.3 9. AS??? 52.93.14.119 0.0% 100 2.6 2.1 1.6 10.8 1.2 10. AS??? 100.91.27.86 0.0% 100 25.8 26.2 25.6 34.9 1.2 11. AS??? 54.239.42.197 0.0% 100 25.5 25.9 25.4 35.8 1.5 12. AS??? 100.91.4.218 0.0% 100 25.9 26.2 25.1 38.3 1.6 13. AS??? 100.91.4.217 0.0% 100 25.4 26.0 25.3 41.4 2.0 14. AS??? 100.91.5.85 0.0% 100 25.3 25.8 25.2 29.1 0.9 15. AS??? 54.239.103.86 0.0% 100 25.6 30.0 25.2 49.1 3.8 16. AS??? 54.239.103.77 0.0% 100 25.3 25.6 25.2 28.1 0.5 17. AS4134 218.30.53.1 0.0% 100 28.0 29.1 25.2 33.1 2.3 18. AS4134 202.97.50.21 0.0% 100 32.4 29.1 25.2 33.5 2.4 19. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 20. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 21. AS4134 202.97.94.121 0.0% 100 186.8 185.6 181.8 189.8 2.3 22. AS4816 119.147.222.6 0.0% 100 182.6 183.5 182.4 195.8 1.8 23. AS4816 183.2.182.130 0.0% 100 181.7 183.3 181.5 207.0 3.9 24. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 25. AS45102 116.251.113.158 0.0% 100 176.7 177.9 176.5 186.7 2.1 26. AS45102 116.251.115.141 0.0% 100 213.2 213.4 213.1 218.5 0.6 Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 7:37 PM Erik Sundberg <ESundberg(a)nitelusa.com> wrote: > May sure when you are dealing with transnational links to watch the > latency so you can tell when the link goes international. Just because you > are going from a US Network provider to China Telecom doesn't mean that > your not connecting to them in the united states. > > > > For example a traceroute from Denver to 27.29.128.1 which is an IP in > China Telecom's network. > > It's about 26ms between Denver and Los Angeles. Hop 5 to Hop 6 > > China Telecom connects to GTT in Los Angeles Hop7/8 > > On Hop 8 is in the United State and Hop 9 is across the pacific. Because > the latency goes from 31 ms to 183 ms. > > > Just something to keep in mind. > > > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. _gateway > 0.0% 14 1.0 1.2 1.0 2.8 0.5 > 2. te-0-0-26.ear2.den1.us.nitelusa.net > 0.0% 14 0.9 1.0 0.8 2.1 0.4 > 3. te-0-0-26.ear1.den1.us.nitelusa.net > 0.0% 14 1.1 1.6 1.1 2.9 0.7 > 4. te-0-0-1-0.cr1.den1.us.nitelusa.net > 0.0% 14 1.0 1.0 1.0 1.1 0.0 > 5. ae1-122.cr0-den2.ip4.gtt.net > 0.0% 14 0.5 1.2 0.3 6.9 2.0 > 6. et-0-0-47.cr3-lax2.ip4.gtt.net > 0.0% 14 26.5 26.4 26.2 26.7 0.2 > 7. as4134.lax20.ip4.gtt.net > 0.0% 14 27.7 28.7 26.8 30.1 1.1 > 8. 202.97.50.29 > 0.0% 14 31.4 30.6 26.8 34.1 2.4 > 9. 202.97.41.129 > 0.0% 14 183.3 187.1 183.3 190.8 2.4 > 10. 202.97.94.101 > 0.0% 14 187.9 188.6 186.1 211.2 6.8 > 11. 202.97.94.141 > 0.0% 13 177.8 180.7 177.2 184.2 2.3 > 12. 202.97.67.54 > 0.0% 13 199.5 201.2 197.4 205.1 2.6 > 13. 111.177.110.62 > 0.0% 13 205.9 206.3 205.9 208.2 0.7 > 14. 27.29.128.1 > 0.0% 13 202.6 202.8 202.5 203.9 0.4 > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg(a)nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* Zhiyun Qian <zhiyunq(a)cs.ucr.edu> > *Sent:* Tuesday, April 16, 2019 1:02:36 PM > *To:* Erik Sundberg > *Cc:* Pengxiong Zhu; Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Erik, > > Thanks a lot for the information! This is extremely helpful. We are > conducting an analysis on performance/policy-related study on transnational > links. We are hoping to submit a paper soon. Will be glad to share all the > details once we have a draft! > > Best, > -Zhiyun > > > On Tue, Apr 16, 2019 at 10:35 AM Erik Sundberg <ESundberg(a)nitelusa.com> > wrote: > > CPE is usually ran by the customer. Some provider do offer managed routers > for a fee. Kinda like renting a cable modem from your provider. > > > What are your guys trying to accomplish or find out? > > Erik > > > > Erik Sundberg > Sr. Network Engineer > Nitel > 350 N Orleans Street > Suite 1300N > Chicago, Il 60654 > Desk: 773-661-5532 > Cell: 708-710-7419 > NOC: 866-892-0915 > Email: esundberg(a)nitelusa.com > web: www.nitelusa.com > > ------------------------------ > *From:* Pengxiong Zhu <pzhu011(a)ucr.edu> > *Sent:* Tuesday, April 16, 2019 12:32 PM > *To:* Erik Sundberg > *Cc:* Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Thanks a lot! > > Are the Customer Devices managed by Telia or the customer? > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Tue, Apr 16, 2019 at 7:43 AM Erik Sundberg <ESundberg(a)nitelusa.com> > wrote: > > I hope this helps with the breakdown for telia. > > > > > Telia i think is using /31's for there serial blocks now > > 62.115.170.56 (Telia Edge Rotuer) > > 62.115.170.57 (Customer Device) > > > > chinaunicom-ic-341501-sjo-b21.c.telia.net. > > > <Customername>-<CircuitID>-<POP>-<router>.c.telia.net > > > > Customer: ChinaUnicom > > Telia Circuit ID's are: ic-123456 > > POP: SJO (Airport code) > > Router: b21 > > Doamin: c.telia.net "Customer.telia.net" > > > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundberg(a)nitelusa.com > > web: www.nitelusa.com > > ------------------------------ > *From:* NANOG <nanog-bounces(a)nanog.org> on behalf of Pengxiong Zhu < > pzhu011(a)ucr.edu> > *Sent:* Monday, April 15, 2019 11:36:45 PM > *To:* nanog(a)nanog.org > *Cc:* Keyu Man; Zhiyun Qian; Zhongjie Wang > *Subject:* Ownership of Routers on Both Ends of Transnational Links > > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. >

3 4

Mostly name and shame...
by bzs＠theworld.com 13 May '19

13 May '19

Why has OUTLOOK.COM allowed daily dictionary spammers to operate from their net, FOR YEARS? It can't be that hard to detect and block. 2019-05-13T17:00:18.194103-04:00 pcls6 sendmail[14128]: NOUSER: proctor5 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.444848-04:00 pcls6 sendmail[14128]: NOUSER: proctor4 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.698977-04:00 pcls6 sendmail[14128]: NOUSER: proctor2 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:00:18.952548-04:00 pcls6 sendmail[14128]: NOUSER: proctor10 relay=mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53] 2019-05-13T17:10:27.523597-04:00 pcls6 sendmail[19471]: NOUSER: proctor6 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:27.775984-04:00 pcls6 sendmail[19471]: NOUSER: proctor5 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.029744-04:00 pcls6 sendmail[19471]: NOUSER: proctor4 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.283016-04:00 pcls6 sendmail[19471]: NOUSER: proctor2 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:10:28.537106-04:00 pcls6 sendmail[19471]: NOUSER: proctor10 relay=mail-eopbgr810043.outbound.protection.outlook.com [40.107.81.43] 2019-05-13T17:30:47.045677-04:00 pcls6 sendmail[31621]: NOUSER: proctor6 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.299131-04:00 pcls6 sendmail[31621]: NOUSER: proctor5 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.552492-04:00 pcls6 sendmail[31621]: NOUSER: proctor4 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:47.804233-04:00 pcls6 sendmail[31621]: NOUSER: proctor2 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:30:48.056635-04:00 pcls6 sendmail[31621]: NOUSER: proctor10 relay=mail-eopbgr810072.outbound.protection.outlook.com [40.107.81.72] 2019-05-13T17:35:05.867715-04:00 pcls6 sendmail[1352]: NOUSER: proctor9 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.120021-04:00 pcls6 sendmail[1352]: NOUSER: proctor7 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.372603-04:00 pcls6 sendmail[1352]: NOUSER: proctor6 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.627583-04:00 pcls6 sendmail[1352]: NOUSER: proctor5 relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] 2019-05-13T17:35:06.885218-04:00 pcls6 sendmail[1352]: NOUSER: proctor relay=mail-eopbgr50127.outbound.protection.outlook.com [40.107.5.127] etc etc etc etc. -- -Barry Shein Software Tool & Die | bzs(a)TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

1 0

Seeking Feedback on Mitigation of New BGP-driven Attack
by Jared Smith 11 May '19

11 May '19

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

3 2

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco.
by Jacques Latour 10 May '19

10 May '19

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-marrakech(a)isoc.org<mailto:dnssec-marrakech@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

1 0