- Test - lists.nanog.org

CISCO 0-day exploits
by Jean | ddostest.me 11 Feb '20

11 Feb '20

CDPwn: 5 new zero-day Cisco exploits https://www.armis.com/cdpwn/ What's the impact on your network? Everything is under control? Jean

7 12

SD-NAP (San Diego) Internet Exchange?
by Matt Peterson 11 Feb '20

11 Feb '20

Wondering if SD-NAP is still functional? PeeringDB entry <https://peeringdb.com/ix/81> looks pretty stale, haven't been able to reach any contact aware of the current status. Appreciate any help or direction on the status, thanks. --Matt

2 1

Charter contact
by Mehmet Akcin 10 Feb '20

10 Feb '20

Hey there I am looking for a contact in Charter for a 10G wave. Reno > SF or Reno to > LA. Please let me know if you know people who may help. Thanks -- Mehmet +1-424-298-1903

3 2

AS7843 at NANOG78
by aaron＠digitalcrossroad.org 10 Feb '20

10 Feb '20

Hi, Would an operator from AS7843 at NANOG78 reach out to me off-list? Thanks, Aaron

1 0

Re: CISCO 0-day exploits
by Scott Weeks 10 Feb '20

10 Feb '20

--- nanog(a)nanog.org wrote: From: "Jean | ddostest.me via NANOG" <nanog(a)nanog.org> > https://www.armis.com/cdpwn/ > > What's the impact on your network? Everything is under control? --------------------------------------- I really thought that more Cisco devices were deployed among NANOG. I guess that these devices are not used anymore or maybe that I understood wrong the severity of this CVE. --------------------------------------- Just because you use cisco devices doesn't mean you have to use their proprietary protocols, such as EIGRP or CDP. OSPF or LLDP work just fine and interoperate with other vendors... :) scott

3 2

SLAAC renumbering problems (Fwd: [v6ops] draft-gont-v6ops-slaac-renum **Call for adoption**)
by Fernando Gont 10 Feb '20

10 Feb '20

Folks, A while ago some of us started working on an IETF draft to document and mitigate some issues experienced by SLAAC in the face of some renumbering events. Such work has resulted in three small documents. * draft-gont-v6ops-slaac-renum (problem statement) * draft-gont-v6ops-slaac-renum (CPE recommendations) * draft-gont-6man-slaac-renum (proposed protocol updates) Two of such documents are being discussed at the v6ops wg of the IETF, where there are ongoing calls for adoption for two of them. * The "problem statement" document (https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum) is being discussed at the v6ops wg of the IETF in this thread: https://mailarchive.ietf.org/arch/msg/v6ops/HmcZYGY4Lu2h7NUND3o2UiOsKXA * The "CPE recommendations" document (https://tools.ietf.org/html/draft-gont-v6ops-cpe-slaac-renum) is being discussed in the same group/list, in this thread: https://mailarchive.ietf.org/arch/msg/v6ops/yW_YdRogwMNCRvK1PKpXWgcBkmQ Feedback will be highly appreciated, particularly if on the v6ops wg mailing-list. Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: [v6ops] draft-gont-v6ops-slaac-renum **Call for adoption** Date: Sat, 4 Jan 2020 22:56:44 +0000 From: Ron Bonica <rbonica=40juniper.net(a)dmarc.ietf.org> To: v6ops(a)ietf.org <v6ops(a)ietf.org> Folks, Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it. This week, please review and comment on draft-gont-v6ops-slaac-renum. When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item. Fred and Ron Juniper Business Use Only

1 0

NCS-55A1
by Jason Bothe 09 Feb '20

09 Feb '20

Hi All, Happy NANOG78! Just curious if anyone knows how the MACSec behaves on the Cisco NCS-55A1, specifically the 24Q6H-S variant. I’m curious if you can still use MACSec individually on the 6xQSFP+/QSFP28 ports if I break them out as 10G. Thanks! J~

1 0

Spoofer Report for NANOG for Jan 2020
by CAIDA Spoofer Project 08 Feb '20

08 Feb '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 Jan 2020: ASN Name Fixed-By 701 UUNET 2020-01-15 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jan 2020: ASN Name First-Spoofed Last-Spoofed 5650 FRONTIER-FRTR 2016-02-22 2020-01-10 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2020-01-30 6128 CABLE-NET-1 2016-09-03 2020-01-29 20412 CLARITY-TELECOM 2016-09-30 2020-01-30 20001 TWC-20001-PACWEST 2016-10-08 2020-01-31 6181 FUSE-NET 2016-10-10 2020-01-29 174 COGENT-174 2016-10-21 2020-01-29 32440 LONI 2016-11-03 2020-01-25 12083 WOW-INTERNET 2016-11-09 2020-01-30 39939 RISE-CO-AS39939 2016-11-11 2020-01-27 9009 M247 2017-01-10 2020-01-31 701 UUNET 2017-06-14 2020-01-16 63296 AMARILLO-WIRELESS 2017-09-01 2020-01-28 18798 ENCORE-ASN 2017-10-09 2020-01-11 546 PARSONS-PGS-1 2017-11-20 2020-01-30 12222 AKAMAI 2018-02-14 2020-01-30 11827 WSU 2018-05-07 2020-01-30 393564 SPOKANE 2018-06-05 2020-01-28 225 VIRGINIA 2018-06-18 2020-01-22 20448 VPNTRANET-LLC 2018-09-20 2020-01-28 3549 LVLT-3549 2018-12-06 2020-01-28 62957 HOSPITALITY-NETWORK 2018-12-30 2020-01-10 23523 VOYAGEURINTERNET-1 2019-01-22 2020-01-06 63275 RADIOWIRE 2019-02-07 2020-01-15 6360 UNIVHAWAII 2019-02-25 2020-01-18 11297 LIPSCOMB 2019-03-29 2020-01-21 8047 GCI 2019-04-11 2020-01-29 46300 HSC-WAP 2019-10-30 2020-01-30 2886 EC-813-2886 2019-11-05 2020-01-10 63018 USDEDICATED 2019-12-03 2020-01-31 19009 ONECLEVELAND 2020-01-07 2020-01-07 12231 CONWAYCORP 2020-01-10 2020-01-31 239 UTORONTO 2020-01-28 2020-01-28 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

large path attr
by Randy Bush 07 Feb '20

07 Feb '20

Feb 7 05:30:12 rpd[1752]: Prefix Send failed ! 103.148.40.0/24 bgp_rt_trace_too_big_message:1209 path attribute too big. Cannot build update. anyone else seen this one? another kiddie? randy

2 2

Re: large path attr
by Randy Bush 07 Feb '20

07 Feb '20

responding to private email > Yes, something was up, as seen at the AS22211 openbgpd logger "flight > recorder". I only looked near the time stamp you had. > > # mrt2bgpdump /pool0/var/log/bgpd/all-in-2020-02-07-05-26 |grep 103.148.40 > BGP4MP|02/07/20 05:30:15|A|66.79.132.1|22211|103.148.40.0/24|12182 174 > 132602 10075 134371 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > ... > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076|IGP > > BGP4MP|02/07/20 05:30:42|A|66.79.132.1|22211|103.148.40.0/24|12182 2914 174 > 132602 10075 134371 140076 140076 140076 140076 140076 140076 140076 140076 > 140076 140076 140076 140076 140076 140076 140076 140076 140076 140076 > ... and so on as140076 is Mir Internet Service in Dhaka microtik prepend gl!tch? randy

1 0