July 2020 - Test - lists.nanog.org

Spoofer Report for NANOG for Jun 2020
by CAIDA Spoofer Project 08 Jul '20

08 Jul '20

In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Jun 2020: ASN Name Fixed-By 14525 OMNIFICENT-NET 2020-06-07 10745 ARIN-ASH-CHA 2020-06-12 63018 DEDICATED 2020-06-22 23473 PAVLOVMEDIA 2020-06-29 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jun 2020: ASN Name First-Spoofed Last-Spoofed 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2020-06-25 6128 CABLE-NET-1 2016-09-03 2020-06-30 7459 GRANDECOM-AS1 2016-09-26 2020-06-11 20412 CLARITY-TELECOM 2016-09-30 2020-06-29 6181 FUSE-NET 2016-10-10 2020-06-29 11427 TWC-11427-TEXAS 2016-10-21 2020-06-22 174 COGENT-174 2016-10-21 2020-06-30 32440 LONI 2016-11-03 2020-06-28 12083 WOW-INTERNET 2016-11-09 2020-06-28 39939 RISE-CO-AS39939 2016-11-11 2020-06-27 30036 MEDIACOM-ENTERPRISE-BUSINESS 2016-11-16 2020-06-29 9009 M247 2017-01-10 2020-06-21 63296 AWBROADBAND 2017-09-01 2020-06-30 20448 VPNTRANET-LLC 2018-09-20 2020-06-12 8047 GCI 2019-04-11 2020-06-25 33387 NOCIX 2019-06-06 2020-06-27 46300 HSC-WAP 2019-10-30 2020-06-26 21859 ZNET 2019-12-26 2020-06-18 239 UTORONTO 2020-01-28 2020-06-27 13614 ALLWEST 2020-03-16 2020-06-30 26335 MTSU 2020-03-20 2020-06-15 7859 PAIR-NETWORKS 2020-04-03 2020-06-27 5078 ONENET-AS-1 2020-04-06 2020-06-30 29844 SENAWAVE 2020-05-22 2020-06-04 11650 PLDI 2020-05-25 2020-06-24 6391 URBAN-15 2020-05-29 2020-06-30 5690 VIANET-NO 2020-06-12 2020-06-25 21565 AS21565 2020-06-21 2020-06-27 395723 LIGHTSPEEDHOSTING1 2020-06-22 2020-06-25 11525 HRTC 2020-06-27 2020-06-29 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Hoping to attend NANOG 80?
by NANOG News 08 Jul '20

08 Jul '20

*Share your insights!* The health and safety of the NANOG community is our top priority, and your feedback is extremely valuable in our efforts to continue providing the safest conference experiences possible. Planning to attend NANOG 80? We'd love to hear your thoughts! Take Survey <https://www.surveymonkey.com/r/YHG6GGZ>

1 0

CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP
by Douglas Fischer 08 Jul '20

08 Jul '20

We are looking for a CGNAT solution open source based. Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / IPFILTER / IPFW. But I only know Open Source CGNAT recipes with predefined public-ports <-> private IPs mapping. What It brings two types of issues: A - The need to overprovision the number of private IPs (Considering Multiple BNGs behind the CGN). B - The inability of those basic recipes to deal with incoming auxiliary connections of p2p protocols (mostly used by games). Te market solutions that I've dealt with solves those issues beautifully. a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private address that is not being used, and give us an excellent rate between public IPv4 Address vs Private IP Address. b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF, NAT-PMP, etc...) ensure an acceptable quality of experience to end-users. But, the market solution brings also some down-sides... - The cost, evidently. - The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, Internal Servers, etc), to stay on the license limits of those boxes, sometimes brings some issues. So, I and some friends are(for a long time) looking for an OpenSource solution that can give us something near what the market solutions give. Any of you guys ave some suggestions for that? P.S.: Yes, I know that IPv6 is the only real solution for that, but until there, our customers still want to access a lot os p2p content(mostly audio in game rooms, sip calls, and things like that.) P.S.2: Yes, I also know that 464 could be a good possibility, but is not possible in this scenario. -- Douglas Fernando Fischer Engº de Controle e Automação

6 5

pandemic stories about network ops/engineering
by Mehmet Akcin 07 Jul '20

07 Jul '20

hey there, Millions of people working from home, I am sure there was a lot of hard work from network and systems teams to build and upgrade capacity before and during the covid19 pandemic. I have a youtube series I am focusing on internet infrastructure and new normal, I would like to discover new stories about how network teams have handled unique stories during this time. Something different where you think it's important for people to know. I think there are many heroes who made this stay at home possible with enabling technology and my goal is to give these individuals a little bit visibility they deserve. For example youtube stream https://youtu.be/wFmZadETNDQ if you have suggestions about guests, please contact offlist. thank you Mehmet

1 0

rfc4271 ORIGIN/path of default route, should the value be 0 or 2?
by Drew Weaver 07 Jul '20

07 Jul '20

Howdy, I am using a multi-vendor network and validating the inter-operability. When I announce a default route to a BGP peer using default-originate applied to the peer group/neighbor configuration: in vendor A that route is sent with ORIGIN 0 (internal) in vendor B that route is sent with ORIGIN 2 (Unknown) Downstream it looks like this: Network Next Hop Metric LocPrf Weight Path * i 0.0.0.0 192.168.27.1 100 0 ? *>i 192.168.25.1 0 100 0 i * i 192.168.27.2 100 0 ? I don't believe that it has a functionality impact but I would like to know which one you think follows the RFC more closely. https://tools.ietf.org/html/rfc4271 thanks, -Drew

3 3

Anyone from Edgecast/ Verizon Digital on here
by Rob See 07 Jul '20

07 Jul '20

Hi, We are having problems with traffic to Edgecast from our netblock getting TCP Reset. The big thing it seems to be causing problems with is Twitter. Anyone else experiencing this problem, and does anyone have a contact there ? Their tier 1 support didn't want to talk to us because we aren't a direct customer. -- Thanks, -Rob

1 0

Study on understanding email configuration quality
by Tobias Fiebig 07 Jul '20

07 Jul '20

Dear all, I am a researcher at TU Delft in the Netherlands, looking into Security & Protocol Adoption. My student Olamide is looking into how well email setups are maintained around the globe. For this, we need many people, ideally from smaller providers, i.e., with non gmail/hotmail/yahoo addresses, to send us emails. Please consider participating in this study, and sharing it in your networks. To help us, please follow the instructions at: https://www.email-security-scans.org/ Important caveat: If your mailer validates recipient addresses before accepting mails, you might be unable to send to destination addresses that are (a) only resolvable via IPv6 only, or (b) Have broken DNSSEC, which we use to test DNSSEC validation. If this is the case, please just remove the 1-3 offending addresses from the To: header. Please also note that our test setups will test whether the host delivering mails to us is an open relay. Also note that you may receive bounces from your mailserver for some of the destination addresses, e.g., if mails can not be delivered via IPv6, or if your mail-setup validates DANE records for our DANE test domain. We do _not_ need a copy of those bounces. In case you want to get results for a domain you operate or use early, please just drop me an email from the same domain and delivering servers after you participated, and I will share the data with you. :-) Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft

2 1

NANOG Women in Tech: A Conversation with Micheala Clifford
by NANOG News 06 Jul '20

06 Jul '20

*"Get as much experience as you can, and make yourself known." * Though women make up 47 percent of all employed adults in the US, they hold only 25 percent of computer-science roles, and only 14 percent of software engineering roles. For women of color, the gap is even wider: Black women hold only 2 percent of all computing jobs, and Latinx women hold just 1 percent. There are some truly amazing women in the NANOG community, but we'd love to see far more. That’s why we work with colleges and universities, affiliate NOGs, and tech communities to provide greater access to our tools, resources, and programming across North America, with particular focus on the education and empowerment of students, women, and people of color. Our newest series on NANOG TV further explores the stories and career paths of some of the most exceptional women we know. Watch our first interview, featuring Micheala Clifford of Netflix, to learn more about her experience as a woman navigating the world of network engineering. Watch Now <https://www.nanog.org/news-stories/nanog-tv/women-tech/a-conversation-with-…>

1 0

NANOG 80 Call For Presentations
by Vincent Celindro 06 Jul '20

06 Jul '20

Dear NANOG Community, The NANOG Program Committee (PC) is excited to announce that we are accepting proposals for all sessions at NANOG 80. Transform your research, ideas, and best practices into a presentation for the 80th community-wide gathering of The North American Network Operators’ Group, in October. Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialogue, and drive new solutions to our greatest networking challenges. The NANOG Program Committee (PC) is currently seeking proposals, and also welcomes suggestions for speakers, and ideas for topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. Submit your NANOG 80 proposal now, via the NANOG Program Committee tool <https://www.nanog.org/meetings/submit-presentation/>. The deadline for proposals to be considered for NANOG 80 is Monday August 24th 2020. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the Program Committee Tool at: https://www.nanog.org/meetings/submit-presentation/ - Sign in with your Profile Account - Select the type of talk you propose to present, and complete the title and abstract - Topics of interest - SDN - Traffic Analysis - ISP Issues - sharing lessons learned / what to watch out for - Cloud related topics - Automation - Scale Concerns - Routing - Best Current Practices - Career Development Skills If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nanogpc(a)nanog.org) and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool at your earliest convenience. We look forward to reviewing your submission! Final slides must be submitted two weeks prior to the start of the conference and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you at NANOG 80. Sincerely, Vincent Celindro - PC Chair On behalf of the NANOG Program Committee

1 0

Comcast DNS Assistance?
by Dave Dechellis 06 Jul '20

06 Jul '20

Hello, Last night we made some changes to our DNS-SEC environment at Tufts University and all changes seem to have propagated - but we're having issues resolving against Comcast's DNS servers. All DNS-SEC checking seems to be looking good post changes and other ISPs are resolving fine. Is there anyone from Comcast who might be able to validate behavior? I'm assuming it might take up to 1 day for TTL propagation. Thanks Dave David.DeChellis(a)tufts.edu

3 2