From jasonbaugher at adamstel.com Tue Jan 1 00:15:50 2019 From: jasonbaugher at adamstel.com (Jason Baugher) Date: Tue, 1 Jan 2019 00:15:50 +0000 Subject: IP Dslams In-Reply-To: References: , Message-ID: Most of my experience is with Calix C7 and E7 DSL, fan of both. Recently learning the Adtran TA5000, not impressed. Hardware may be solid, but management is ugly and painful. Sent from my U.S. Cellular® Smartphone -------- Original message -------- From: Erik Sundberg Date: 12/31/18 1:32 PM (GMT-06:00) To: Nick Edwards Cc: nanog at nanog.org Subject: RE: IP Dslams I haven’t used any of theses… Check out Adtran Total Access 5000 Platform…. Used by a lot of EoC / EoDS1 carriers Google: Ethernet Extender DSLAM https://enableit.com/rackmount-extender/ From: NANOG On Behalf Of Nick Edwards Sent: Friday, December 28, 2018 7:36 PM To: nanog at nanog.org Subject: IP Dslams Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason) ________________________________ 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. Jason Baugher, Network Operations Manager 405 Emminga Road | PO Box 217 | Golden, IL 62339-0217 P:(217) 696-4411 | F:(217) 696-4811 | www.adams.net [Adams-Logo] ________________________________ The information contained in this email message is PRIVILEGED AND CONFIDENTIAL, and is intended for the use of the addressee and no one else. If you are not the intended recipient, please do not read, distribute, reproduce or use this email message (or the attachments) and notify the sender of the mistaken transmission. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ler762 at gmail.com Tue Jan 1 02:01:03 2019 From: ler762 at gmail.com (Lee) Date: Mon, 31 Dec 2018 21:01:03 -0500 Subject: CenturyLink RCA? In-Reply-To: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> References: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> Message-ID: On 12/31/18, Keith Medcalf wrote: >> It could have been worse: >> https://www.cio.com.au/article/65115/all_systems_down/ > > "Make network changes only between 2am and 5am on weekends." > > Wow. Just wow. yeah. out of all the possible lessons they could have learned.. > I suppose the IT types are considerably different than > Process Operations. Our rule is to only make changes scheduled at 09:00 (or > no later than will permit a complete backout and restore by 15:00) Local > Time on "Full Staff" day that is not immediately preceded or followed by a > reduced staff day, holiday, or weekend-day. Do you get paid differently based on time of day? I used to be at a place where they were drifting into a 'no changes until midnight' mode except for one group; the rumor I heard was they got overtime pay after 6PM which is why they got to do all their changes during the day. Lee From freedman at freedman.net Tue Jan 1 04:56:03 2019 From: freedman at freedman.net (Avi Freedman) Date: Mon, 31 Dec 2018 23:56:03 -0500 (EST) Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> Message-ID: <20190101045603.F1F27F628@freedman.net> We do have a minimum for commercial service that's more like $1500/mo but we are coming out with a free tier in Q1 with lower retention (among other deltas, but including fully slice and dice flow analytics +BGP that it sounded like Erik might be looking for). Feel free to ping me if anyone would like to help us test the free tier in January. Thanks, Avi Freedman CEO, Kentik > Doesn't Kentik cost like $2000 a month minimum? > > > On Mon, Dec 31, 2018 at 11:57 AM Matthew Crocker > wrote: > > > +1 Kentik as well, DDoS, RTBH, Netflow. Cloud based so I don't have to > > worry about it. > > > > On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" < > > nanog-bounces at nanog.org on behalf of bryan at shout.net> wrote: > > > > +1 Kentik ... > > > > We've been using their DDoS/RTBH mitigation with good success. > > > > > > On 12/31/18 3:52 AM, Eric Lindsjö wrote: > > > Hi, > > > > > > We use kentik and we're very happy. Works great, tons of new > > features > > > coming along all the time. Going to start looking into ddos > > detection > > > and mitigation soon. > > > > > > Would recommend. > > > > > > Kind regards, > > > Eric Lindsjö > > > > > > > > > On 12/31/2018 04:29 AM, Erik Sundberg wrote: > > >> > > >> Hi Nanog…. > > >> > > >> We are looking at replacing our Netflow collector. I am wonder what > > >> other service providers are using to collect netflow data off their > > >> Core and Edge Routers. Pros/Cons… What to watch out for any info > > would > > >> help. > > >> > > >> We are mainly looking to analyze the netflow data. Bonus if it does > > >> ddos detection and mitigation. > > >> > > >> We are looking at > > >> > > >> ManageEngine Netflow Analyzer > > >> > > >> PRTG > > >> > > >> Plixer – Scrutinizer > > >> > > >> PeakFlow > > >> > > >> Kentik > > >> > > >> Solarwinds NTA > > >> > > >> Thanks in advance… > > >> > > >> Erik > > >> > > >> > > >> > > ------------------------------------------------------------------------ > > >> > > >> 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. > > > > > > > > > From saku at ytti.fi Tue Jan 1 08:02:53 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 1 Jan 2019 10:02:53 +0200 Subject: CenturyLink In-Reply-To: <15951.1546313466@turing-police.cc.vt.edu> References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> <20181230185854.678a278d@spidey.rellim.com> <15951.1546313466@turing-police.cc.vt.edu> Message-ID: Hey Valdis, ´ > There's another number that's missing - the stability of the drift. Not the way I read it, I read +-1.1us verbatim, drifts is somewhere between 1.1 .. -1.1 in given 24h window. I assume if was constant + +-variable, the constant would already have been engineered out before customer ship. But yes, agreed, high precision is sufficient, high accuracy is not needed as high precision instruments accuracy can be fixed through external mechanism post-fact. -- ++ytti From william.allen.simpson at gmail.com Tue Jan 1 12:05:29 2019 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 1 Jan 2019 07:05:29 -0500 Subject: CenturyLink RCA? In-Reply-To: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> References: <776b43647c16314ca1a54bce3908fddd@mail.dessus.com> Message-ID: On 12/31/18 3:31 PM, Keith Medcalf wrote: >> It could have been worse: >> https://www.cio.com.au/article/65115/all_systems_down/ > > "Make network changes only between 2am and 5am on weekends." > > Wow. Just wow. I suppose the IT types are considerably different than Process Operations. Our rule is to only make changes scheduled at 09:00 (or no later than will permit a complete backout and restore by 15:00) Local Time on "Full Staff" day that is not immediately preceded or followed by a reduced staff day, holiday, or weekend-day. > We had fairly extensive discussion on this list decades ago. Deploy non-emergency changes early Tuesday morning local time, a few hours before regular working hours. Agreed about "not immediately preceded or followed by a reduced staff day, holiday, or weekend-day." Because you won't know it's really working until the actual users have no reported problems. Tuesdays give a couple of working days to ensure that there were no hidden ill affects. Weekends are terrible for that reason. As are Mondays and Fridays, because actual users aren't around in overseas locations. Even those of us who have operated regional ISPs still can effect the world. And those of us with multiple datacenters world-wide have to ensure that changes in one place don't affect the others.... As I remember, at the time this NANOG wisdom propagated to legal blogs. Because so much of what network operators do has legal implications. From nick.z.edwards at gmail.com Tue Jan 1 12:19:18 2019 From: nick.z.edwards at gmail.com (Nick Edwards) Date: Tue, 1 Jan 2019 22:19:18 +1000 Subject: IP Dslams In-Reply-To: References: Message-ID: Firstly, thanks everyone for replies. @Carl: ADSL2 dslams would no doubt be cheaper than VDSL for retirement village, and as a retirement village, residents must be 65+, therefor, they wont have high bandwidth needs, based on their other much older properties, their residents use between 2 and 15GB a month, with an average of 5GB, so VDSL -if not the same cost as ADSL2 dslams, would be a waste, and from my experience ADSL2 is more stable over distances, where the furthest villas are 800 meters away from comms room. As for phones, we are installing a PBXact1000, and for the villas, we will be using a bunch of Vega 3050 50 port Analogue gateways talking to it. These villas are stand alone duplexes, so running ethernet is not feasible They have a PMS which takes care of billing, although if they do what do at other places they run, residents are usually given a 30 dollar a month call credit which is likely included in their monthly "complex maintenance" fees. On Tue, Jan 1, 2019 at 8:12 AM Colton Conor wrote: > Carl, > > What did you select to replace your MX BNG? > > To Nick, we use Adtran Total Access 5000's today. They work fine, but if I > was doing a new install I would do Calix with their newer lines that have > SDN BNG functions. Calix just has better CPE to go along with it, but they > are just G.Fast and ethernet only CPE's. > > Why only ADSL2+? > > What are you doing for voice? > > Do you have access to Coax cable? If so I would do a small 32x10 CMTS with > cable modem. Much cheaper and future proof. > > On Mon, Dec 31, 2018 at 3:47 PM Carl Peterson > wrote: > >> I'd consider breaking down the two functions. >> Set up your customer connections using ADSL Ethernet, etc and put each >> unit in the building on its own CVLAN. This should never change even when >> the subscribers in the unit change. This way you can configure it once and >> never touch it again. I'd use Calix G.fast but I have no idea what your >> budget/wiring looks like and I'm not sure where their e3-48 and E5-48 are >> in general availability. >> >> Then hand the SVLAN with all the CVLANs off to the BNG and authenticate >> the circuits using IPoE. Waystream has an ASR6000 switch with BNG >> functionalities (I've never used it, just came across it when looking for >> other options to replace my MX BNG. >> >> On Mon, Dec 31, 2018 at 1:15 PM Nick Edwards >> wrote: >> >>> Howdy, >>> We have a requirement for an aged care facility to provide voice and >>> data, we have the voice worked out, but data, WiFi is out of the question, >>> so are looking for IP-Dslams, preferably a system that is all-in-one, or >>> self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as >>> has a property managment API, or even just a webpage manager where admin >>> can add in new residents when they arive, or delete when they depart I know >>> these used to be available many years ago, but that vendor has like many >>> vanished, only requirement is for ADSL2+, prefer units with either 48 ports >>> or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 >>> etc) >>> >>> If anyone knows of such units, would appreciate some details on them, >>> brand/model suppliers if known, etc, we can try get out google fu back if >>> we have some steering:) >>> >>> Thank Y'all >>> >>> (resent - original never made it to the list for some gremlin reason) >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Tue Jan 1 12:25:11 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 1 Jan 2019 07:25:11 -0500 Subject: IP Dslams In-Reply-To: References: Message-ID: On 1/1/19 7:19 AM, Nick Edwards wrote: > @Carl:  ADSL2 dslams would no doubt be cheaper than VDSL for retirement > village, and as a retirement village, residents must be 65+, therefor, > they wont have high bandwidth needs, based on their other much older > properties, their residents use between 2 and 15GB a month, with an > average of 5GB, so VDSL -if not the same cost as ADSL2 dslams, would be > a waste, and from my experience ADSL2 is more stable over distances, > where the furthest villas are 800 meters away from comms room. If you're wanting to buy used gear, ADSL2+ DSLAMs are indeed probably cheaper, but you might have trouble finding native IP/Ethernet ones. A lot of the older stuff predating the VDSL era was very ATM-centric. I'm not sure anyone's still really making ADSL2+-only DSLAMs, so I'm not sure a 1:1 cost comparison is even possible on new gear. Note that most VDSL/VSDL2 DSLAMs do support ADSL2/ADSL2+ fallback, so you're not stuck with VDSL if you do have a problematic link, and you've got a bit more future-proofing. You can also get G.FAST DSLAMs with VDSL and ADSL2 fallback if you wanted to really have some future-proofing. 800m is probably pushing it for G.FAST, but VDSL2 should run on that just fine even on crummy old voice-grade copper. Depending on how it's bundled, you might not be able to use every pair in a cable for VDSL2, but if you're putting POTS on a separate pair, that means half your pairs right there are not running DSL at all. Again, with most VDSL DSLAMs, you've got the option of ADSL2 fallback if you do need it on the long-distance links. ADSL2 does have the advantage that you can (probably) run POTS+DSL on the same pair if you need to. I'm not sure that's possible with VDSL, but I'd love someone to prove me wrong. -- Brandon Martin From nick.z.edwards at gmail.com Tue Jan 1 12:31:01 2019 From: nick.z.edwards at gmail.com (Nick Edwards) Date: Tue, 1 Jan 2019 22:31:01 +1000 Subject: IP Dslams In-Reply-To: References: Message-ID: drats that last @ should have been to Colton, my apologies... I have in past used dlink and planet dslams as they were back then dirt cheap, I guess I might have to look at a small mikrotik device that can do all my requirements, just trying to use the KISS approach, as I'm the contractor installing it and wont be the one running it on a day to day as-needed basis, thats their admissions staff who will add/delete them On Tue, Jan 1, 2019 at 10:19 PM Nick Edwards wrote: > Firstly, thanks everyone for replies. > > @Carl: ADSL2 dslams would no doubt be cheaper than VDSL for retirement > village, and as a retirement village, residents must be 65+, therefor, they > wont have high bandwidth needs, based on their other much older properties, > their residents use between 2 and 15GB a month, with an average of 5GB, so > VDSL -if not the same cost as ADSL2 dslams, would be a waste, and from my > experience ADSL2 is more stable over distances, where the furthest villas > are 800 meters away from comms room. > > As for phones, we are installing a PBXact1000, and for the villas, we will > be using a bunch of Vega 3050 50 port Analogue gateways talking to it. > These villas are stand alone duplexes, so running ethernet is not feasible > They have a PMS which takes care of billing, although if they do what do at > other places they run, residents are usually given a 30 dollar a month call > credit which is likely included in their monthly "complex maintenance" fees. > > > On Tue, Jan 1, 2019 at 8:12 AM Colton Conor > wrote: > >> Carl, >> >> What did you select to replace your MX BNG? >> >> To Nick, we use Adtran Total Access 5000's today. They work fine, but if >> I was doing a new install I would do Calix with their newer lines that have >> SDN BNG functions. Calix just has better CPE to go along with it, but they >> are just G.Fast and ethernet only CPE's. >> >> Why only ADSL2+? >> >> What are you doing for voice? >> >> Do you have access to Coax cable? If so I would do a small 32x10 CMTS >> with cable modem. Much cheaper and future proof. >> >> On Mon, Dec 31, 2018 at 3:47 PM Carl Peterson < >> carl-lists at portnetworks.com> wrote: >> >>> I'd consider breaking down the two functions. >>> Set up your customer connections using ADSL Ethernet, etc and put each >>> unit in the building on its own CVLAN. This should never change even when >>> the subscribers in the unit change. This way you can configure it once and >>> never touch it again. I'd use Calix G.fast but I have no idea what your >>> budget/wiring looks like and I'm not sure where their e3-48 and E5-48 are >>> in general availability. >>> >>> Then hand the SVLAN with all the CVLANs off to the BNG and authenticate >>> the circuits using IPoE. Waystream has an ASR6000 switch with BNG >>> functionalities (I've never used it, just came across it when looking for >>> other options to replace my MX BNG. >>> >>> On Mon, Dec 31, 2018 at 1:15 PM Nick Edwards >>> wrote: >>> >>>> Howdy, >>>> We have a requirement for an aged care facility to provide voice and >>>> data, we have the voice worked out, but data, WiFi is out of the question, >>>> so are looking for IP-Dslams, preferably a system that is all-in-one, or >>>> self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as >>>> has a property managment API, or even just a webpage manager where admin >>>> can add in new residents when they arive, or delete when they depart I know >>>> these used to be available many years ago, but that vendor has like many >>>> vanished, only requirement is for ADSL2+, prefer units with either 48 ports >>>> or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 >>>> etc) >>>> >>>> If anyone knows of such units, would appreciate some details on them, >>>> brand/model suppliers if known, etc, we can try get out google fu back if >>>> we have some steering:) >>>> >>>> Thank Y'all >>>> >>>> (resent - original never made it to the list for some gremlin reason) >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Tue Jan 1 03:31:06 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 31 Dec 2018 22:31:06 -0500 Subject: CenturyLink In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318ED1E5D@WAUPRDMBXP1.medline.com> <95957661800c4817b5005d18db2bd85d@linktechs.net> <7f68b2f5-75f2-582e-5048-a2ab85b3fd16@2mbit.com> <20181228080353.ilp6ovvrq3eivijf@nic.fr> <3d01a1b601354b3f971e213e0107e5b8@ox.com> <5df30bd2-7003-7ccf-06bd-a8c8e7c7e983@oneunified.net> <1546180793.98522472@upnet.mymailsrvr.com> <6b00b11fbf704d3e814011d916527fd8@ox.com> <20181230185854.678a278d@spidey.rellim.com> Message-ID: <15951.1546313466@turing-police.cc.vt.edu> On Mon, 31 Dec 2018 10:28:25 +0200, Saku Ytti said: > For the tl;dr folk, crystal drifts +-4.5us per day, Rb +-1.1us (both > seem like unsatisfactorily high numbers to me, i.e. you don't want to > be free-running 24h with Rb). There's another number that's missing - the stability of the drift. I'd rather be dealing with a crystal that's +2.788+/-0.003 than one that's +0.5+/-0.25 From colton.conor at gmail.com Wed Jan 2 04:01:26 2019 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 1 Jan 2019 22:01:26 -0600 Subject: IP Dslams In-Reply-To: References: Message-ID: Indstead of using a Vega 3050 for voice I would just get a DSLAM with a Combo card, and be done with it. VDSL2+ ports plus SIP FXS all on the same card. With that you get metalic testing which would be good for your situation. How many units are you talking about? Do you have access to Coaxial cable? On Tue, Jan 1, 2019 at 6:31 AM Nick Edwards wrote: > drats that last @ should have been to Colton, my apologies... > > I have in past used dlink and planet dslams as they were back then dirt > cheap, I guess I might have to look at a small mikrotik device that can do > all my requirements, just trying to use the KISS approach, as I'm the > contractor installing it and wont be the one running it on a day to day > as-needed basis, thats their admissions staff who will add/delete them > > On Tue, Jan 1, 2019 at 10:19 PM Nick Edwards > wrote: > >> Firstly, thanks everyone for replies. >> >> @Carl: ADSL2 dslams would no doubt be cheaper than VDSL for retirement >> village, and as a retirement village, residents must be 65+, therefor, they >> wont have high bandwidth needs, based on their other much older properties, >> their residents use between 2 and 15GB a month, with an average of 5GB, so >> VDSL -if not the same cost as ADSL2 dslams, would be a waste, and from my >> experience ADSL2 is more stable over distances, where the furthest villas >> are 800 meters away from comms room. >> >> As for phones, we are installing a PBXact1000, and for the villas, we >> will be using a bunch of Vega 3050 50 port Analogue gateways talking to it. >> These villas are stand alone duplexes, so running ethernet is not feasible >> They have a PMS which takes care of billing, although if they do what do at >> other places they run, residents are usually given a 30 dollar a month call >> credit which is likely included in their monthly "complex maintenance" fees. >> >> >> On Tue, Jan 1, 2019 at 8:12 AM Colton Conor >> wrote: >> >>> Carl, >>> >>> What did you select to replace your MX BNG? >>> >>> To Nick, we use Adtran Total Access 5000's today. They work fine, but if >>> I was doing a new install I would do Calix with their newer lines that have >>> SDN BNG functions. Calix just has better CPE to go along with it, but they >>> are just G.Fast and ethernet only CPE's. >>> >>> Why only ADSL2+? >>> >>> What are you doing for voice? >>> >>> Do you have access to Coax cable? If so I would do a small 32x10 CMTS >>> with cable modem. Much cheaper and future proof. >>> >>> On Mon, Dec 31, 2018 at 3:47 PM Carl Peterson < >>> carl-lists at portnetworks.com> wrote: >>> >>>> I'd consider breaking down the two functions. >>>> Set up your customer connections using ADSL Ethernet, etc and put each >>>> unit in the building on its own CVLAN. This should never change even when >>>> the subscribers in the unit change. This way you can configure it once and >>>> never touch it again. I'd use Calix G.fast but I have no idea what your >>>> budget/wiring looks like and I'm not sure where their e3-48 and E5-48 are >>>> in general availability. >>>> >>>> Then hand the SVLAN with all the CVLANs off to the BNG and authenticate >>>> the circuits using IPoE. Waystream has an ASR6000 switch with BNG >>>> functionalities (I've never used it, just came across it when looking for >>>> other options to replace my MX BNG. >>>> >>>> On Mon, Dec 31, 2018 at 1:15 PM Nick Edwards >>>> wrote: >>>> >>>>> Howdy, >>>>> We have a requirement for an aged care facility to provide voice and >>>>> data, we have the voice worked out, but data, WiFi is out of the question, >>>>> so are looking for IP-Dslams, preferably a system that is all-in-one, or >>>>> self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as >>>>> has a property managment API, or even just a webpage manager where admin >>>>> can add in new residents when they arive, or delete when they depart I know >>>>> these used to be available many years ago, but that vendor has like many >>>>> vanished, only requirement is for ADSL2+, prefer units with either 48 ports >>>>> or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 >>>>> etc) >>>>> >>>>> If anyone knows of such units, would appreciate some details on them, >>>>> brand/model suppliers if known, etc, we can try get out google fu back if >>>>> we have some steering:) >>>>> >>>>> Thank Y'all >>>>> >>>>> (resent - original never made it to the list for some gremlin reason) >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.z.edwards at gmail.com Wed Jan 2 11:47:34 2019 From: nick.z.edwards at gmail.com (Nick Edwards) Date: Wed, 2 Jan 2019 21:47:34 +1000 Subject: IP Dslams In-Reply-To: References: Message-ID: Thanks, do you have any brand DSLAM with combo card in mind? There are 260 villas, and no coax. On Wed, Jan 2, 2019 at 2:01 PM Colton Conor wrote: > Indstead of using a Vega 3050 for voice I would just get a DSLAM with a > Combo card, and be done with it. VDSL2+ ports plus SIP FXS all on the same > card. With that you get metalic testing which would be good for your > situation. > > How many units are you talking about? Do you have access to Coaxial cable? > > On Tue, Jan 1, 2019 at 6:31 AM Nick Edwards > wrote: > >> drats that last @ should have been to Colton, my apologies... >> >> I have in past used dlink and planet dslams as they were back then dirt >> cheap, I guess I might have to look at a small mikrotik device that can do >> all my requirements, just trying to use the KISS approach, as I'm the >> contractor installing it and wont be the one running it on a day to day >> as-needed basis, thats their admissions staff who will add/delete them >> >> On Tue, Jan 1, 2019 at 10:19 PM Nick Edwards >> wrote: >> >>> Firstly, thanks everyone for replies. >>> >>> @Carl: ADSL2 dslams would no doubt be cheaper than VDSL for retirement >>> village, and as a retirement village, residents must be 65+, therefor, they >>> wont have high bandwidth needs, based on their other much older properties, >>> their residents use between 2 and 15GB a month, with an average of 5GB, so >>> VDSL -if not the same cost as ADSL2 dslams, would be a waste, and from my >>> experience ADSL2 is more stable over distances, where the furthest villas >>> are 800 meters away from comms room. >>> >>> As for phones, we are installing a PBXact1000, and for the villas, we >>> will be using a bunch of Vega 3050 50 port Analogue gateways talking to it. >>> These villas are stand alone duplexes, so running ethernet is not feasible >>> They have a PMS which takes care of billing, although if they do what do at >>> other places they run, residents are usually given a 30 dollar a month call >>> credit which is likely included in their monthly "complex maintenance" fees. >>> >>> >>> On Tue, Jan 1, 2019 at 8:12 AM Colton Conor >>> wrote: >>> >>>> Carl, >>>> >>>> What did you select to replace your MX BNG? >>>> >>>> To Nick, we use Adtran Total Access 5000's today. They work fine, but >>>> if I was doing a new install I would do Calix with their newer lines that >>>> have SDN BNG functions. Calix just has better CPE to go along with it, but >>>> they are just G.Fast and ethernet only CPE's. >>>> >>>> Why only ADSL2+? >>>> >>>> What are you doing for voice? >>>> >>>> Do you have access to Coax cable? If so I would do a small 32x10 CMTS >>>> with cable modem. Much cheaper and future proof. >>>> >>>> On Mon, Dec 31, 2018 at 3:47 PM Carl Peterson < >>>> carl-lists at portnetworks.com> wrote: >>>> >>>>> I'd consider breaking down the two functions. >>>>> Set up your customer connections using ADSL Ethernet, etc and put each >>>>> unit in the building on its own CVLAN. This should never change even when >>>>> the subscribers in the unit change. This way you can configure it once and >>>>> never touch it again. I'd use Calix G.fast but I have no idea what your >>>>> budget/wiring looks like and I'm not sure where their e3-48 and E5-48 are >>>>> in general availability. >>>>> >>>>> Then hand the SVLAN with all the CVLANs off to the BNG and >>>>> authenticate the circuits using IPoE. Waystream has an ASR6000 switch with >>>>> BNG functionalities (I've never used it, just came across it when looking >>>>> for other options to replace my MX BNG. >>>>> >>>>> On Mon, Dec 31, 2018 at 1:15 PM Nick Edwards >>>>> wrote: >>>>> >>>>>> Howdy, >>>>>> We have a requirement for an aged care facility to provide voice and >>>>>> data, we have the voice worked out, but data, WiFi is out of the question, >>>>>> so are looking for IP-Dslams, preferably a system that is all-in-one, or >>>>>> self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as >>>>>> has a property managment API, or even just a webpage manager where admin >>>>>> can add in new residents when they arive, or delete when they depart I know >>>>>> these used to be available many years ago, but that vendor has like many >>>>>> vanished, only requirement is for ADSL2+, prefer units with either 48 ports >>>>>> or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 >>>>>> etc) >>>>>> >>>>>> If anyone knows of such units, would appreciate some details on >>>>>> them, brand/model suppliers if known, etc, we can try get out google fu >>>>>> back if we have some steering:) >>>>>> >>>>>> Thank Y'all >>>>>> >>>>>> (resent - original never made it to the list for some gremlin reason) >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hibaysal at gmail.com Wed Jan 2 11:50:42 2019 From: hibaysal at gmail.com (H I Baysal) Date: Wed, 2 Jan 2019 12:50:42 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: <20190101045603.F1F27F628@freedman.net> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> Message-ID: <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> PMACCT (Works Awesome) push to influxdb ( Works awesome) With some custom scripts to add/match interface descriptions. And you can query whatever you want in grafana :D And grafana has a nice API for rendering a dashboardgraph to a PNG and you can send this png to whatever chat/bot or mail you want. And all for free with 99% of accuracy. (Mucho gracias to Paulo :D ) On 01-01-19 05:56, Avi Freedman wrote: > We do have a minimum for commercial service that's more like $1500/mo but we are coming out with a free tier in Q1 with lower retention (among other deltas, but including fully slice and dice flow analytics +BGP that it sounded like Erik might be looking for). > > Feel free to ping me if anyone would like to help us test the free tier in January. > > Thanks, > > Avi Freedman > CEO, Kentik > >> Doesn't Kentik cost like $2000 a month minimum? >> >> >> On Mon, Dec 31, 2018 at 11:57 AM Matthew Crocker >> wrote: >> >>> +1 Kentik as well, DDoS, RTBH, Netflow. Cloud based so I don't have to >>> worry about it. >>> >>> On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" < >>> nanog-bounces at nanog.org on behalf of bryan at shout.net> wrote: >>> >>> +1 Kentik ... >>> >>> We've been using their DDoS/RTBH mitigation with good success. >>> >>> >>> On 12/31/18 3:52 AM, Eric Lindsjö wrote: >>> > Hi, >>> > >>> > We use kentik and we're very happy. Works great, tons of new >>> features >>> > coming along all the time. Going to start looking into ddos >>> detection >>> > and mitigation soon. >>> > >>> > Would recommend. >>> > >>> > Kind regards, >>> > Eric Lindsjö >>> > >>> > >>> > On 12/31/2018 04:29 AM, Erik Sundberg wrote: >>> >> >>> >> Hi Nanog…. >>> >> >>> >> We are looking at replacing our Netflow collector. I am wonder what >>> >> other service providers are using to collect netflow data off their >>> >> Core and Edge Routers. Pros/Cons… What to watch out for any info >>> would >>> >> help. >>> >> >>> >> We are mainly looking to analyze the netflow data. Bonus if it does >>> >> ddos detection and mitigation. >>> >> >>> >> We are looking at >>> >> >>> >> ManageEngine Netflow Analyzer >>> >> >>> >> PRTG >>> >> >>> >> Plixer – Scrutinizer >>> >> >>> >> PeakFlow >>> >> >>> >> Kentik >>> >> >>> >> Solarwinds NTA >>> >> >>> >> Thanks in advance… >>> >> >>> >> Erik >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------ >>> >> >>> >> 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. >>> > >>> >>> >>> From lists.nanog at monmotha.net Wed Jan 2 11:54:56 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 2 Jan 2019 06:54:56 -0500 Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> Message-ID: On 12/14/18 11:51 AM, Mikael Abrahamsson wrote: > We use this to configure LW4o6 tunnels using DHCPv6. This is already > present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6. So I guess you're deploying "RG" style CPE routers to your customers that you've loaded OpenWRT onto? How's the maintainability of that? Any hardware recommendations? The mechanisms mentioned in this thread are exactly what I'm looking for, but I'm having trouble finding any COTS vendor support for them. I'm sure if I wanted to buy 100k units, somebody would put out some custom firmware for me, but as the network I'm doing this on is a brand new startup in a somewhat sparsely populated area, I'd be buying dozens at a time, not thousands. -- Brandon Martin From raphael.timothy at gmail.com Wed Jan 2 12:08:10 2019 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 2 Jan 2019 20:08:10 +0800 Subject: Service Provider NetFlow Collectors In-Reply-To: <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> Message-ID: I would advise against InfluxDB in this case - flow data has a very high (and open) tag cardinality which is not suited to Influx (although their recently new index format has improved this). I’m currently pushing sFlow through Pmacct —> Kafka —> Clickhouse (columnar store) with a summing merge tree database engine. Clickhouse is very fast for queries across columns as well as aggregating down them (e.g. summing number of bytes). For example this is the results of a query of nearly a year’s worth of MAC-to-MAC flows (7-tuple) queried for the last 7 days between two given sets of MACs: 2016 rows in set. Elapsed: 0.208 sec. Processed 17.56 million rows, 1.03 GB (84.51 million rows/s., 4.97 GB/s.) There is also a Grafana datasource plugin for Clickhouse :) - Tim > On 2 Jan 2019, at 7:50 pm, H I Baysal wrote: > > PMACCT (Works Awesome) > push to influxdb ( Works awesome) > > With some custom scripts to add/match interface descriptions. And you can query whatever you want in grafana :D > And grafana has a nice API for rendering a dashboardgraph to a PNG and you can send this png to whatever chat/bot or mail you want. > > And all for free with 99% of accuracy. > > (Mucho gracias to Paulo :D ) > > > On 01-01-19 05:56, Avi Freedman wrote: >> We do have a minimum for commercial service that's more like $1500/mo but we are coming out with a free tier in Q1 with lower retention (among other deltas, but including fully slice and dice flow analytics +BGP that it sounded like Erik might be looking for). >> >> Feel free to ping me if anyone would like to help us test the free tier in January. >> >> Thanks, >> >> Avi Freedman >> CEO, Kentik >> >>> Doesn't Kentik cost like $2000 a month minimum? >>> >>> >>> On Mon, Dec 31, 2018 at 11:57 AM Matthew Crocker >>> wrote: >>> >>>> +1 Kentik as well, DDoS, RTBH, Netflow. Cloud based so I don't have to >>>> worry about it. >>>> >>>> On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" < >>>> nanog-bounces at nanog.org on behalf of bryan at shout.net> wrote: >>>> >>>> +1 Kentik ... >>>> >>>> We've been using their DDoS/RTBH mitigation with good success. >>>> >>>> >>>> On 12/31/18 3:52 AM, Eric Lindsjö wrote: >>>> > Hi, >>>> > >>>> > We use kentik and we're very happy. Works great, tons of new >>>> features >>>> > coming along all the time. Going to start looking into ddos >>>> detection >>>> > and mitigation soon. >>>> > >>>> > Would recommend. >>>> > >>>> > Kind regards, >>>> > Eric Lindsjö >>>> > >>>> > >>>> > On 12/31/2018 04:29 AM, Erik Sundberg wrote: >>>> >> >>>> >> Hi Nanog…. >>>> >> >>>> >> We are looking at replacing our Netflow collector. I am wonder what >>>> >> other service providers are using to collect netflow data off their >>>> >> Core and Edge Routers. Pros/Cons… What to watch out for any info >>>> would >>>> >> help. >>>> >> >>>> >> We are mainly looking to analyze the netflow data. Bonus if it does >>>> >> ddos detection and mitigation. >>>> >> >>>> >> We are looking at >>>> >> >>>> >> ManageEngine Netflow Analyzer >>>> >> >>>> >> PRTG >>>> >> >>>> >> Plixer – Scrutinizer >>>> >> >>>> >> PeakFlow >>>> >> >>>> >> Kentik >>>> >> >>>> >> Solarwinds NTA >>>> >> >>>> >> Thanks in advance… >>>> >> >>>> >> Erik >>>> >> >>>> >> >>>> >> >>>> ------------------------------------------------------------------------ >>>> >> >>>> >> 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. >>>> > >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Wed Jan 2 12:20:51 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 2 Jan 2019 14:20:51 +0200 Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> Message-ID: Hey Tim, > I would advise against InfluxDB in this case - flow data has a very high (and open) tag cardinality which is not suited to Influx (although their recently new index format has improved this). I'm not entirely sure I understand. Does this mean the permutations of tags are high, i.e. series count is high? If so, isn't this general problem and advice against all TSDBs? If so, I fully agree, you couldn't/shouldn't make for example IP addresses your tags, potentially creating 2**32*2 series without any other tags, it's rather non-sensical proposal in TSDB. Influx themselves comment that >10M series is likely infeasible. So you need unique tag combinations to be low millions at most. -- ++ytti From hibaysal at gmail.com Wed Jan 2 12:37:29 2019 From: hibaysal at gmail.com (H I Baysal) Date: Wed, 2 Jan 2019 13:37:29 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> Message-ID: <9da01caa-62fc-b27a-efdc-b2c67e0e97ef@gmail.com> Hi Tim, That absolutely depends on the amount of TAGs you use, and how you aggregate, etc. I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even sweating a single drop.... We have a 4 Tbps of traffic during peak, and as well as pmacct and influxdb or running very very smooth. (With the mentioned aggregations I can see what a single customer costs with Transit, Peering and IX (per IP even if needed) ) And dst AS per port/description/ethernet name From your mail i derive that you just pushed everything to influx from flows, you have to be a bit smarter with the layout, aggregations and continuous queries. (collect what you need) On 02-01-19 13:08, Tim Raphael wrote: > I would advise against InfluxDB in this case - flow data has a very > high (and open) tag cardinality which is not suited to Influx > (although their recently new index format has improved this). > > I’m currently pushing sFlow through Pmacct —> Kafka —> Clickhouse > (columnar store) with a summing merge tree database engine. > Clickhouse is very fast for queries across columns as well as > aggregating down them (e.g. summing number of bytes). > > For example this is the results of a query of nearly a year’s worth of > MAC-to-MAC flows (7-tuple) queried for the last 7 days between two > given sets of MACs: > / > / > /2016 rows in set. Elapsed: 0.208 sec. Processed 17.56 million rows, > 1.03 GB (84.51 million rows/s., 4.97 GB/s.)/ > / > / > There is also a Grafana datasource plugin for Clickhouse :) > / > / > /- /Tim > > >> On 2 Jan 2019, at 7:50 pm, H I Baysal > > wrote: >> >> PMACCT (Works Awesome) >> push to influxdb ( Works awesome) >> >> With some custom scripts to add/match interface descriptions. And you >> can query whatever you want in grafana :D >> And grafana has a nice API for rendering a dashboardgraph to a PNG >> and you can send this png to whatever chat/bot or mail you want. >> >> And all for free with 99% of accuracy. >> >> (Mucho gracias to Paulo :D ) >> >> >> On 01-01-19 05:56, Avi Freedman wrote: >>> We do have a minimum for commercial service that's more like >>> $1500/mo but we are coming out with a free tier in Q1 with lower >>> retention (among other deltas, but including fully slice and dice >>> flow analytics +BGP that it sounded like Erik might be looking for). >>> >>> Feel free to ping me if anyone would like to help us test the free >>> tier in January. >>> >>> Thanks, >>> >>> Avi Freedman >>> CEO, Kentik >>> >>>> Doesn't Kentik cost like $2000 a month minimum? >>>> >>>> >>>> On Mon, Dec 31, 2018 at 11:57 AM Matthew Crocker >>>> > >>>> wrote: >>>> >>>>>  +1 Kentik as well,  DDoS, RTBH, Netflow.  Cloud based so I don't >>>>> have to >>>>> worry about it. >>>>> >>>>> On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" < >>>>> nanog-bounces at nanog.org on behalf >>>>> of bryan at shout.net > wrote: >>>>> >>>>>     +1 Kentik ... >>>>> >>>>>     We've been using their DDoS/RTBH mitigation with good success. >>>>> >>>>> >>>>>     On 12/31/18 3:52 AM, Eric Lindsjö wrote: >>>>>     > Hi, >>>>>     > >>>>>     > We use kentik and we're very happy. Works great, tons of new >>>>> features >>>>>     > coming along all the time. Going to start looking into ddos >>>>> detection >>>>>     > and mitigation soon. >>>>>     > >>>>>     > Would recommend. >>>>>     > >>>>>     > Kind regards, >>>>>     > Eric Lindsjö >>>>>     > >>>>>     > >>>>>     > On 12/31/2018 04:29 AM, Erik Sundberg wrote: >>>>>     >> >>>>>     >> Hi Nanog…. >>>>>     >> >>>>>     >> We are looking at replacing our Netflow collector. I am >>>>> wonder what >>>>>     >> other service providers are using to collect netflow data >>>>> off their >>>>>     >> Core and Edge Routers. Pros/Cons… What to watch out for any >>>>> info >>>>> would >>>>>     >> help. >>>>>     >> >>>>>     >> We are mainly looking to analyze the netflow data. Bonus if >>>>> it does >>>>>     >> ddos detection and mitigation. >>>>>     >> >>>>>     >> We are looking at >>>>>     >> >>>>>     >> ManageEngine Netflow Analyzer >>>>>     >> >>>>>     >> PRTG >>>>>     >> >>>>>     >> Plixer – Scrutinizer >>>>>     >> >>>>>     >> PeakFlow >>>>>     >> >>>>>     >> Kentik >>>>>     >> >>>>>     >> Solarwinds NTA >>>>>     >> >>>>>     >> Thanks in advance… >>>>>     >> >>>>>     >> Erik >>>>>     >> >>>>>     >> >>>>>     >> >>>>> ------------------------------------------------------------------------ >>>>>     >> >>>>>     >> 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. >>>>>     > >>>>> >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Wed Jan 2 12:37:37 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Jan 2019 13:37:37 +0100 (CET) Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> Message-ID: On Wed, 2 Jan 2019, Brandon Martin wrote: > On 12/14/18 11:51 AM, Mikael Abrahamsson wrote: >> We use this to configure LW4o6 tunnels using DHCPv6. This is already >> present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6. > > So I guess you're deploying "RG" style CPE routers to your customers that > you've loaded OpenWRT onto? How's the maintainability of that? Any hardware > recommendations? Yes, we're buying devices from a vendor that uses OpenWrt as base for their operating system. We're using this one currently: https://www.intenogroup.com/products/gateways/eg400/ We remotely manage it using Netconf/YANG from our NMS so we can do software upgrades (and other management). If you have low volume you can of course use SSH and script it if that's what you want. They also have TR-69 based management, and perhaps others. > The mechanisms mentioned in this thread are exactly what I'm looking for, but > I'm having trouble finding any COTS vendor support for them. I'm sure if I > wanted to buy 100k units, somebody would put out some custom firmware for me, > but as the network I'm doing this on is a brand new startup in a somewhat > sparsely populated area, I'd be buying dozens at a time, not thousands. Get in touch with them, tell them I said hi. They might be able to accomodate your low volume by sending you gateways with their default software on it and you'd have to upgrade it to whatever image you want on it, yourself. It only takes a few minutes per box so should be perfectly doable with your low volume. -- Mikael Abrahamsson email: swmike at swm.pp.se From raphael.timothy at gmail.com Wed Jan 2 12:48:32 2019 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 2 Jan 2019 20:48:32 +0800 Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> Message-ID: This is correct, With a flow database you want to be able to say: “show me all HTTP traffic from subnet a.b.c.0/24” which requires you to either keep individual IPs or aggregate subnets. Combined with port and protocol data for both source and destination, the series count shoots way above 10M. - Tim > On 2 Jan 2019, at 20:20, Saku Ytti wrote: > > Hey Tim, > >> I would advise against InfluxDB in this case - flow data has a very high (and open) tag cardinality which is not suited to Influx (although their recently new index format has improved this). > > I'm not entirely sure I understand. Does this mean the permutations of > tags are high, i.e. series count is high? If so, isn't this general > problem and advice against all TSDBs? If so, I fully agree, you > couldn't/shouldn't make for example IP addresses your tags, > potentially creating 2**32*2 series without any other tags, it's > rather non-sensical proposal in TSDB. > > Influx themselves comment that >10M series is likely infeasible. So > you need unique tag combinations to be low millions at most. > -- > ++ytti From lists.nanog at monmotha.net Wed Jan 2 12:48:40 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 2 Jan 2019 07:48:40 -0500 Subject: IP Dslams In-Reply-To: References: Message-ID: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> On 1/2/19 6:47 AM, Nick Edwards wrote: > There are 260 villas, and no coax. Is there a logical way to distribute the termination? You might be able to get better performance (not that you perhaps care, in this case) at minimal additional cost if you can do building-local termination of each customer circuit and then backhaul on e.g. bonded VDSL2 or G.FAST over shorter distances (perhaps hopping building to building). I'm assuming there's no data grade copper or fiber if there's no coax. Obviously if you've got those, distributed termination makes even more sense. If you do want a centralized solution, an Adtran TA5006 (the small chassis) with 6x 48 port VDSL2 combo modules (with or without vectoring, depending on your needs) would do the job (though it fills the chassis and doesn't allow for expansion, so the full-size TA5000 may be desirable). I've played (and am playing with) the same system but with GPON termination and have been happy with it so far. -- Brandon Martin From lists.nanog at monmotha.net Wed Jan 2 12:59:21 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 2 Jan 2019 07:59:21 -0500 Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> Message-ID: <946cd5b5-5404-4924-e15e-130baacac9d9@monmotha.net> On 1/2/19 7:37 AM, Mikael Abrahamsson wrote: > > Yes, we're buying devices from a vendor that uses OpenWrt as base for > their operating system. We're using this one currently: > > https://www.intenogroup.com/products/gateways/eg400/ > > We remotely manage it using Netconf/YANG from our NMS so we can do > software upgrades (and other management). If you have low volume you can > of course use SSH and script it if that's what you want. They also have > TR-69 based management, and perhaps others. If only Ubiquiti had so many (documented) options for management... > Get in touch with them, tell them I said hi. They might be able to > accomodate your low volume by sending you gateways with their default > software on it and you'd have to upgrade it to whatever image you want > on it, yourself. It only takes a few minutes per box so should be > perfectly doable with your low volume That could work. I'll give them a shout. Thanks for the pointer. Out of curiosity, what do you use to terminate the MAP/LW4o6 tunnels/encaps to the public Internet? Plenty of options here, of course, especially at the traffic rates I'm moving. I'm just curious what others' experiences have been as these are still somewhat new in SP deployments, I think. -- Brandon Martin From saku at ytti.fi Wed Jan 2 12:59:22 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 2 Jan 2019 14:59:22 +0200 Subject: Service Provider NetFlow Collectors In-Reply-To: <9da01caa-62fc-b27a-efdc-b2c67e0e97ef@gmail.com> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> <9da01caa-62fc-b27a-efdc-b2c67e0e97ef@gmail.com> Message-ID: Hey, On Wed, 2 Jan 2019 at 14:40, H I Baysal wrote: > That absolutely depends on the amount of TAGs you use, and how you aggregate, etc. > I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even sweating a single drop.... > > We have a 4 Tbps of traffic during peak, and as well as pmacct and influxdb or running very very smooth. How many series do you have in the DB? Your explanation makes it unclear to me what labels you have 'per IP' is ambiguous to me. If only DST_IP is tag and you have low amount of IPs in or behind your network, it seems very feasible indeed. -- ++ytti From swmike at swm.pp.se Wed Jan 2 13:09:51 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Jan 2019 14:09:51 +0100 (CET) Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: <946cd5b5-5404-4924-e15e-130baacac9d9@monmotha.net> References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> <946cd5b5-5404-4924-e15e-130baacac9d9@monmotha.net> Message-ID: On Wed, 2 Jan 2019, Brandon Martin wrote: > Out of curiosity, what do you use to terminate the MAP/LW4o6 tunnels/encaps > to the public Internet? Plenty of options here, of course, especially at the > traffic rates I'm moving. I'm just curious what others' experiences have > been as these are still somewhat new in SP deployments, I think. We use https://github.com/snabbco/snabb lwAFTR. We deploy an anycast based solution with self-check and ExaBGP to announce the anycast next-hop the RGs after the lwAFTR instance passes its self check. That means we can deploy these geographically diversely and also with redundancy, and can hitlessly take them out of service if needed. -- Mikael Abrahamsson email: swmike at swm.pp.se From raphael.timothy at gmail.com Wed Jan 2 13:43:20 2019 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 2 Jan 2019 21:43:20 +0800 Subject: Service Provider NetFlow Collectors In-Reply-To: <9da01caa-62fc-b27a-efdc-b2c67e0e97ef@gmail.com> References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> <9da01caa-62fc-b27a-efdc-b2c67e0e97ef@gmail.com> Message-ID: <54504BE9-6725-46EF-AE64-94472DA5F2DE@gmail.com> That’s a much better cardinality (AS based) but it’s not the general case. Even if you want per-prefix information I’d argue that Influx would still not handle the load (~700k ^ 2 cardinality). For limited tag-sets it would do the trick. I never did attempt to push it to Influx with some foresight that it’d be suboptimal for my ultimate use cases. I wanted a solution that could handle a wide range of use cases without having to worry about limits on tag-sets. I found Clickhouse able to do what I wanted in a performant way. - Tim > On 2 Jan 2019, at 20:37, H I Baysal wrote: > > Hi Tim, > > That absolutely depends on the amount of TAGs you use, and how you aggregate, etc. > I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even sweating a single drop.... > > We have a 4 Tbps of traffic during peak, and as well as pmacct and influxdb or running very very smooth. > > (With the mentioned aggregations I can see what a single customer costs with Transit, Peering and IX (per IP even if needed) ) > And dst AS per port/description/ethernet name > > From your mail i derive that you just pushed everything to influx from flows, you have to be a bit smarter with the layout, aggregations and continuous queries. > (collect what you need) > > > >> On 02-01-19 13:08, Tim Raphael wrote: >> I would advise against InfluxDB in this case - flow data has a very high (and open) tag cardinality which is not suited to Influx (although their recently new index format has improved this). >> >> I’m currently pushing sFlow through Pmacct —> Kafka —> Clickhouse (columnar store) with a summing merge tree database engine. >> Clickhouse is very fast for queries across columns as well as aggregating down them (e.g. summing number of bytes). >> >> For example this is the results of a query of nearly a year’s worth of MAC-to-MAC flows (7-tuple) queried for the last 7 days between two given sets of MACs: >> >> 2016 rows in set. Elapsed: 0.208 sec. Processed 17.56 million rows, 1.03 GB (84.51 million rows/s., 4.97 GB/s.) >> >> There is also a Grafana datasource plugin for Clickhouse :) >> >> - Tim >> >> >>> On 2 Jan 2019, at 7:50 pm, H I Baysal wrote: >>> >>> PMACCT (Works Awesome) >>> push to influxdb ( Works awesome) >>> >>> With some custom scripts to add/match interface descriptions. And you can query whatever you want in grafana :D >>> And grafana has a nice API for rendering a dashboardgraph to a PNG and you can send this png to whatever chat/bot or mail you want. >>> >>> And all for free with 99% of accuracy. >>> >>> (Mucho gracias to Paulo :D ) >>> >>> >>>> On 01-01-19 05:56, Avi Freedman wrote: >>>> We do have a minimum for commercial service that's more like $1500/mo but we are coming out with a free tier in Q1 with lower retention (among other deltas, but including fully slice and dice flow analytics +BGP that it sounded like Erik might be looking for). >>>> >>>> Feel free to ping me if anyone would like to help us test the free tier in January. >>>> >>>> Thanks, >>>> >>>> Avi Freedman >>>> CEO, Kentik >>>> >>>>> Doesn't Kentik cost like $2000 a month minimum? >>>>> >>>>> >>>>> On Mon, Dec 31, 2018 at 11:57 AM Matthew Crocker >>>>> wrote: >>>>> >>>>>> +1 Kentik as well, DDoS, RTBH, Netflow. Cloud based so I don't have to >>>>>> worry about it. >>>>>> >>>>>> On 12/31/18, 11:37 AM, "NANOG on behalf of Bryan Holloway" < >>>>>> nanog-bounces at nanog.org on behalf of bryan at shout.net> wrote: >>>>>> >>>>>> +1 Kentik ... >>>>>> >>>>>> We've been using their DDoS/RTBH mitigation with good success. >>>>>> >>>>>> >>>>>> On 12/31/18 3:52 AM, Eric Lindsjö wrote: >>>>>> > Hi, >>>>>> > >>>>>> > We use kentik and we're very happy. Works great, tons of new >>>>>> features >>>>>> > coming along all the time. Going to start looking into ddos >>>>>> detection >>>>>> > and mitigation soon. >>>>>> > >>>>>> > Would recommend. >>>>>> > >>>>>> > Kind regards, >>>>>> > Eric Lindsjö >>>>>> > >>>>>> > >>>>>> > On 12/31/2018 04:29 AM, Erik Sundberg wrote: >>>>>> >> >>>>>> >> Hi Nanog…. >>>>>> >> >>>>>> >> We are looking at replacing our Netflow collector. I am wonder what >>>>>> >> other service providers are using to collect netflow data off their >>>>>> >> Core and Edge Routers. Pros/Cons… What to watch out for any info >>>>>> would >>>>>> >> help. >>>>>> >> >>>>>> >> We are mainly looking to analyze the netflow data. Bonus if it does >>>>>> >> ddos detection and mitigation. >>>>>> >> >>>>>> >> We are looking at >>>>>> >> >>>>>> >> ManageEngine Netflow Analyzer >>>>>> >> >>>>>> >> PRTG >>>>>> >> >>>>>> >> Plixer – Scrutinizer >>>>>> >> >>>>>> >> PeakFlow >>>>>> >> >>>>>> >> Kentik >>>>>> >> >>>>>> >> Solarwinds NTA >>>>>> >> >>>>>> >> Thanks in advance… >>>>>> >> >>>>>> >> Erik >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> ------------------------------------------------------------------------ >>>>>> >> >>>>>> >> 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. >>>>>> > >>>>>> >>>>>> >>>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Wed Jan 2 13:59:13 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 2 Jan 2019 13:59:13 +0000 Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> Message-ID: > Doesn't Kentik cost like $2000 a month minimum? We recently got a quote from Kentik and I fell off my chair. The annual cost was slightly more than the total upfront purchase cost of the hardware they were collecting Flow from and was significantly more than the total cost each year of running the network (when factoring in power, cross-connects, transit, etc.). I'm told that collecting Flow and BGP from two routers which both do < 10Gbit is "~$32K USD per year for Kentik Pro" - even that feels disproportionally expensive. It does look like an excellent product though I'm struggling to find a business case that justifies the cost on relatively small (sub 2 Tbit/s) networks. From lee.howard at retevia.net Wed Jan 2 15:10:17 2019 From: lee.howard at retevia.net (Lee Howard) Date: Wed, 2 Jan 2019 10:10:17 -0500 Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: <946cd5b5-5404-4924-e15e-130baacac9d9@monmotha.net> References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> <946cd5b5-5404-4924-e15e-130baacac9d9@monmotha.net> Message-ID: <3511d6ce-12f7-b848-e3d6-2f0254b1f8ab@retevia.net> On 1/2/19 7:59 AM, Brandon Martin wrote: > On 1/2/19 7:37 AM, Mikael Abrahamsson wrote: >> >> Yes, we're buying devices from a vendor that uses OpenWrt as base for >> their operating system. We're using this one currently: >> >> https://www.intenogroup.com/products/gateways/eg400/ >> >> We remotely manage it using Netconf/YANG from our NMS so we can do >> software upgrades (and other management). If you have low volume you >> can of course use SSH and script it if that's what you want. They >> also have TR-69 based management, and perhaps others. > > If only Ubiquiti had so many (documented) options for management... DHCPv6 is fine. Jordi did a panel a year ago at APNIC where he browbeat vendors about supporting transition mechanisms. The summary is that they said they have code, they just don't want to ship everything, because it's more to maintain. https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/ This led to the draft he mentioned upthread, requiring support. OpenWRT is still the only thing I've seen that wasn't a customer-specific build. > >> Get in touch with them, tell them I said hi. They might be able to >> accomodate your low volume by sending you gateways with their default >> software on it and you'd have to upgrade it to whatever image you >> want on it, yourself. It only takes a few minutes per box so should >> be perfectly doable with your low volume > That could work.  I'll give them a shout.  Thanks for the pointer. > > Out of curiosity, what do you use to terminate the MAP/LW4o6 > tunnels/encaps to the public Internet?  Plenty of options here, of > course, especially at the traffic rates I'm moving.  I'm just curious > what others' experiences have been as these are still somewhat new in > SP deployments, I think. Open source software. For stateless transition mechanisms (MAP/LW4o6) it can be really fast. We have a build I'd be happy to share, if you want. Lee From lists.nanog at monmotha.net Wed Jan 2 15:47:00 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 2 Jan 2019 10:47:00 -0500 Subject: Auto-configuring IPv6 transition mechanisms on customer devices In-Reply-To: <3511d6ce-12f7-b848-e3d6-2f0254b1f8ab@retevia.net> References: <49e3529a-a9de-7c81-fa1a-23504b4a840b@monmotha.net> <946cd5b5-5404-4924-e15e-130baacac9d9@monmotha.net> <3511d6ce-12f7-b848-e3d6-2f0254b1f8ab@retevia.net> Message-ID: On 1/2/19 10:10 AM, Lee Howard wrote: > > DHCPv6 is fine. > > Jordi did a panel a year ago at APNIC where he browbeat vendors about > supporting transition mechanisms. The summary is that they said they > have code, they just don't want to ship everything, because it's more to > maintain. > https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/ > > This led to the draft he mentioned upthread, requiring support. OpenWRT > is still the only thing I've seen that wasn't a customer-specific build. DHCPv6 looks perfectly fine for distributing LW4o6/MAP config info. That makes perfect sense as it's essentially part of address/interface configuration just for accessing an alternate protocol. I was referring more to the dearth of broader-range management features on Ubiquiti gear in particular. Get what you pay for, I guess. It slings packets just fine. > Open source software. For stateless transition mechanisms (MAP/LW4o6) it > can be really fast. We have a build I'd be happy to share, if you want. Oh I was certainly planning to use a OSS software platform. I'm sub-Gbps at the moment. I could probably do it on a RasPi. The SNABB lwAFTR option Mikael referred to looks like it would work fine but has some deployment complexities related to its focus on higher performance that are likely not relevant in my present situation, so I'd certainly be interested in other options. -- Brandon Martin From drohan at gmail.com Wed Jan 2 16:07:08 2019 From: drohan at gmail.com (Daniel Rohan) Date: Wed, 2 Jan 2019 08:07:08 -0800 Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> Message-ID: Hey Phil, What use cases are you trying to work on? I work for Kentik on the product side of things and this kind of info is very interesting for me to hear. Happy to take your reply in a DM or here. Dan On Wed, Jan 2, 2019 at 6:01 AM Phil Lavin wrote: > > Doesn't Kentik cost like $2000 a month minimum? > > We recently got a quote from Kentik and I fell off my chair. The annual > cost was slightly more than the total upfront purchase cost of the hardware > they were collecting Flow from and was significantly more than the total > cost each year of running the network (when factoring in power, > cross-connects, transit, etc.). I'm told that collecting Flow and BGP from > two routers which both do < 10Gbit is "~$32K USD per year for Kentik Pro" - > even that feels disproportionally expensive. It does look like an excellent > product though I'm struggling to find a business case that justifies the > cost on relatively small (sub 2 Tbit/s) networks. > -- Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Wed Jan 2 17:14:16 2019 From: alfie at fdx.services (Alfie Pates) Date: Wed, 02 Jan 2019 17:14:16 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> Message-ID: <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> I'm of the opinion that, if you need resiliency, you should order explicitly diverse circuits from a primary provider and then a secondary circuit from a second vendor. Ultimately, If you want contractually-enforced physical diversity then the best options will be single-vendor solutions: Obviously you also want to avoid an unknown single-vendor single-point-of-failure, hence the secondary provider. Having two vendors is usually a less than optimal solution since neither has visibility into the others' network to ensure the physical diversity required for a truly resilient service: what happens if an undersea cable is cut, etc? The cost of such solutions is often unpleasant to justify, mind. ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 2 17:33:43 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 2 Jan 2019 17:33:43 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> References: <1544808340.local-835950ab-296e-v1.5.3-420ce003@getmailspring.com> <805398887.1927.1544870668800.JavaMail.mhammett@ThunderFuck> <95DD374B-9214-45DA-8F81-B0A424C267CD@reservetele.com> <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> All true but it is becoming increasingly difficult to determine if a provider is using another providers infrastructure (all are at some level). For example, in the SIP world there are several national level carriers that are using Level 3s core SIP network and if you were not aware of that you could buy trunks from two of the largest SIP trunk providers in the US and actually be running on the same network. Carriers are also very often reliant on the ILEC for fiber and last mile access. Especially in non-metro areas getting diverse last mile access could be impossible or have huge construction costs. It is pretty complicated to ensure that your carriers are really diverse and much harder to ensure that they stay that way. I have many examples of carrier grooming their own primary and backup circuits onto the same L1 path and not realize they have done so. Contractual diversity is a great idea that does not work since the carriers do not actually know what each other’s network looks like. So let’s say that Sprint and CenturyLink choose the same fiber carrier between areas, do you think they would notify each other of that fact? Do you think the fiber carrier would tell them what another customer’s network looks like? You can tell Sprint to not use CenturyLink but there is no way to get both of them not to use the same third party. I suppose you could contractually tell a carrier to avoid xxx cable but I would have little faith that they maintain that over time. I seriously doubt they review all existing contracts when re-grooming their networks. Steven Naslund Chicago IL >I'm of the opinion that, if you need resiliency, you should order explicitly diverse circuits from a primary provider and then a secondary circuit from a second vendor. > >Ultimately, If you want contractually-enforced physical diversity then the best options will be single-vendor solutions: Obviously you also want to avoid an unknown single-vendor single-point-of-failure, hence the >secondary provider. Having two vendors is usually a less than optimal solution since neither has visibility into the others' network to ensure the physical diversity required for a truly resilient service: what happens if >an undersea cable is cut, etc? > >The cost of such solutions is often unpleasant to justify, mind. > >~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jan 2 17:50:54 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 2 Jan 2019 11:50:54 -0600 (CST) Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> Message-ID: <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> It's easier when you use carriers that provide usable network maps on their web site. Less guess work. When I got a Windstream wave, I got a PDF that was the device CLLI and port number of each device in the path A - Z. Obviously they could change it without informing me of the new path, but I at least know at order it's different and can ask for details when there are outages or latency changes that indicate a change in path. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Steve Naslund" To: nanog at nanog.org Sent: Wednesday, January 2, 2019 11:33:43 AM Subject: RE: How to choose a transport(terrestrial/subsea) All true but it is becoming increasingly difficult to determine if a provider is using another providers infrastructure (all are at some level). For example, in the SIP world there are several national level carriers that are using Level 3s core SIP network and if you were not aware of that you could buy trunks from two of the largest SIP trunk providers in the US and actually be running on the same network. Carriers are also very often reliant on the ILEC for fiber and last mile access. Especially in non-metro areas getting diverse last mile access could be impossible or have huge construction costs. It is pretty complicated to ensure that your carriers are really diverse and much harder to ensure that they stay that way. I have many examples of carrier grooming their own primary and backup circuits onto the same L1 path and not realize they have done so. Contractual diversity is a great idea that does not work since the carriers do not actually know what each other’s network looks like. So let’s say that Sprint and CenturyLink choose the same fiber carrier between areas, do you think they would notify each other of that fact? Do you think the fiber carrier would tell them what another customer’s network looks like? You can tell Sprint to not use CenturyLink but there is no way to get both of them not to use the same third party. I suppose you could contractually tell a carrier to avoid xxx cable but I would have little faith that they maintain that over time. I seriously doubt they review all existing contracts when re-grooming their networks. Steven Naslund Chicago IL > I'm of the opinion that, if you need resiliency, you should order explicitly diverse circuits from a primary provider and then a secondary circuit from a second vendor. > > Ultimately, If you want contractually-enforced physical diversity then the best options will be single-vendor solutions: Obviously you also want to avoid an unknown single-vendor single-point-of-failure, hence the > secondary provider. Having two vendors is usually a less than optimal solution since neither has visibility into the others' network to ensure the physical diversity required for a truly resilient service: what happens if > an undersea cable is cut, etc? > > The cost of such solutions is often unpleasant to justify, mind. > > ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed Jan 2 18:01:50 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 2 Jan 2019 13:01:50 -0500 Subject: CenturyLink RCA? In-Reply-To: References: Message-ID: My best parsing of that ticket, with some guesses : - Infinera management card goes Really Bad, knocks out local waves, and starts spewing garbage out onto the management network - Management network propagates the garbage , other Infinera management cards get it and fall into the same state, knocking down local waves and re-spewing garbage. - Backup tunnels in place to ensure management network connectivity works all the time help propagate the garbage. - They start getting into some devices via OOB, probably rebooting. Devices come up ok, then this garbage traffic knocks them over again. - They start pulling down the backup tunnels to stop the virus from spreading, bouncing stuff again, putting filters on each device to drop the garbage traffic. - This starts to work, but then they hit other problems with linecards from devices that were bounced. - They also start hitting sites that they don't have functional OOB for, and have to get someone driving out to manually get access into. On Sun, Dec 30, 2018 at 8:45 AM Saku Ytti wrote: > Apologies for the URL, I do not know official source and I do not > share the URLs sentiment. > https://fuckingcenturylink.com/ > > Can someone translate this to IP engineer? What did actually happen? > From my own history, I rarely recognise the problem I fixed from > reading the public RCA. I hope CenturyLink will do better. > > Best guess so far that I've heard is > > a) CenturyLink runs global L2 DCN/OOB > b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU, > I've had this failure mode) > c) DCN had direct access to control-plane, and L2 congested > control-plane resources causing it to deprovision waves > > Now of course this is entirely speculation, but intended to show what > type of explanation is acceptable and can be used to fix things. > Hopefully CenturyLink does come out with IP-engineering readable > explanation, so that we may use it as leverage to support work in our > own domains to remove such risks. > > a) do not run L2 DCN/OOB > b) do not connect MGMT ETH (it is unprotected access to control-plane, > it cannot be protected by CoPP/lo0 filter/LPTS ec) > c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP) > d) do fail optical network up > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed Jan 2 20:14:06 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 2 Jan 2019 15:14:06 -0500 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> Message-ID: You can mitigate some of that by getting contract language in place that says a carrier must maintain the circuit on the specified and agreed pathway, and if it's later discovered that it has been moved, you don't pay for the circuit from the time it was moved until it is restored. It's a nice bit of leverage to make sure they *DO* pay attention when they regroom to avoid surprises. :) On Wed, Jan 2, 2019 at 12:53 PM Mike Hammett wrote: > It's easier when you use carriers that provide usable network maps on > their web site. Less guess work. > > When I got a Windstream wave, I got a PDF that was the device CLLI and > port number of each device in the path A - Z. Obviously they could change > it without informing me of the new path, but I at least know at order it's > different and can ask for details when there are outages or latency changes > that indicate a change in path. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Steve Naslund" > *To: *nanog at nanog.org > *Sent: *Wednesday, January 2, 2019 11:33:43 AM > *Subject: *RE: How to choose a transport(terrestrial/subsea) > > All true but it is becoming increasingly difficult to determine if a > provider is using another providers infrastructure (all are at some > level). For example, in the SIP world there are several national level > carriers that are using Level 3s core SIP network and if you were not aware > of that you could buy trunks from two of the largest SIP trunk providers in > the US and actually be running on the same network. Carriers are also very > often reliant on the ILEC for fiber and last mile access. Especially in > non-metro areas getting diverse last mile access could be impossible or > have huge construction costs. It is pretty complicated to ensure that your > carriers are really diverse and much harder to ensure that they stay that > way. I have many examples of carrier grooming their own primary and backup > circuits onto the same L1 path and not realize they have done so. > > > > Contractual diversity is a great idea that does not work since the > carriers do not actually know what each other’s network looks like. So > let’s say that Sprint and CenturyLink choose the same fiber carrier between > areas, do you think they would notify each other of that fact? Do you > think the fiber carrier would tell them what another customer’s network > looks like? You can tell Sprint to not use CenturyLink but there is no way > to get both of them not to use the same third party. I suppose you could > contractually tell a carrier to avoid xxx cable but I would have little > faith that they maintain that over time. I seriously doubt they review all > existing contracts when re-grooming their networks. > > > > Steven Naslund > > Chicago IL > > > > > > >I'm of the opinion that, if you need resiliency, you should order > explicitly diverse circuits from a primary provider and then a secondary > circuit from a second vendor. > > > > > >Ultimately, If you want contractually-enforced physical diversity then > the best options will be single-vendor solutions: Obviously you also want > to avoid an unknown single-vendor single-point-of-failure, hence the >secondary > provider. Having two vendors is usually a less than optimal solution since > neither has visibility into the others' network to ensure the physical > diversity required for a truly resilient service: what happens if >an > undersea cable is cut, etc? > > > > > >The cost of such solutions is often unpleasant to justify, mind. > > > > > >~a > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Wed Jan 2 20:43:55 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 2 Jan 2019 22:43:55 +0200 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, 2 Jan 2019 at 22:17, Tom Beecher wrote: > You can mitigate some of that by getting contract language in place that says a carrier must maintain the circuit on the specified and agreed pathway, and if it's later discovered that it has been moved, you don't pay for the circuit from the time it was moved until it is restored. > > It's a nice bit of leverage to make sure they *DO* pay attention when they regroom to avoid surprises. :) Who is selling this product? I know SLA compensations on service disruptions is a thing, but there the downside seller is carrying is limited to MRC, that is seller gets higher margin on SLA products than nonSLA, when when outages are factored in. I don't see the business case for the seller in contractual terms you are proposing. The amendment has to make more money for the seller, otherwise there is no point for them to sell it, unless of course the product is unmarketable without the amendment. I would anticipate if this product is available the seller limits downside in the contracts in such way that it will always be profitable to the seller to sell the insurance to you. -- ++ytti From SNaslund at medline.com Wed Jan 2 21:48:16 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 2 Jan 2019 21:48:16 +0000 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED58E2@WAUPRDMBXP1.medline.com> This was a product available from the earliest Bell System days. You could specify a couple of options. One is local path redundancy or diversity - intended to get you to another central office and not use the same cable as another specified circuit. A second option is called avoidance where you could tell the phone company to avoid a certain area. AT&T would let you order a SONET node which guaranteed two different entrances for fiber ring going through at least two different COs, expensive and you pay the install or agree to megalong contract terms for a minimum number of access circuits. As an example, the US Government ordered command and control circuits and explicitly had them avoid major metro areas (that were likely nuclear targets). The deal in practice though is that these options were rarely ordered since whoever orders it pays all the initial construction costs. If you building wants a connection to other than your home CO, you have to pay for all of the plant construction to reach a point where you could catch a cable going that way. As to who is selling it? Almost anyone if you pay for that level of custom engineering. More importantly, can you verify it? The US Government had a deal with AT&T to show them the entire AT&T backhaul network architecture. Not many customers get that level of access. If anything they are going to show you the "lines between cities" type map that we all know has little to do with reality on the ground. Steven Naslund Chicago IL >Who is selling this product? I know SLA compensations on service disruptions is a thing, but there the downside seller is carrying is limited to MRC, that is seller gets higher margin on SLA products than nonSLA, when when outages >are factored in. I don't see the business case for the seller in contractual terms you are proposing. The amendment has to make more money for the seller, otherwise there is no point for them to sell it, unless of course the product >is unmarketable without the amendment. >I would anticipate if this product is available the seller limits downside in the contracts in such way that it will always be profitable to the seller to sell the insurance to you. > >-- > ++ytti From jbothe at me.com Wed Jan 2 22:04:34 2019 From: jbothe at me.com (Jason Bothe) Date: Wed, 2 Jan 2019 16:04:34 -0600 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> Message-ID: Correct. Its called a grooming clause and you can most certainly ensure you have language in your agreements with the vendor. Restrictions being it needs to be for wavelength or an IRU path which is custom anyhow. Also, KMZs or no business. Period. J~ > On 2, Jan 2019, at 2:14 PM, Tom Beecher wrote: > > You can mitigate some of that by getting contract language in place that says a carrier must maintain the circuit on the specified and agreed pathway, and if it's later discovered that it has been moved, you don't pay for the circuit from the time it was moved until it is restored. > > It's a nice bit of leverage to make sure they *DO* pay attention when they regroom to avoid surprises. :) > > On Wed, Jan 2, 2019 at 12:53 PM Mike Hammett > wrote: > It's easier when you use carriers that provide usable network maps on their web site. Less guess work. > > When I got a Windstream wave, I got a PDF that was the device CLLI and port number of each device in the path A - Z. Obviously they could change it without informing me of the new path, but I at least know at order it's different and can ask for details when there are outages or latency changes that indicate a change in path. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From: "Steve Naslund" > > To: nanog at nanog.org > Sent: Wednesday, January 2, 2019 11:33:43 AM > Subject: RE: How to choose a transport(terrestrial/subsea) > > All true but it is becoming increasingly difficult to determine if a provider is using another providers infrastructure (all are at some level). For example, in the SIP world there are several national level carriers that are using Level 3s core SIP network and if you were not aware of that you could buy trunks from two of the largest SIP trunk providers in the US and actually be running on the same network. Carriers are also very often reliant on the ILEC for fiber and last mile access. Especially in non-metro areas getting diverse last mile access could be impossible or have huge construction costs. It is pretty complicated to ensure that your carriers are really diverse and much harder to ensure that they stay that way. I have many examples of carrier grooming their own primary and backup circuits onto the same L1 path and not realize they have done so. > > > Contractual diversity is a great idea that does not work since the carriers do not actually know what each other’s network looks like. So let’s say that Sprint and CenturyLink choose the same fiber carrier between areas, do you think they would notify each other of that fact? Do you think the fiber carrier would tell them what another customer’s network looks like? You can tell Sprint to not use CenturyLink but there is no way to get both of them not to use the same third party. I suppose you could contractually tell a carrier to avoid xxx cable but I would have little faith that they maintain that over time. I seriously doubt they review all existing contracts when re-grooming their networks. > > > Steven Naslund > > Chicago IL > > > > >I'm of the opinion that, if you need resiliency, you should order explicitly diverse circuits from a primary provider and then a secondary circuit from a second vendor. > > > > > >Ultimately, If you want contractually-enforced physical diversity then the best options will be single-vendor solutions: Obviously you also want to avoid an unknown single-vendor single-point-of-failure, hence the >secondary provider. Having two vendors is usually a less than optimal solution since neither has visibility into the others' network to ensure the physical diversity required for a truly resilient service: what happens if >an undersea cable is cut, etc? > > > > > >The cost of such solutions is often unpleasant to justify, mind. > > > > > >~a > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlewis at techcompute.net Tue Jan 1 00:50:22 2019 From: mlewis at techcompute.net (Mitchell Lewis) Date: Tue, 1 Jan 2019 00:50:22 +0000 Subject: Cleveland/Cincinnati Co-location Message-ID: Good Evening All, I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. Thanks & Regards, Mitchell Lewis 203-816-0371 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mankamis at cisco.com Wed Jan 2 05:47:53 2019 From: mankamis at cisco.com (Mankamana Mishra (mankamis)) Date: Wed, 2 Jan 2019 05:47:53 +0000 Subject: does emergency (911) dispatch uses IP ? Message-ID: Guys, While reading CL network down impacting 911 services, was trying to get more information about how does this network looks like. From end user to center, I guess VOIP is used. Wondering what is the communication method from Emergency service center to end units (Police, Fire or any other services). Do they also use IP ? or its Still Radio only ? if it is IP, do they use Unicast or multicast or broadcast ? Tried googling, but did not get much information. Any insight would be appreciated. Thanks Mankamana -------------- next part -------------- An HTML attachment was scrubbed... URL: From hibaysal at gmail.com Wed Jan 2 14:05:12 2019 From: hibaysal at gmail.com (H I Baysal) Date: Wed, 2 Jan 2019 15:05:12 +0100 Subject: Service Provider NetFlow Collectors In-Reply-To: References: <11d7fab8-a769-ea23-3963-a5b3d4a641af@emj.se> <4341cffb-bca2-3145-70a5-e9735c2e9c57@shout.net> <752815D4-DD2F-4E37-85ED-F91E04D8DC27@corp.crocker.com> <20190101045603.F1F27F628@freedman.net> <0053ac6a-fb96-ec3c-42d9-4595785b30ea@gmail.com> <9da01caa-62fc-b27a-efdc-b2c67e0e97ef@gmail.com> Message-ID: <6af19b80-b521-bf20-075d-ea09d812eaa0@gmail.com> Hi Saku, aggregate [DSTAS]: label, dst_as, peer_dst_as, out_iface aggregate [SRCAS]: label, src_as, peer_src_as, in_iface aggregate[IP]: label, dst_as, src_host, out_iface, in_iface And a script goes over this output to relate ifindex to ifalias from also influxdb SNMP counter DB (where the ifalias is stored) ( script has to be smart to know which port flows to store, as in edge ports for hosters for example cause you wouldnt want ibgp flow info in your DST AS database) I'm attaching only the graph for IP aggregate series. And Cpu never goes above 30%. As i said, per IP, per iface, per dst As information stored, cant get more pretties and betetr than this for a capacity manager :D And if you add another tag adding a price per mbit to a carrier/port, you can find out how much a single customer is costing you for network usage based on per IP aggregation !!!!!!!!!!!!!!!!!!!! You have to be "smart" with duration of your retention policy and continuous queries though :D (again, Thanks Paulo for PMACCT!!! ) ( and as an addition, we have a telegram bot you send a message to like "/dst as#", and this pulls the graph from grafana, renders it and sends it to telegram chat :D I worked at a few Hosting companies, and I haven't seen anything like this :D ) The idea is to put this whole thing on github but i need to make time for that... And "aint nobody got time for that" :P On 02-01-19 13:59, Saku Ytti wrote: > Hey, > > > On Wed, 2 Jan 2019 at 14:40, H I Baysal wrote: > >> That absolutely depends on the amount of TAGs you use, and how you aggregate, etc. >> I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even sweating a single drop.... >> >> We have a 4 Tbps of traffic during peak, and as well as pmacct and influxdb or running very very smooth. > How many series do you have in the DB? > > Your explanation makes it unclear to me what labels you have 'per IP' > is ambiguous to me. If only DST_IP is tag and you have low amount of > IPs in or behind your network, it seems very feasible indeed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at telcodata.us Wed Jan 2 22:11:55 2019 From: paul at telcodata.us (Paul Timmins) Date: Wed, 2 Jan 2019 17:11:55 -0500 Subject: Cleveland/Cincinnati Co-location In-Reply-To: References: Message-ID: <5BBC0EDE-EBB0-4279-B65D-2B09197E9D06@telcodata.us> Everstream has a pretty vast network in Ohio. Worth looking into. > On Dec 31, 2018, at 7:50 PM, Mitchell Lewis wrote: > > Good Evening All, > I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. > > I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. > > Thanks & Regards, > Mitchell Lewis > 203-816-0371 -------------- next part -------------- An HTML attachment was scrubbed... URL: From merculiani at gmail.com Wed Jan 2 22:18:32 2019 From: merculiani at gmail.com (Matt Erculiani) Date: Wed, 2 Jan 2019 16:18:32 -0600 Subject: Cleveland/Cincinnati Co-location In-Reply-To: <5BBC0EDE-EBB0-4279-B65D-2B09197E9D06@telcodata.us> References: <5BBC0EDE-EBB0-4279-B65D-2B09197E9D06@telcodata.us> Message-ID: DRS/Involta is a big one up there, but I'm not sure if they do plain-old colo. -Mayt On Wed, Jan 2, 2019, 16:14 Paul Timmins Everstream has a pretty vast network in Ohio. Worth looking into. > > On Dec 31, 2018, at 7:50 PM, Mitchell Lewis > wrote: > > Good Evening All, > I am working on project that may involve building points of presence in Cleveland > & Cincinnati. Any suggestions as to which colocation facility in each > city to build in? The prime factor of consideration for this project is > access to waves to places like Chicago, New York & Ashburn. It would be > nice to have multiple wave provider options to choose from. > > I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in > Cleveland. > > Thanks & Regards, > *Mitchell Lewis* > 203-816-0371 <+12038160371> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 2 22:30:05 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 2 Jan 2019 22:30:05 +0000 Subject: does emergency (911) dispatch uses IP ? In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED5965@WAUPRDMBXP1.medline.com> So, to explain the whole system….. 1. From your location to the your serving CO would be IP, POTS, Cellular however your normal phone call route. 2. From your CO to the CO(s) serving your 911 center. Might be a dedicated trunk or may have high priority to seize channels within the normal trunking between COs. The transport being TDM or VOIP is up to the local carrier to decide. 3. From the 911 center to the to the responders can vary by area and size. Major metros can route to dispatch centers that handle police fire and other services and they can usually communicate over a dedicated trunked radio system through the area they cover to directly communicate with responders and command elements. For a small town volunteer department the call might go to a county level dispatcher who pages out the responders. It might even be ringing a single phone at the local PD. It is up to each municipality to determine how they want the calls routed and the phone company assigns each number they assigned to a 911 center based on your street address. There is a global table (used to be maintained by Bellcore, then Telcordia, I’m not sure now) that shows ranges of street addresses mapped to the correct 911 center that is used to populate the phone system. 4. Large Metros and advanced 911 centers send voice and packet/cellular radio to responding units often giving them maps, aerial views, known hazmat on site, and other data. If you have a large enterprise you can buy systems that allow you to communicate data like this from your organization to the 911 center. My company has a data link that sends mapping data, entrance information, and even has our security people meet the responders at the door every time 911 is called. The wrong questions is IP or radio only, they are not mutually exclusive anymore. A lot of these systems today are cellular data transmission or packet over radio. Big county wide systems are often hybrids of both. They can have their own radios covering major population density and use cellular data to fill in the shadows in their coverage. The radio user just sees the device as a walkie talkie and all that switching is transparent to them. Steven Naslund Chicago IL >Guys, >While reading CL network down impacting 911 services, was trying to get more information about how does this network looks like. From end user to center, I guess VOIP is used. Wondering what is the communication method >from Emergency service center to end units (Police, Fire or any other services). Do they also use IP ? or its Still Radio only ? if it is IP, do they use Unicast or multicast or broadcast ? > >Tried googling, but did not get much information. Any insight would be appreciated. > >Thanks >Mankamana -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Wed Jan 2 22:36:14 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 2 Jan 2019 17:36:14 -0500 (EST) Subject: does emergency (911) dispatch uses IP ? In-Reply-To: References: Message-ID: Yes. Look for NENA (National Emergency Number Association). 20+ years ago, 911 routing required telco connections in each LATA. Some legacy (e.g. copper) still uses LATA-based 911 routing, but a lot of 911 routing (i.e. cell, voip, next-gen voice, etc) has been consolidated to a few service providers' data centers connected via IP. NextGeneration 911 will be essentially 100% IP. Cost, efficiency, etc. On Wed, 2 Jan 2019, Mankamana Mishra (mankamis) via NANOG wrote: > While reading CL network down impacting 911 services, was trying to get more > information about how does this network looks like. From end user to center, > I guess VOIP is used. Wondering what is the communication method from > Emergency service center to end units (Police, Fire or any other services). > Do they also use IP ? or its Still Radio only ? if it is IP, do they use > Unicast or multicast or broadcast ? > > > Tried googling, but did not get much information. Any insight would be > appreciated. From SNaslund at medline.com Wed Jan 2 22:41:41 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 2 Jan 2019 22:41:41 +0000 Subject: does emergency (911) dispatch uses IP ? In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED5992@WAUPRDMBXP1.medline.com> There are multiple ways this outage can impact CL 911 service not just related to IP. Here are a few of them: 1. You have a POTS line and you dial 911 which gets to your central office but the CO switch had no trunks out, either because they were TDM but riding one of the optical carriers or IP based. Both go down when the optical mux chokes. 2. 911 center is probably connected to multiple COs (usually at least two) but since this outage was nationwide it is very likely that adjacent COs could have lost transmission trunks isolating the 911 center. 3. If you are a cellular customer, that data is getting backhauled to a central office and then getting inserted into the same CO switches that lost their transmission capacity. It is important to remember that a lot of stuff is using IP for transport but the IP network is also controlling the L1 infrastructure. In this case it looks like the IP network transmitted bad control data to the underlying fiber network. Steven Naslund Chicago IL >Guys, >While reading CL network down impacting 911 services, was trying to get more information about how does this network looks like. From end user to center, I guess VOIP is used. Wondering what is the communication method >from Emergency service center to end units (Police, Fire or any other services). Do they also use IP ? or its Still Radio only ? if it is IP, do they use Unicast or multicast or broadcast ? > >Tried googling, but did not get much information. Any insight would be appreciated. > >Thanks >Mankamana -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 2 22:56:25 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 2 Jan 2019 22:56:25 +0000 Subject: does emergency (911) dispatch uses IP ? In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40318ED59B6@WAUPRDMBXP1.medline.com> That's right. Check out www.west.com So, your town will hire someone to put the systems in the 911 center and that might be a company like West or say you are a local network provider doing VOIP you could hire west to put in a gateway for you. State and local governments can hire them to maintain the databases behind all of this. You dump all of your 911 calls to their gateway (which also has access to your customer address data) and they will handle all of the routing out of their centers for you. They also provide recording keeping an recording services if you want. Often the first choice from your site to West's datacenters is VOIP over Internet, they often then have backup landline routes and any other kind of redundancy you want to pay for. Putting in multiple datacenters and having multiple Internet feeds you can easily outperform the reliability of the traditional POTS infrastructure. This industry really took off when the CLEC/wireless industry launched to avoid creating a bunch of duplicative expensive infrastructure to meet the public safety regulations. Better to have a few giants like West take on the liability and build a nice infrastructure anyone can use than to roll you own and have to keep up with the changing technology. This kind of technology also allows smaller municipalities to get better more advanced systems by purchasing them as a service rather than a one time monster budget hit that traditional 911 centers used to be. One more great thing about doing this is that the network becomes much more flexible and calls can be routed around failed centers or center that may themselves be in the middle of a disaster. Disclaimer: I don't make anything from West just know of their services and roll in the industry. There are others that might be as good or better. Steven Naslund >Yes. > >Look for NENA (National Emergency Number Association). > >20+ years ago, 911 routing required telco connections in each LATA. Some >legacy (e.g. copper) still uses LATA-based 911 routing, but a lot of 911 routing (i.e. cell, voip, next-gen voice, etc) has been consolidated to a few service providers' data centers connected via IP. > >NextGeneration 911 will be essentially 100% IP. > >Cost, efficiency, etc. From jeff+nanog at waddellsolutions.com Thu Jan 3 01:18:48 2019 From: jeff+nanog at waddellsolutions.com (Jeff Waddell) Date: Wed, 2 Jan 2019 20:18:48 -0500 Subject: Cleveland/Cincinnati Co-location In-Reply-To: References: <5BBC0EDE-EBB0-4279-B65D-2B09197E9D06@telcodata.us> Message-ID: CyrusOne and Immedion are the only 2 datacenters in Cincinnati that have a decent spread of what little connectivity Cincinnati has going through it. Immedion is down on 3rd street Reach out off list if you have questions or want an intro. On Wed, Jan 2, 2019 at 5:20 PM Matt Erculiani wrote: > DRS/Involta is a big one up there, but I'm not sure if they do plain-old > colo. > > -Mayt > > On Wed, Jan 2, 2019, 16:14 Paul Timmins >> Everstream has a pretty vast network in Ohio. Worth looking into. >> >> On Dec 31, 2018, at 7:50 PM, Mitchell Lewis >> wrote: >> >> Good Evening All, >> I am working on project that may involve building points of presence in Cleveland >> & Cincinnati. Any suggestions as to which colocation facility in each >> city to build in? The prime factor of consideration for this project is >> access to waves to places like Chicago, New York & Ashburn. It would be >> nice to have multiple wave provider options to choose from. >> >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in >> Cleveland. >> >> Thanks & Regards, >> *Mitchell Lewis* >> 203-816-0371 <+12038160371> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From npeelman at ETC1.net Thu Jan 3 03:37:59 2019 From: npeelman at ETC1.net (Nick Peelman) Date: Thu, 3 Jan 2019 03:37:59 +0000 Subject: Service Provider NetFlow Collectors In-Reply-To: <2066108599.2244.1546274442993.JavaMail.mhammett@ThunderFuck> References: <2066108599.2244.1546274442993.JavaMail.mhammett@ThunderFuck> Message-ID: <0C6662D2-2116-4CC2-B57E-7E01332A5045@etc1.net> We rolled a large(ish) ElasticSearch cluster last year out of SuperMicro Microclouds (3U, 8 nodes per chassis, Xeon-D based processors), mostly 32GB of RAM per node, and M.2 PCIe SSDs as well as HDD storage. ES is a finicky beast to maintain. It can handle a node completely dying or disappearing from the network, but not when one runs out of space (at least not gracefully). Maintaining retention and rotation is tedious at best (yay curator). We’re dumping a boatload of log data there, as well as Flow data using Elastiflow, which provides the necessary collector bits as well as all the pretty Kibana graphs and stuff. Probably overbuilt, but I can pretty much keep whatever logs we want in perpetuity, we have plenty of headroom, and searching is incredibly fast. ELK is an awesome set of tools, but be warned, there be dragons. Admin’ing even a small cluster can be time consuming and frustrating, and requires a pretty stout linux and server background, or at least some really good troubleshooting skills and an ability to turn to the code when the docs fall short. Doing a larger cluster could easily be a full time job. Still, all in all, I’m happy with the cost of ours, including my time building it and continued time maintaining it, compared to what the yearly outlay was going to be for Kentik. -nick On 31 Dec 2018, at 11:40, Mike Hammett > wrote: I just recently rolled out Elastiflow. Lots of great information. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Michel 'ic' Luczak" > To: "Erik Sundberg" > Cc: nanog at nanog.org Sent: Monday, December 31, 2018 3:40:40 AM Subject: Re: Service Provider NetFlow Collectors Don’t underestimate good old ELK https://www.elastic.co/guide/en/logstash/current/netflow-module.html + https://github.com/robcowart/elastiflow BR, ic On 31 Dec 2018, at 04:29, Erik Sundberg > wrote: Hi Nanog…. We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. We are looking at ManageEngine Netflow Analyzer PRTG Plixer – Scrutinizer PeakFlow Kentik Solarwinds NTA Thanks in advance… Erik ________________________________ 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. From streinerj at gmail.com Thu Jan 3 06:00:24 2019 From: streinerj at gmail.com (Justin M. Streiner) Date: Thu, 3 Jan 2019 01:00:24 -0500 (EST) Subject: Cleveland/Cincinnati Co-location In-Reply-To: References: Message-ID: On Tue, 1 Jan 2019, Mitchell Lewis wrote: > I am working on project that may involve building points of presence in > Cleveland & Cincinnati. Any suggestions as to which colocation facility > in each city to build in? The prime factor of consideration for this > project is access to waves to places like Chicago, New York & Ashburn. > It would be nice to have multiple wave provider options to choose from. > > I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in > Cleveland. Expedient has two facilities in Cleveland that might be worth looking at. Thank you jms From allenmckinleykitchen at gmail.com Thu Jan 3 15:50:45 2019 From: allenmckinleykitchen at gmail.com (Allen McKinley Kitchen (gmail)) Date: Thu, 3 Jan 2019 10:50:45 -0500 Subject: Cleveland/Cincinnati Co-location In-Reply-To: References: Message-ID: <91679AF9-E310-463C-B427-630F69C02222@gmail.com> +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) ..Allen > On Jan 3, 2019, at 01:00, Justin M. Streiner wrote: > >> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >> >> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >> >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. > > Expedient has two facilities in Cleveland that might be worth looking at. > > Thank you > jms From aaron_ppus at fmad.com Thu Jan 3 01:40:44 2019 From: aaron_ppus at fmad.com (Aaron) Date: Thu, 3 Jan 2019 10:40:44 +0900 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: Throwing my hat in the ring also (vendor from fmadio) https://github.com/fmadio/pcap2json Not exactly a newflow collector, its pcap -> flowgen -> elk on a single box, working very well so far, still work in progress. Problem with logstash is its too slow for high flow rates. So we did everything inside the flow generator for direct ELK bulk uploads removing logstash completely. Cheers Aaron On Mon, 31 Dec 2018 at 18:40, Michel 'ic' Luczak wrote: > Don’t underestimate good old ELK > https://www.elastic.co/guide/en/logstash/current/netflow-module.html > + https://github.com/robcowart/elastiflow > > BR, ic > > On 31 Dec 2018, at 04:29, Erik Sundberg wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what other > service providers are using to collect netflow data off their Core and Edge > Routers. Pros/Cons… What to watch out for any info would help. > > We are mainly looking to analyze the netflow data. Bonus if it does ddos > detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer – Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance… > > Erik > > > ------------------------------ > > 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at shawnritchie.com Thu Jan 3 17:21:32 2019 From: me at shawnritchie.com (Shawn Ritchie) Date: Thu, 3 Jan 2019 11:21:32 -0600 Subject: Cleveland/Cincinnati Co-location In-Reply-To: <91679AF9-E310-463C-B427-630F69C02222@gmail.com> References: <91679AF9-E310-463C-B427-630F69C02222@gmail.com> Message-ID: <19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1@fastmail.fm> On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) wrote: > > +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) > > ..Allen > >> On Jan 3, 2019, at 01:00, Justin M. Streiner wrote: >> >>> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >>> >>> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >>> >>> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. >> >> Expedient has two facilities in Cleveland that might be worth looking at. >> >> Thank you >> jms I’m in Expedient’s Cleveland DC and will second that they’re decent. — Shawn From andy at nosignal.org Thu Jan 3 20:08:46 2019 From: andy at nosignal.org (Andy Davidson) Date: Thu, 3 Jan 2019 20:08:46 +0000 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> Hi, Dominic -- On 20/12/2018, 17:49, Dominic Schallert wrote: > this might be a stupid question but today I was discussing with a colleague if > Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. > My standpoint is that in any case, Peering-LAN prefixes should be filtered and not > announced to peers/customers because a Peering-LAN represents some sort of > DMZ and there is simply no need for them to be reachable by third-parties not being > physically connected to an IXP themselves. There are no stupid questions! It is a good idea to not BGP announce and perhaps also to drop traffic toward peering LAN prefixes at customer-borders, this was already well discussed in the thread. But there wasn’t a discussion on how we got to this point. Until the Cloudflare 2013 BGP speaker attack, that sought to flood Cloudflare’s transfer networks and exchange connectivity (and with it saturating IXP inter-switch links and IXP participant ports), it was common for IXP IPv4/6 peering LANs to be internet reachable and BGP transited. This facilitated troubleshooting (e.g. traceroutes showing peering lan interfaces in traceroutes instead of ‘starring out’) and PMTUD (e.g. see recommendation in https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html which actually asked for IXP peering LANs to be announced). There are good reasons to announce but there are better reasons to filter. The security benefits of filtering outweigh the upsides on today’s internet, but fashions and best practice may further evolve over time. Andy -- Andy Davidson Director, Asteroid International BV www.asteroidhq.com Director, Euro-IX - The European Internet Exchange Association www.euro-ix.net From csyoo at law.upenn.edu Thu Jan 3 20:51:56 2019 From: csyoo at law.upenn.edu (Christopher S. Yoo) Date: Thu, 3 Jan 2019 20:51:56 +0000 Subject: Report on Legal Barriers to RPKI Adoption In-Reply-To: References: Message-ID: As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo at law.upenn.edu http://www.law.upenn.edu/faculty/csyoo/ For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/. -------------- next part -------------- An HTML attachment was scrubbed... URL: From db at rrbone.net Thu Jan 3 22:01:56 2019 From: db at rrbone.net (Dominik Bay) Date: Thu, 3 Jan 2019 22:01:56 +0000 Subject: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 originated by 4812 209 286 3320 5400 5511 6327 6461 6762 6830 8218 8220 8447 8551 9002 12956 The proper source is 32982 (Department of Energy). More details to be found here: https://bgpstream.com/event/171779 And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 Cheers, Dominik From jeffshultz at sctcweb.com Thu Jan 3 22:37:28 2019 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Thu, 3 Jan 2019 14:37:28 -0800 Subject: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 In-Reply-To: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> References: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> Message-ID: China Telecom originating a network that belongs to the agency that controls all things nuclear in the US... nothing suspicious there. On Thu, Jan 3, 2019 at 2:03 PM Dominik Bay wrote: > > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779 > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 > > Cheers, > Dominik > > -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ From sean at donelan.com Thu Jan 3 22:45:00 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 3 Jan 2019 17:45:00 -0500 (EST) Subject: Astronaut accidently calls 911 from space Message-ID: I was disappointed that it was just a misdial. I was looking forward to how IP geolocation worked with 9-1-1 calls from space. I always wondered how that altitude parameter in 911 packets was used. :-) https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892 From dovid at telecurve.com Thu Jan 3 23:46:08 2019 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 3 Jan 2019 18:46:08 -0500 Subject: Cellular backup connections In-Reply-To: References: Message-ID: All, Thanks for all of the feedback. I was on site today and noticed two things. 1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this. 2) I was watching the ping times and it looked something like this: 400ms 360ms 330ms 300ms 260ms 210ms 170ms 140ms 120ms 400ms 375ms It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes. On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan wrote: > On Fri, 28 Dec 2018, Dovid Bender wrote: > > >I finally got around to setting up a cellular backup device in our new > POP. > > >When SSH'ing in remotely the connection seems rather slow. > > Perhaps using MOSH can help make the interactive CLI session less > annoying. > > >Verizon they charge $500.00 just to get a public IP and I want to avoid > >that if possible. > > You might look into have it call out / maintain a connection back to > your infrastructure. > > > /mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Fri Jan 4 08:21:32 2019 From: job at ntt.net (Job Snijders) Date: Fri, 4 Jan 2019 11:21:32 +0300 Subject: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 In-Reply-To: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> References: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> Message-ID: Dear all, NTT / AS 2914 deployed explicit filters to block this BGP announcement from AS 4134. I recommend other operators to do the same. I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the /24 announcement so the counter measure is more effective. Kind regards, Job On Fri, Jan 4, 2019 at 1:02 Dominik Bay wrote: > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 > originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779 > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 > > Cheers, > Dominik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.z.edwards at gmail.com Fri Jan 4 14:36:42 2019 From: nick.z.edwards at gmail.com (Nick Edwards) Date: Sat, 5 Jan 2019 00:36:42 +1000 Subject: IP Dslams In-Reply-To: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> References: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> Message-ID: They don't have a large budget and although I'm yet to get prices on adtran's (understandable, holidays 'n all) I doubt it will fit within their budget, it's looking more like getting a few planet dslams and configuring a linux box as the bng, been 10 years since I've had to do that kind of setup, memories hazy, but I know it worked, and well, so thanks to all for suggestions but the adtrans and nokias are not for those on shoe string budgets, which wouldnt even allow me to include an asr1k for the bng, and although it would allow for, I'd rather not grab an ebay 7200/7300 :) On Wed, Jan 2, 2019 at 10:52 PM Brandon Martin wrote: > On 1/2/19 6:47 AM, Nick Edwards wrote: > > There are 260 villas, and no coax. > > Is there a logical way to distribute the termination? You might be able > to get better performance (not that you perhaps care, in this case) at > minimal additional cost if you can do building-local termination of each > customer circuit and then backhaul on e.g. bonded VDSL2 or G.FAST over > shorter distances (perhaps hopping building to building). > > I'm assuming there's no data grade copper or fiber if there's no coax. > Obviously if you've got those, distributed termination makes even more > sense. > > If you do want a centralized solution, an Adtran TA5006 (the small > chassis) with 6x 48 port VDSL2 combo modules (with or without vectoring, > depending on your needs) would do the job (though it fills the chassis > and doesn't allow for expansion, so the full-size TA5000 may be > desirable). I've played (and am playing with) the same system but with > GPON termination and have been happy with it so far. > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawnl at up.net Fri Jan 4 14:59:04 2019 From: shawnl at up.net (Shawn L) Date: Fri, 4 Jan 2019 09:59:04 -0500 (EST) Subject: IP Dslams In-Reply-To: References: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> Message-ID: <1546613944.7588969@upnet.mymailsrvr.com> Might want to look for old Zhone ip bitstorm dslams. There should be a bunch on the used market. They do all of the ATM conversions internally so you just need to feed them with ethernet. -----Original Message----- From: "Nick Edwards" Sent: Friday, January 4, 2019 9:36am To: "Brandon Martin" Cc: "NANOG" Subject: Re: IP Dslams They don't have a large budget and although I'm yet to get prices on adtran's (understandable, holidays 'n all) I doubt it will fit within their budget, it's looking more like getting a few planet dslams and configuring a linux box as the bng, been 10 years since I've had to do that kind of setup, memories hazy, but I know it worked, and well, so thanks to all for suggestions but the adtrans and nokias are not for those on shoe string budgets, which wouldnt even allow me to include an asr1k for the bng, and although it would allow for, I'd rather not grab an ebay 7200/7300 :) On Wed, Jan 2, 2019 at 10:52 PM Brandon Martin <[ lists.nanog at monmotha.net ]( mailto:lists.nanog at monmotha.net )> wrote:On 1/2/19 6:47 AM, Nick Edwards wrote: > There are 260 villas, and no coax. Is there a logical way to distribute the termination? You might be able to get better performance (not that you perhaps care, in this case) at minimal additional cost if you can do building-local termination of each customer circuit and then backhaul on e.g. bonded VDSL2 or G.FAST over shorter distances (perhaps hopping building to building). I'm assuming there's no data grade copper or fiber if there's no coax. Obviously if you've got those, distributed termination makes even more sense. If you do want a centralized solution, an Adtran TA5006 (the small chassis) with 6x 48 port VDSL2 combo modules (with or without vectoring, depending on your needs) would do the job (though it fills the chassis and doesn't allow for expansion, so the full-size TA5000 may be desirable). I've played (and am playing with) the same system but with GPON termination and have been happy with it so far. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffshultz at sctcweb.com Fri Jan 4 15:06:06 2019 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Fri, 4 Jan 2019 07:06:06 -0800 Subject: IP Dslams In-Reply-To: References: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> Message-ID: You might start hunting on the used market for Occam/Calix B6 equipment, specifically the B6-252 ADSL2+ and POTS card and the 12 slot chassis. You'll have to put in some supporting infrastructure, but they do work well, and I know of at least two aftermarket repair places that will repair them for a reasonable (for the telecom world) cost. On Fri, Jan 4, 2019, 06:38 Nick Edwards They don't have a large budget and although I'm yet to get prices on > adtran's (understandable, holidays 'n all) I doubt it will fit within their > budget, it's looking more like getting a few planet dslams and configuring > a linux box as the bng, been 10 years since I've had to do that kind of > setup, memories hazy, but I know it worked, and well, so thanks to all for > suggestions but the adtrans and nokias are not for those on shoe string > budgets, which wouldnt even allow me to include an asr1k for the bng, and > although it would allow for, I'd rather not grab an ebay 7200/7300 :) > > On Wed, Jan 2, 2019 at 10:52 PM Brandon Martin > wrote: > >> On 1/2/19 6:47 AM, Nick Edwards wrote: >> > There are 260 villas, and no coax. >> >> Is there a logical way to distribute the termination? You might be able >> to get better performance (not that you perhaps care, in this case) at >> minimal additional cost if you can do building-local termination of each >> customer circuit and then backhaul on e.g. bonded VDSL2 or G.FAST over >> shorter distances (perhaps hopping building to building). >> >> I'm assuming there's no data grade copper or fiber if there's no coax. >> Obviously if you've got those, distributed termination makes even more >> sense. >> >> If you do want a centralized solution, an Adtran TA5006 (the small >> chassis) with 6x 48 port VDSL2 combo modules (with or without vectoring, >> depending on your needs) would do the job (though it fills the chassis >> and doesn't allow for expansion, so the full-size TA5000 may be >> desirable). I've played (and am playing with) the same system but with >> GPON termination and have been happy with it so far. >> -- >> Brandon Martin >> > -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Jan 4 15:47:30 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 4 Jan 2019 16:47:30 +0100 (CET) Subject: IP Dslams In-Reply-To: References: Message-ID: On Sat, 29 Dec 2018, Nick Edwards wrote: > Howdy, > We have a requirement for an aged care facility to provide voice and data, > we have the voice worked out, but data, WiFi is out of the question, so are > looking for IP-Dslams, preferably a system that is all-in-one, or self > contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has > a property managment API, or even just a webpage manager where admin can Are you sure you need all of that? When I designed ADSL solutions ~15 years ago I built with Paradyne DSLAM with ethernet uplink, then we used rfc 1483 bridged over ATM, so no need for PPP, radius or anything. It was just IPoETHERNEToATM and all the regular IPoE mechanisms could be used (DHCP etc). So we just bundled the DSLAM with an L3 switch and that was that. One vlan per customer which solved the customer isolation problem. Customer could run modem in either bridged mode or terminate the IPoETHoATM PVC on the RG itself. -- Mikael Abrahamsson email: swmike at swm.pp.se From db at rrbone.net Fri Jan 4 16:03:22 2019 From: db at rrbone.net (Dominik Bay) Date: Fri, 4 Jan 2019 17:03:22 +0100 Subject: (FIXED) Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 In-Reply-To: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> References: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net> Message-ID: <75142d5f-7e90-7f7b-2bbb-04540bdf743d@rrbone.net> Thanks for your efforts in filtering and liaising with CN! This issue has been fixed by ~ 1430 UTC today. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x28B95CE4E3F0918D.asc Type: application/pgp-keys Size: 3187 bytes Desc: not available URL: From blake at ispn.net Fri Jan 4 17:47:37 2019 From: blake at ispn.net (Blake Hudson) Date: Fri, 4 Jan 2019 11:47:37 -0600 Subject: IP Dslams In-Reply-To: <1546613944.7588969@upnet.mymailsrvr.com> References: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> <1546613944.7588969@upnet.mymailsrvr.com> Message-ID: I was thinking the same thing. They're a few years out of support, but the Zhone 42xx IP DSLAM provides a 1Gbps ethernet uplink and 24 ADSL2+ DSL user ports per 1U chassis (stackable to achieve 192 ports total). Wish they were available in AC for non-telco use. http://support.zhone.com/support/manuals/docs/42/4200-A2-GN21-40.pdf You could pair these with a pfSense appliance (or an x86 PC running the free software) to provide DHCP, DNS, etc - or use the built in pfSense captive portal to provide additional authentication and accounting per user. pfSense can provide NAT and FW if needed, or these features can be disabled to use globally routable IP4/IP6 addresses. As far as support goes, backup your pfsense and DLSAM configs when you finish the project and the subscriber accounts and DSL modems could be maintained by a local admin through the pfSense web interface with no need to touch the DSLAMs or anything CLI. --Blake Shawn L via NANOG wrote on 1/4/2019 8:59 AM: > > Might want to look for old Zhone ip bitstorm dslams.  There should be > a bunch on the used market.  They do all of the ATM conversions > internally so you just need to feed them with ethernet. > > > -----Original Message----- > From: "Nick Edwards" > Sent: Friday, January 4, 2019 9:36am > To: "Brandon Martin" > Cc: "NANOG" > Subject: Re: IP Dslams > > They don't have a large budget and although I'm yet to get prices on > adtran's (understandable, holidays 'n all) I doubt it will fit within > their budget, it's looking more like getting a few planet dslams and > configuring a linux box as the bng, been 10 years since I've had to do > that kind of setup, memories hazy, but I know it worked, and well, so > thanks to all for suggestions but the adtrans and nokias are not for > those on shoe string budgets, which wouldnt even allow me to include > an asr1k for the bng, and although it would allow for, I'd rather not > grab an ebay 7200/7300 :) > > On Wed, Jan 2, 2019 at 10:52 PM Brandon Martin > > wrote: > > On 1/2/19 6:47 AM, Nick Edwards wrote: > > There are 260 villas, and no coax. > > Is there a logical way to distribute the termination?  You might > be able > to get better performance (not that you perhaps care, in this > case) at > minimal additional cost if you can do building-local termination > of each > customer circuit and then backhaul on e.g. bonded VDSL2 or G.FAST > over > shorter distances (perhaps hopping building to building). > > I'm assuming there's no data grade copper or fiber if there's no > coax. > Obviously if you've got those, distributed termination makes even > more > sense. > > If you do want a centralized solution, an Adtran TA5006 (the small > chassis) with 6x 48 port VDSL2 combo modules (with or without > vectoring, > depending on your needs) would do the job (though it fills the > chassis > and doesn't allow for expansion, so the full-size TA5000 may be > desirable).  I've played (and am playing with) the same system but > with > GPON termination and have been happy with it so far. > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawnl at up.net Fri Jan 4 17:53:26 2019 From: shawnl at up.net (Shawn L) Date: Fri, 4 Jan 2019 12:53:26 -0500 (EST) Subject: IP Dslams In-Reply-To: References: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> <1546613944.7588969@upnet.mymailsrvr.com> Message-ID: <1546624406.664820050@upnet.mymailsrvr.com> The "newer" replacement for the 42xx series was the bitstorm (Bitstorm-RP2-152-AC), and they came in AC as well and 48 ports -- in a 1.5 U I think . -----Original Message----- From: "Blake Hudson" Sent: Friday, January 4, 2019 12:47pm To: nanog at nanog.org Subject: Re: IP Dslams I was thinking the same thing. They're a few years out of support, but the Zhone 42xx IP DSLAM provides a 1Gbps ethernet uplink and 24 ADSL2+ DSL user ports per 1U chassis (stackable to achieve 192 ports total). Wish they were available in AC for non-telco use. [ http://support.zhone.com/support/manuals/docs/42/4200-A2-GN21-40.pdf ]( http://support.zhone.com/support/manuals/docs/42/4200-A2-GN21-40.pdf ) You could pair these with a pfSense appliance (or an x86 PC running the free software) to provide DHCP, DNS, etc - or use the built in pfSense captive portal to provide additional authentication and accounting per user. pfSense can provide NAT and FW if needed, or these features can be disabled to use globally routable IP4/IP6 addresses. As far as support goes, backup your pfsense and DLSAM configs when you finish the project and the subscriber accounts and DSL modems could be maintained by a local admin through the pfSense web interface with no need to touch the DSLAMs or anything CLI. --Blake Shawn L via NANOG wrote on 1/4/2019 8:59 AM: Might want to look for old Zhone ip bitstorm dslams. There should be a bunch on the used market. They do all of the ATM conversions internally so you just need to feed them with ethernet. -----Original Message----- From: "Nick Edwards" [ ]( mailto:nick.z.edwards at gmail.com ) Sent: Friday, January 4, 2019 9:36am To: "Brandon Martin" [ ]( mailto:lists.nanog at monmotha.net ) Cc: "NANOG" [ ]( mailto:nanog at nanog.org ) Subject: Re: IP Dslams They don't have a large budget and although I'm yet to get prices on adtran's (understandable, holidays 'n all) I doubt it will fit within their budget, it's looking more like getting a few planet dslams and configuring a linux box as the bng, been 10 years since I've had to do that kind of setup, memories hazy, but I know it worked, and well, so thanks to all for suggestions but the adtrans and nokias are not for those on shoe string budgets, which wouldnt even allow me to include an asr1k for the bng, and although it would allow for, I'd rather not grab an ebay 7200/7300 :) On Wed, Jan 2, 2019 at 10:52 PM Brandon Martin <[ lists.nanog at monmotha.net ]( mailto:lists.nanog at monmotha.net )> wrote:On 1/2/19 6:47 AM, Nick Edwards wrote: > There are 260 villas, and no coax. Is there a logical way to distribute the termination? You might be able to get better performance (not that you perhaps care, in this case) at minimal additional cost if you can do building-local termination of each customer circuit and then backhaul on e.g. bonded VDSL2 or G.FAST over shorter distances (perhaps hopping building to building). I'm assuming there's no data grade copper or fiber if there's no coax. Obviously if you've got those, distributed termination makes even more sense. If you do want a centralized solution, an Adtran TA5006 (the small chassis) with 6x 48 port VDSL2 combo modules (with or without vectoring, depending on your needs) would do the job (though it fills the chassis and doesn't allow for expansion, so the full-size TA5000 may be desirable). I've played (and am playing with) the same system but with GPON termination and have been happy with it so far. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Fri Jan 4 17:56:28 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 4 Jan 2019 12:56:28 -0500 Subject: IP Dslams In-Reply-To: <1546624406.664820050@upnet.mymailsrvr.com> References: <472532b9-bb4c-ab1f-f18b-3c461b9fd122@monmotha.net> <1546613944.7588969@upnet.mymailsrvr.com> <1546624406.664820050@upnet.mymailsrvr.com> Message-ID: <7efbf473-4fd7-513e-09e1-25620feed55d@monmotha.net> On 1/4/19 12:53 PM, Shawn L via NANOG wrote: > The "newer" replacement for the 42xx series was the bitstorm > (Bitstorm-RP2-152-AC), and they came in AC as well and 48 ports -- in a > 1.5 U I think . Yep, that's probably the one you want to look at. I've got one on a shelf. Looks like a nice box. Pity it has no firmware on it. It does not have POTS built in, so you'd have to generate that somehow. An old Adit 600 with a bunch of FXS cards and CMG router might do it on the cheap. -- Brandon Martin From cscora at apnic.net Fri Jan 4 18:03:51 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Jan 2019 04:03:51 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190104180351.15593C44B7@thyme.apnic.net> 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-stats at 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 05 Jan, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 732608 Prefixes after maximum aggregation (per Origin AS): 281600 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 352811 Total ASes present in the Internet Routing Table: 62818 Prefixes per ASN: 11.66 Origin-only ASes present in the Internet Routing Table: 54157 Origin ASes announcing only one prefix: 23519 Transit ASes present in the Internet Routing Table: 8661 Transit-only ASes present in the Internet Routing Table: 267 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 22 Number of instances of unregistered ASNs: 24 Number of 32-bit ASNs allocated by the RIRs: 25373 Number of 32-bit ASNs visible in the Routing Table: 20560 Prefixes from 32-bit ASNs in the Routing Table: 88488 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 263 Number of addresses announced to Internet: 2838813409 Equivalent to 169 /8s, 52 /16s and 218 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 244490 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200435 Total APNIC prefixes after maximum aggregation: 56904 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 197571 Unique aggregates announced from the APNIC address blocks: 81259 APNIC Region origin ASes present in the Internet Routing Table: 9328 APNIC Prefixes per ASN: 21.18 APNIC Region origin ASes announcing only one prefix: 2633 APNIC Region transit ASes present in the Internet Routing Table: 1390 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4326 Number of APNIC addresses announced to Internet: 769208320 Equivalent to 45 /8s, 217 /16s and 48 /24s APNIC AS Blocks 4608-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: 216909 Total ARIN prefixes after maximum aggregation: 102896 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 216224 Unique aggregates announced from the ARIN address blocks: 103607 ARIN Region origin ASes present in the Internet Routing Table: 18302 ARIN Prefixes per ASN: 11.81 ARIN Region origin ASes announcing only one prefix: 6801 ARIN Region transit ASes present in the Internet Routing Table: 1842 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2528 Number of ARIN addresses announced to Internet: 1077014688 Equivalent to 64 /8s, 49 /16s and 240 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 200092 Total RIPE prefixes after maximum aggregation: 95539 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 196443 Unique aggregates announced from the RIPE address blocks: 116298 RIPE Region origin ASes present in the Internet Routing Table: 25720 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 11484 RIPE Region transit ASes present in the Internet Routing Table: 3611 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7702 Number of RIPE addresses announced to Internet: 716014656 Equivalent to 42 /8s, 173 /16s and 132 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 94946 Total LACNIC prefixes after maximum aggregation: 22030 LACNIC Deaggregation factor: 4.31 Prefixes being announced from the LACNIC address blocks: 96333 Unique aggregates announced from the LACNIC address blocks: 42307 LACNIC Region origin ASes present in the Internet Routing Table: 7953 LACNIC Prefixes per ASN: 12.11 LACNIC Region origin ASes announcing only one prefix: 2180 LACNIC Region transit ASes present in the Internet Routing Table: 1476 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5500 Number of LACNIC addresses announced to Internet: 173201152 Equivalent to 10 /8s, 82 /16s and 215 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 20203 Total AfriNIC prefixes after maximum aggregation: 4214 AfriNIC Deaggregation factor: 4.79 Prefixes being announced from the AfriNIC address blocks: 25774 Unique aggregates announced from the AfriNIC address blocks: 9097 AfriNIC Region origin ASes present in the Internet Routing Table: 1233 AfriNIC Prefixes per ASN: 20.90 AfriNIC Region origin ASes announcing only one prefix: 421 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 504 Number of AfriNIC addresses announced to Internet: 102971904 Equivalent to 6 /8s, 35 /16s and 58 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4656 515 522 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4644 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3011 1160 90 VIETEL-AS-AP Viettel Group, VN 45899 2985 1717 115 VNPT-AS-VN VNPT Corp, VN 4766 2815 11129 768 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2500 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2408 4906 29 CTTNET China TieTong Telecommunications 17974 2253 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2140 437 181 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3503 1326 92 SHAW - Shaw Communications Inc., CA 11492 3484 225 600 CABLEONE - CABLE ONE, INC., US 22773 3309 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2604 5293 975 AMAZON-02 - Amazon.com, Inc., US 16625 2201 1229 1692 AKAMAI-AS - Akamai Technologies, Inc., 20115 2150 2754 533 CHARTER-20115 - Charter Communications, 18566 2138 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2095 349 129 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2076 5077 589 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5261 1628 138 UNI2-AS, ES 39891 3517 185 20 ALJAWWALSTC-AS, SA 8551 3289 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2632 577 1935 AKAMAI-ASN1, US 12389 2228 2221 626 ROSTELECOM-AS, RU 34984 2049 338 528 TELLCOM-AS, TR 9121 1683 1691 17 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 8402 1292 544 17 CORBINA-AS OJSC "Vimpelcom", RU 9009 1222 131 684 M247, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5470 3319 589 Uninet S.A. de C.V., MX 10620 3150 475 905 Telmex Colombia S.A., CO 11830 2679 371 71 Instituto Costarricense de Electricidad 6503 1649 449 54 Axtel, S.A.B. de C.V., MX 7303 1438 960 233 Telecom Argentina S.A., AR 28573 1186 2237 182 CLARO S.A., BR 6147 1079 377 29 Telefonica del Peru S.A.A., PE 3816 1025 511 112 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 939 143 67 Alestra, S. de R.L. de C.V., MX 13999 938 539 259 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1161 393 22 LINKdotNET-AS, EG 37611 898 107 9 Afrihost, ZA 36903 797 401 139 MT-MPLS, MA 36992 781 1411 44 ETISALAT-MISR, EG 24835 683 634 21 RAYA-AS, EG 8452 650 1731 19 TE-AS TE-AS, EG 29571 481 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 37342 421 32 1 MOVITEL, MZ 15399 415 45 11 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5470 3319 589 Uninet S.A. de C.V., MX 12479 5261 1628 138 UNI2-AS, ES 7545 4656 515 522 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4644 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3517 185 20 ALJAWWALSTC-AS, SA 6327 3503 1326 92 SHAW - Shaw Communications Inc., CA 11492 3484 225 600 CABLEONE - CABLE ONE, INC., US 22773 3309 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3289 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3150 475 905 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5261 5123 UNI2-AS, ES 4538 4644 4570 ERX-CERNET-BKB China Education and Research Net 7545 4656 4134 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3517 3497 ALJAWWALSTC-AS, SA 6327 3503 3411 SHAW - Shaw Communications Inc., CA 8551 3289 3246 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3309 3135 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3011 2921 VIETEL-AS-AP Viettel Group, VN 11492 3484 2884 CABLEONE - CABLE ONE, INC., US 45899 2985 2870 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 4200058511 PRIVATE 103.111.177.0/24 137522 OERL-AS-AP Origin Energy Retai 4200058511 PRIVATE 103.111.178.0/24 137522 OERL-AS-AP Origin Energy Retai 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:36 /11:99 /12:291 /13:568 /14:1127 /15:1913 /16:13341 /17:7877 /18:13854 /19:25515 /20:39677 /21:46098 /22:91160 /23:74548 /24:413605 /25:925 /26:820 /27:880 /28:32 /29:18 /30:9 /31:2 /32:191 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4113 5261 UNI2-AS, ES 6327 3266 3503 SHAW - Shaw Communications Inc., CA 11492 2764 3484 CABLEONE - CABLE ONE, INC., US 8551 2745 3289 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 39891 2689 3517 ALJAWWALSTC-AS, SA 22773 2549 3309 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2033 2138 MEGAPATH5-US - MegaPath Corporation, US 11830 2024 2679 Instituto Costarricense de Electricidad y Telec 30036 1843 2095 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1626 2:889 3:1 4:23 5:2411 6:43 7:1 8:1174 12:1876 13:303 14:1884 15:37 16:2 17:209 18:59 20:48 23:2563 24:2418 25:2 27:2551 31:2012 32:92 35:31 36:824 37:2998 38:1600 39:282 40:121 41:3157 42:730 43:2007 44:136 45:6478 46:3114 47:244 49:1333 50:1080 51:319 52:1088 54:363 55:1 56:6 57:41 58:1715 59:1070 60:461 61:2090 62:2211 63:1809 64:5093 65:2200 66:4823 67:2685 68:1165 69:3443 70:1145 71:603 72:2278 74:2745 75:407 76:525 77:1707 78:1720 79:2320 80:1645 81:1416 82:1063 83:879 84:1077 85:2130 86:559 87:1502 88:992 89:2399 90:210 91:6535 92:1224 93:2359 94:2373 95:3117 96:909 97:349 98:934 99:169 100:88 101:1162 102:335 103:19647 104:3564 105:242 106:897 107:1834 108:703 109:3611 110:1633 111:1911 112:1395 113:1380 114:1153 115:1720 116:1618 117:1924 118:2204 119:1685 120:1150 121:1029 122:2363 123:1636 124:1451 125:1942 128:1195 129:690 130:523 131:1644 132:716 133:213 134:1043 135:229 136:539 137:673 138:1931 139:790 140:569 141:762 142:803 143:996 144:897 145:504 146:1250 147:775 148:1706 149:799 150:780 151:998 152:935 153:324 154:2413 155:965 156:1639 157:852 158:658 159:1899 160:1491 161:904 162:2654 163:772 164:1121 165:1586 166:465 167:1350 168:3207 169:866 170:3985 171:496 172:1072 173:2143 174:996 175:879 176:2274 177:4050 178:2558 179:1292 180:2097 181:2355 182:2678 183:1352 184:1139 185:14512 186:3666 187:2463 188:2975 189:2087 190:8281 191:1402 192:10021 193:6483 194:5332 195:4046 196:2896 197:1733 198:5701 199:5964 200:7418 201:5006 202:10235 203:10195 204:4628 205:3022 206:3306 207:3281 208:3943 209:4190 210:3904 211:2009 212:3072 213:2826 214:1073 215:52 216:5978 217:2197 218:899 219:575 220:1834 221:997 222:980 223:1421 End of report From mehmet at akcin.net Fri Jan 4 18:47:39 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 4 Jan 2019 10:47:39 -0800 Subject: How to choose a transport(terrestrial/subsea) In-Reply-To: References: <782357206.2397.1544892820238.JavaMail.mhammett@ThunderFuck> <2ECC8F52-7A86-4A84-9B32-CC3F64446BD4@6by7.net> <788457847.2761.1544902202755.JavaMail.mhammett@ThunderFuck> <1070675904.7469.1545939242369.JavaMail.mhammett@ThunderFuck> <1546449256.2927700.1623697752.298D0161@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40318ED5740@WAUPRDMBXP1.medline.com> <1430298816.3948.1546451453778.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, Jan 2, 2019 at 2:04 PM Jason Bothe via NANOG wrote: > KMZs or no business. Period. > You can say that in US, EU but you won't be able to in certain places unless you are willing to take the extra mile and work with people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahenderson at avci.net Fri Jan 4 12:57:40 2019 From: ahenderson at avci.net (Aaron Henderson) Date: Fri, 4 Jan 2019 07:57:40 -0500 Subject: Changing upstream providers, opinions/thoughts on 123.net and cogent Message-ID: I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net and Cogent. I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Thanks, A -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkehoe at pdmi.com Fri Jan 4 15:22:48 2019 From: dkehoe at pdmi.com (David Kehoe) Date: Fri, 4 Jan 2019 15:22:48 +0000 Subject: Cleveland/Cincinnati Co-location Message-ID: <5D377D6CCA7EBD40AD0F62E94DF49375BB60420D@MAIL23.PDMBOARDMAN.local> Former employer was in Expedient’s DC. You can honestly do better than Expedient. Look into the Power Redundancy, Cooling Efficiency of the building, if the site is a purpose built DC (Expedient in Cleveland is not). Is Cloud Connect for backups important? Have you identified your requirements? If you need a starting point look at the following: Data Center Certification (from the Uptime Institute), Distance, Compliance (if needed), Level of Controlled Access, Power SLA, N+1 Cooling, Multi-Homed ISPs, Uptime %, Monitoring, NOC, Purpose Built DC. Involta has a really good data center in Independence, Akron, and a very impressive site near Pittsburgh. They would give you the option of having Hot/Hot datacenters with their connectivity. I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, is on the Century Link backbone, and has a solid rubber roof with no holes or cooling systems on the roof.) Thank you, David Kehoe From: NANOG On Behalf Of nanog-request at nanog.org Sent: Friday, January 4, 2019 7:00 AM To: nanog at nanog.org Subject: NANOG Digest, Vol 132, Issue 4 Send NANOG mailing list submissions to nanog at 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 at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Cleveland/Cincinnati Co-location (Allen McKinley Kitchen (gmail)) 2. Re: Service Provider NetFlow Collectors (Aaron) 3. Re: Cleveland/Cincinnati Co-location (Shawn Ritchie) 4. Re: Announcing Peering-LAN prefixes to customers (Andy Davidson) 5. Report on Legal Barriers to RPKI Adoption (Christopher S. Yoo) 6. 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Dominik Bay) 7. Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Jeff Shultz) 8. Astronaut accidently calls 911 from space (Sean Donelan) 9. Re: Cellular backup connections (Dovid Bender) 10. Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Job Snijders) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Jan 2019 10:50:45 -0500 From: "Allen McKinley Kitchen (gmail)" > To: "Justin M. Streiner" > Cc: NANOG > Subject: Re: Cleveland/Cincinnati Co-location Message-ID: <91679AF9-E310-463C-B427-630F69C02222 at gmail.com> Content-Type: text/plain; charset=us-ascii +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) ..Allen > On Jan 3, 2019, at 01:00, Justin M. Streiner > wrote: > >> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >> >> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >> >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. > > Expedient has two facilities in Cleveland that might be worth looking at. > > Thank you > jms ------------------------------ Message: 2 Date: Thu, 3 Jan 2019 10:40:44 +0900 From: Aaron > To: "Michel 'ic' Luczak" > Cc: Erik Sundberg >, "nanog at nanog.org" > Subject: Re: Service Provider NetFlow Collectors Message-ID: > Content-Type: text/plain; charset="utf-8" Throwing my hat in the ring also (vendor from fmadio) https://github.com/fmadio/pcap2json Not exactly a newflow collector, its pcap -> flowgen -> elk on a single box, working very well so far, still work in progress. Problem with logstash is its too slow for high flow rates. So we did everything inside the flow generator for direct ELK bulk uploads removing logstash completely. Cheers Aaron On Mon, 31 Dec 2018 at 18:40, Michel 'ic' Luczak > wrote: > Don’t underestimate good old ELK > https://www.elastic.co/guide/en/logstash/current/netflow-module.html > + https://github.com/robcowart/elastiflow > > BR, ic > > On 31 Dec 2018, at 04:29, Erik Sundberg > wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what other > service providers are using to collect netflow data off their Core and Edge > Routers. Pros/Cons… What to watch out for any info would help. > > We are mainly looking to analyze the netflow data. Bonus if it does ddos > detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer – Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance… > > Erik > > > ------------------------------ > > 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Message: 3 Date: Thu, 3 Jan 2019 11:21:32 -0600 From: Shawn Ritchie > To: "Allen McKinley Kitchen (gmail)" > Cc: "Justin M. Streiner" >, NANOG > Subject: Re: Cleveland/Cincinnati Co-location Message-ID: <19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1 at fastmail.fm> Content-Type: text/plain; charset=utf-8 On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) > wrote: > > +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) > > ..Allen > >> On Jan 3, 2019, at 01:00, Justin M. Streiner > wrote: >> >>> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >>> >>> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >>> >>> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. >> >> Expedient has two facilities in Cleveland that might be worth looking at. >> >> Thank you >> jms I’m in Expedient’s Cleveland DC and will second that they’re decent. — Shawn ------------------------------ Message: 4 Date: Thu, 3 Jan 2019 20:08:46 +0000 From: Andy Davidson > To: Dominic Schallert > Cc: "nanog at nanog.org" > Subject: Re: Announcing Peering-LAN prefixes to customers Message-ID: <34E9593E-5004-4A01-BAFC-E56CA6520433 at nosignal.org> Content-Type: text/plain; charset="utf-8" Hi, Dominic -- On 20/12/2018, 17:49, Dominic Schallert > wrote: > this might be a stupid question but today I was discussing with a colleague if > Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. > My standpoint is that in any case, Peering-LAN prefixes should be filtered and not > announced to peers/customers because a Peering-LAN represents some sort of > DMZ and there is simply no need for them to be reachable by third-parties not being > physically connected to an IXP themselves. There are no stupid questions! It is a good idea to not BGP announce and perhaps also to drop traffic toward peering LAN prefixes at customer-borders, this was already well discussed in the thread. But there wasn’t a discussion on how we got to this point. Until the Cloudflare 2013 BGP speaker attack, that sought to flood Cloudflare’s transfer networks and exchange connectivity (and with it saturating IXP inter-switch links and IXP participant ports), it was common for IXP IPv4/6 peering LANs to be internet reachable and BGP transited. This facilitated troubleshooting (e.g. traceroutes showing peering lan interfaces in traceroutes instead of ‘starring out’) and PMTUD (e.g. see recommendation in https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html which actually asked for IXP peering LANs to be announced). There are good reasons to announce but there are better reasons to filter. The security benefits of filtering outweigh the upsides on today’s internet, but fashions and best practice may further evolve over time. Andy -- Andy Davidson Director, Asteroid International BV www.asteroidhq.com Director, Euro-IX - The European Internet Exchange Association www.euro-ix.net ------------------------------ Message: 5 Date: Thu, 3 Jan 2019 20:51:56 +0000 From: "Christopher S. Yoo" > To: "nanog at nanog.org" > Cc: David Wishnick > Subject: Report on Legal Barriers to RPKI Adoption Message-ID: > Content-Type: text/plain; charset="utf-8" As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here>. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo at law.upenn.edu> http://www.law.upenn.edu/faculty/csyoo/ For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/. -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Message: 6 Date: Thu, 3 Jan 2019 22:01:56 +0000 From: Dominik Bay > To: "nanog at nanog.org" > Subject: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06 at rrbone.net> Content-Type: text/plain; charset="utf-8" I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 originated by 4812 209 286 3320 5400 5511 6327 6461 6762 6830 8218 8220 8447 8551 9002 12956 The proper source is 32982 (Department of Energy). More details to be found here: https://bgpstream.com/event/171779 And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 Cheers, Dominik ------------------------------ Message: 7 Date: Thu, 3 Jan 2019 14:37:28 -0800 From: Jeff Shultz > To: Dominik Bay > Cc: "nanog at nanog.org" > Subject: Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: > Content-Type: text/plain; charset="UTF-8" China Telecom originating a network that belongs to the agency that controls all things nuclear in the US... nothing suspicious there. On Thu, Jan 3, 2019 at 2:03 PM Dominik Bay > wrote: > > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779 > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 > > Cheers, > Dominik > > -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!! > > > > _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ ------------------------------ Message: 8 Date: Thu, 3 Jan 2019 17:45:00 -0500 (EST) From: Sean Donelan > To: nanog at nanog.org Subject: Astronaut accidently calls 911 from space Message-ID: > Content-Type: text/plain; format=flowed; charset=US-ASCII I was disappointed that it was just a misdial. I was looking forward to how IP geolocation worked with 9-1-1 calls from space. I always wondered how that altitude parameter in 911 packets was used. :-) https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892 ------------------------------ Message: 9 Date: Thu, 3 Jan 2019 18:46:08 -0500 From: Dovid Bender > To: Mark Milhollan > Cc: NANOG > Subject: Re: Cellular backup connections Message-ID: > Content-Type: text/plain; charset="utf-8" All, Thanks for all of the feedback. I was on site today and noticed two things. 1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this. 2) I was watching the ping times and it looked something like this: 400ms 360ms 330ms 300ms 260ms 210ms 170ms 140ms 120ms 400ms 375ms It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes. On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan > wrote: > On Fri, 28 Dec 2018, Dovid Bender wrote: > > >I finally got around to setting up a cellular backup device in our new > POP. > > >When SSH'ing in remotely the connection seems rather slow. > > Perhaps using MOSH can help make the interactive CLI session less > annoying. > > >Verizon they charge $500.00 just to get a public IP and I want to avoid > >that if possible. > > You might look into have it call out / maintain a connection back to > your infrastructure. > > > /mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Message: 10 Date: Fri, 4 Jan 2019 11:21:32 +0300 From: Job Snijders > To: Dominik Bay > Cc: "nanog at nanog.org" > Subject: Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: > Content-Type: text/plain; charset="utf-8" Dear all, NTT / AS 2914 deployed explicit filters to block this BGP announcement from AS 4134. I recommend other operators to do the same. I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the /24 announcement so the counter measure is more effective. Kind regards, Job On Fri, Jan 4, 2019 at 1:02 Dominik Bay > wrote: > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24 > originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779 > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0 > > Cheers, > Dominik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: > End of NANOG Digest, Vol 132, Issue 4 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at pickering.org Fri Jan 4 15:37:49 2019 From: rob at pickering.org (Rob Pickering) Date: Fri, 4 Jan 2019 15:37:49 +0000 Subject: IP Dslams In-Reply-To: References: Message-ID: Just a thought, would a two wire Ethernet extender technology (eg Phybridge) provide you with a simpler solution? xDSL needs a lot of infrastructure for a low port count (& budget) application. I have no idea if you can split the baseband out to provide POTS over the same pair, but even if you can't, Ethernet plus a VoIP phone or ATA to each unit may end up cheaper than a shed load of carrier oriented xDSL infra? On Mon, 31 Dec 2018 at 19:15, Nick Edwards wrote: > Howdy, > We have a requirement for an aged care facility to provide voice and data, > we have the voice worked out, but data, WiFi is out of the question, so are > looking for IP-Dslams, preferably a system that is all-in-one, or self > contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has > a property managment API, or even just a webpage manager where admin can > add in new residents when they arive, or delete when they depart I know > these used to be available many years ago, but that vendor has like many > vanished, only requirement is for ADSL2+, prefer units with either 48 ports > or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 > etc) > > If anyone knows of such units, would appreciate some details on them, > brand/model suppliers if known, etc, we can try get out google fu back if > we have some steering:) > > Thank Y'all > > (resent - original never made it to the list for some gremlin reason) > -- -- Rob Pickering, rob at pickering.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Sat Jan 5 02:15:48 2019 From: ben at 6by7.net (Ben Cannon) Date: Fri, 4 Jan 2019 18:15:48 -0800 Subject: Changing upstream providers, opinions/thoughts on 123.net and cogent In-Reply-To: References: Message-ID: <0948EA58-2F09-4BBE-BE23-3E64441DE1EC@6by7.net> Run BGP and use multiple upstream providers as soon as you can. -Ben > On Jan 4, 2019, at 4:57 AM, Aaron Henderson wrote: > > I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net and Cogent. > > I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. > > I was hoping some of you here might have experience with these providers and could share your experiences and opinions. > > Thanks, > > A > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jan 5 03:27:16 2019 From: bill at herrin.us (William Herrin) Date: Fri, 4 Jan 2019 19:27:16 -0800 Subject: Changing upstream providers, opinions/thoughts on 123.net and cogent In-Reply-To: References: Message-ID: On Fri, Jan 4, 2019 at 5:40 PM Aaron Henderson wrote: > I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net and Cogent. > > I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Hi Aaron, I don't know anything about 123.net. Google "Cogent cake," "cogent sprint," and "cogent telia" for explanations and examples of how relying on Cogent as your sole transit provider is likely to bite you in the behind. Using them as a secondary transit provider in a BGP-managed mix is arguably more acceptable. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lists.nanog at monmotha.net Sat Jan 5 03:43:12 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 4 Jan 2019 22:43:12 -0500 Subject: Changing upstream providers, opinions/thoughts on 123.net and cogent In-Reply-To: References: Message-ID: To reiterate what's been said... I would not want to be single-homed to Cogent. They're fine (and generally useful and a reasonable use of your operating money) in a blend. I'm not familiar with 123.net, but looking briefly at them, they appear to be a regional blend. Much preferable compared to your other option assuming they competently operate their network. FWIW, I wouldn't WANT to be single-homed to anyone, but I'll do it when it's the right choice. If you have to be single-homed, you really have to go with a quality upstream, and you're going to pay for it. If you have the volume and connectivity to be multi-homed, do it. It'll be better in just about every way. -- Brandon Martin From me at payam124.com Sat Jan 5 07:22:58 2019 From: me at payam124.com (Payam Poursaied) Date: Fri, 4 Jan 2019 23:22:58 -0800 Subject: IP Dslams In-Reply-To: References: Message-ID: <025901d4a4c7$7c8d28e0$75a77aa0$@payam124.com> Hi Nick How many devices are you looking for? Consider ZyXEL 1248: https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/ For PPP and those stuff, you can rely on MikroTik. i.e. https://mikrotik.com/product/rb4011igs_rm @199USD you would have PPP(oE) aggregation + user manager panel and much more Regards Payam From: NANOG On Behalf Of Nick Edwards Sent: December 28, 2018 5:36 PM To: nanog at nanog.org Subject: IP Dslams Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sat Jan 5 15:05:14 2019 From: sander at steffann.nl (Sander Steffann) Date: Sat, 5 Jan 2019 16:05:14 +0100 Subject: IP Dslams In-Reply-To: <025901d4a4c7$7c8d28e0$75a77aa0$@payam124.com> References: <025901d4a4c7$7c8d28e0$75a77aa0$@payam124.com> Message-ID: Hi, > How many devices are you looking for? > Consider ZyXEL 1248: https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/ I had bad experiences with those. When testing IPv6 they messed up the data inside the PPP session. The client would negotiate IPv6 just fine, but then no IPv6 packet ever made it through the Zyxel. I replaced them with Draytek VigorAccess, which worked fine for testing. My customer that used those Draytek's stopped using them last year. If anyone is interested I can ask them if they are still in storage somewhere. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From mlewis at techcompute.net Sat Jan 5 17:54:58 2019 From: mlewis at techcompute.net (Mitchell Lewis) Date: Sat, 5 Jan 2019 17:54:58 +0000 Subject: Verizon IDE Message-ID: How common is it for Verizon to deliver "Internet Dedicated Ethernet" over sonet? Ran into a situation where the canoga-perkins nte was uplinked to a Flashwave 4100es in the basement (uplinked by an OC-48). There is in a Verizon ILEC area. Thanks & Regards, Mitchell Lewis mlewis at techcompute.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From streinerj at gmail.com Sat Jan 5 20:06:00 2019 From: streinerj at gmail.com (Justin M. Streiner) Date: Sat, 5 Jan 2019 15:06:00 -0500 (EST) Subject: Verizon IDE In-Reply-To: References: Message-ID: On Sat, 5 Jan 2019, Mitchell Lewis wrote: > How common is it for Verizon to deliver "Internet Dedicated Ethernet" > over sonet? Ran into a situation where the canoga-perkins nte was > uplinked to a Flashwave 4100es in the basement (uplinked by an OC-48). > There is in a Verizon ILEC area. If the location has an existing Verizon SONET node, and there is capacity on it to provide the Ethernet service you need, Verizon could opt to deliver the Ethernet service that way. Thank you jms From goemon at sasami.anime.net Sat Jan 5 22:29:26 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Sat, 5 Jan 2019 14:29:26 -0800 (PST) Subject: attempted archive.is hijacking Message-ID: https://twitter.com/archiveis/status/1081276424781287427 Wonder what tactic the hijackers are using, and if it would work with any registrar - or if there is something specific about isnic that allows it to happen. -Dan From mel at beckman.org Sat Jan 5 23:01:44 2019 From: mel at beckman.org (Mel Beckman) Date: Sat, 5 Jan 2019 23:01:44 +0000 Subject: Verizon IDE In-Reply-To: References: , Message-ID: Verizon’s build-out policy boils down to whether or not any new contract will fund the metro-E upgrade costs over a five year period. If it won’t, then SONET is used where there is capacity, right up to the capacity limit. We recently received a 100 Mbps Ethernet circuit on the last OC3 of a SONET node. I argued that we should have been put on MetroE to enable future upgrades, since there is no orderable bandwidth left on this node, and Verizon’s reply was “you would have to order a bigger circuit now”. Frankly, I couldn’t justify the jump to GigE, so here we are on maxed-out facilities. -mel beckman > On Jan 5, 2019, at 12:06 PM, Justin M. Streiner wrote: > >> On Sat, 5 Jan 2019, Mitchell Lewis wrote: >> >> How common is it for Verizon to deliver "Internet Dedicated Ethernet" over sonet? Ran into a situation where the canoga-perkins nte was uplinked to a Flashwave 4100es in the basement (uplinked by an OC-48). There is in a Verizon ILEC area. > > If the location has an existing Verizon SONET node, and there is capacity on it to provide the Ethernet service you need, Verizon could opt to deliver the Ethernet service that way. > > Thank you > jms From cma at cmadams.net Sun Jan 6 04:56:53 2019 From: cma at cmadams.net (Chris Adams) Date: Sat, 5 Jan 2019 22:56:53 -0600 Subject: Google Fiber v6 PD only giving /64 Message-ID: <20190106045653.GA32738@cmadams.net> Anybody here from Google Fiber? When I first got it last year, my IPv6 setup got a /56 prefix delegated. I now see that no matter what size I request, I only get a /64. Is this intentional? -- Chris Adams From me at payam124.com Sun Jan 6 05:56:01 2019 From: me at payam124.com (Payam Poursaied) Date: Sat, 5 Jan 2019 21:56:01 -0800 Subject: IP Dslams In-Reply-To: References: <025901d4a4c7$7c8d28e0$75a77aa0$@payam124.com> Message-ID: <03c701d4a584$81acf950$8506ebf0$@payam124.com> Hi -----Original Message----- From: Sander Steffann Sent: January 5, 2019 7:05 AM Hi, >> How many devices are you looking for? >> Consider ZyXEL 1248: https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/ >I had bad experiences with those. When testing IPv6 they messed up the data inside the PPP session. The client would negotiate IPv6 just fine, >but then no IPv6 packet ever made it through the Zyxel. I replaced them with Draytek VigorAccess, which worked fine for testing. My customer ?>that used those Draytek's stopped using them last year. If anyone is interested I can ask them if they are still in storage somewhere. Not sure about 1248, but my fellow has tested 5106 and IES6000 (https://www.zyxel.com/products_services/5U-6-slot-Chassis-MSAN-IES-5106-Series/) both work fine From sander at steffann.nl Sun Jan 6 13:55:21 2019 From: sander at steffann.nl (Sander Steffann) Date: Sun, 6 Jan 2019 14:55:21 +0100 Subject: Google Fiber v6 PD only giving /64 In-Reply-To: <20190106045653.GA32738@cmadams.net> References: <20190106045653.GA32738@cmadams.net> Message-ID: <840AE636-4C21-4102-9A52-79D1306798C1@steffann.nl> Hi, > Anybody here from Google Fiber? When I first got it last year, my IPv6 > setup got a /56 prefix delegated. I now see that no matter what size I > request, I only get a /64. Is this intentional? Sounds broken, especially considering how people like Lorenzo have always fought for giving everybody plenty of address space... Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From sander at steffann.nl Sun Jan 6 13:57:19 2019 From: sander at steffann.nl (Sander Steffann) Date: Sun, 6 Jan 2019 14:57:19 +0100 Subject: IP Dslams In-Reply-To: References: <025901d4a4c7$7c8d28e0$75a77aa0$@payam124.com> Message-ID: <563AD045-3B0A-4F11-93B0-D68939421C7D@steffann.nl> Hi, >> How many devices are you looking for? >> Consider ZyXEL 1248: https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/ > > I had bad experiences with those. My apologies, my problems were with a different Zyxel model (which I don't recall anymore). Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From job at ntt.net Sun Jan 6 16:02:35 2019 From: job at ntt.net (Job Snijders) Date: Sun, 6 Jan 2019 19:02:35 +0300 Subject: Report on Legal Barriers to RPKI Adoption In-Reply-To: References: Message-ID: Dear Christopher, David, NANOG community, Thank you for your research and report. I found the report quite readable (not having a legal background) and well structured. Definitely edifying and worth the read! In this mail I’ll reply specifically to a few points from the executive summary (and snip the rest). For those of you who don’t want to create a SSRN account here is a copy of the report: http://instituut.net/~job/SSRN-id3309813.pdf On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo wrote: > Here is a summary of our recommendations: > On the ROV side of the equation, the principal legal hindrances have to do > with the terms and conditions governing access to the RPKI repository > offered by ARIN in its Relying Party Agreement (“RPA”), and in the manner > it has employed to ensure the agreement is binding. Regarding ROV: > > 1. The goal of widespread ROV counsels in favor of ARIN reviewing > its current approach to repository distribution, embodied in the RPA. We > conclude that two paths would be reasonable. First, ARIN should consider > dropping the RPA altogether. This would remove the most significant legal > barriers to widespread utilization of the ARIN RPKI repository. > I’m happy to see suggestions that dropping the RPA is a viable path. In December 2018 we’ve measured that around TWENTY percent of the networks deploying RPKI based Origin Validation are missing the ARIN TAL [source: benjojo]. This is an extremely worrying number, as it means that ARIN ROAs are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the root cause for ARIN being an outliner is absence of the ARIN TAL in the common RPKI Validation softwares. The absence of the ARIN TAL in software distributions can be directly attributed to the existence of the RPA and applicable contract doctrines. If no changes are made to the current situation, I expect the 20% number to remain the same or even grow, effectively making ARIN’s RPKI services unsuitable for the purpose of securing routing. 2. Developers of RPKI validation software should consider integrating > acceptance of ARIN’s RPA into their software workflows. ARIN recently > enabled this possibility, and developers should deliberate on whether to > capitalize on the opportunity. > To put it bluntly: item 2 is not going to happen. We’ve discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or IRR data - and we’re not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN’s RPA into their installation process. 4. In addition to the important step ARIN has already taken to enable > third-party software developers to integrate RPA acceptance into their > software workflows, ARIN should consider reducing the barriers to > third-party service development imposed by the RPA’s prohibited conduct > clause. Specifically, ARIN should consider methods for allowing approved > developers to make use of RPKI information as an input into more > sophisticated services. > 5. Separately, ARIN should consider revising the prohibited conduct > clause to allow broader distribution of information created with RPKI as an > input for research and analysis purposes. > To provide context for the above two paragraphs, at this point in time it’s unclear whether BGPMon’s WHOIS, NLNOG’s IRRExplorer, and the various “RPKI to IRR” services are violating the RPA. I believe it to be highly undesirable for this uncertainty to persist, nor would it be acceptable to require each and every (potential) innovator or researcher to sign contracts with ARIN. ARIN members would be significantly worse off if these services stop using the ARIN TAL. Finally, ARIN members should realize that the majority of ASNs on the Internet are *outside* North America and are not ARIN members. We want *all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and misconfigurations don’t know borders. It’s not reasonable to require Dutch, Indian, Russian and Chinese networks to enter into a contractual agreement with ARIN in order to protect the ARIN members. This is why we need things to work properly out of the box, just like was done with DNSSEC. Reform is needed. Kind regards, Job [benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018 [rpki-client]: https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sun Jan 6 22:51:00 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 6 Jan 2019 17:51:00 -0500 Subject: Cleveland/Cincinnati Co-location In-Reply-To: <5D377D6CCA7EBD40AD0F62E94DF49375BB60420D@MAIL23.PDMBOARDMAN.local> References: <5D377D6CCA7EBD40AD0F62E94DF49375BB60420D@MAIL23.PDMBOARDMAN.local> Message-ID: > > I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has > an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, > is on the Century Link backbone, and has a solid rubber roof with no holes > or cooling systems on the roof.) Being on the CenturyLink backbone doesn't sound like a selling point to me... On Fri, Jan 4, 2019 at 8:46 PM David Kehoe wrote: > Former employer was in Expedient’s DC. You can honestly do better than > Expedient. Look into the Power Redundancy, Cooling Efficiency of the > building, if the site is a purpose built DC (Expedient in Cleveland is > not). Is Cloud Connect for backups important? Have you identified your > requirements? If you need a starting point look at the following: Data > Center Certification (from the Uptime Institute), Distance, Compliance (if > needed), Level of Controlled Access, Power SLA, N+1 Cooling, Multi-Homed > ISPs, Uptime %, Monitoring, NOC, Purpose Built DC. > > > > Involta has a really good data center in Independence, Akron, and a very > impressive site near Pittsburgh. They would give you the option of having > Hot/Hot datacenters with their connectivity. I’m not sure if you have to be > in Cleveland or Cincinnati, but Cyxtera has an AMAZING data center in > Columbus. (The DC can withstand winds up 140 MPH, is on the Century Link > backbone, and has a solid rubber roof with no holes or cooling systems on > the roof.) > > > > Thank you, > > > > *David Kehoe* > > > > *From:* NANOG *On Behalf Of * > nanog-request at nanog.org > *Sent:* Friday, January 4, 2019 7:00 AM > *To:* nanog at nanog.org > *Subject:* NANOG Digest, Vol 132, Issue 4 > > > > Send NANOG mailing list submissions to > nanog at 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 at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Cleveland/Cincinnati Co-location > (Allen McKinley Kitchen (gmail)) > 2. Re: Service Provider NetFlow Collectors (Aaron) > 3. Re: Cleveland/Cincinnati Co-location (Shawn Ritchie) > 4. Re: Announcing Peering-LAN prefixes to customers (Andy Davidson) > 5. Report on Legal Barriers to RPKI Adoption (Christopher S. Yoo) > 6. 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, > 6762, 6830, 8220, 9002, 12956 (Dominik Bay) > 7. Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, > 6461, 6762, 6830, 8220, 9002, 12956 (Jeff Shultz) > 8. Astronaut accidently calls 911 from space (Sean Donelan) > 9. Re: Cellular backup connections (Dovid Bender) > 10. Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, > 6461, 6762, 6830, 8220, 9002, 12956 (Job Snijders) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Jan 2019 10:50:45 -0500 > From: "Allen McKinley Kitchen (gmail)" > > To: "Justin M. Streiner" > Cc: NANOG > Subject: Re: Cleveland/Cincinnati Co-location > Message-ID: <91679AF9-E310-463C-B427-630F69C02222 at gmail.com> > Content-Type: text/plain; charset=us-ascii > > +1 for Expedient. Not a current customer but a VERY satisfied former > customer. (Decision to leave them was a foul case of penny-pincher > mismanagement, above my pay grade and over my objections.) > > ..Allen > > > On Jan 3, 2019, at 01:00, Justin M. Streiner > wrote: > > > >> On Tue, 1 Jan 2019, Mitchell Lewis wrote: > >> > >> I am working on project that may involve building points of presence in > Cleveland & Cincinnati. Any suggestions as to which colocation facility in > each city to build in? The prime factor of consideration for this project > is access to waves to places like Chicago, New York & Ashburn. It would be > nice to have multiple wave provider options to choose from. > >> > >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in > Cleveland. > > > > Expedient has two facilities in Cleveland that might be worth looking at. > > > > Thank you > > jms > > ------------------------------ > > Message: 3 > Date: Thu, 3 Jan 2019 11:21:32 -0600 > From: Shawn Ritchie > To: "Allen McKinley Kitchen (gmail)" > Cc: "Justin M. Streiner" , NANOG > > Subject: Re: Cleveland/Cincinnati Co-location > Message-ID: <19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1 at fastmail.fm> > Content-Type: text/plain; charset=utf-8 > > On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) < > allenmckinleykitchen at gmail.com> wrote: > > > > +1 for Expedient. Not a current customer but a VERY satisfied former > customer. (Decision to leave them was a foul case of penny-pincher > mismanagement, above my pay grade and over my objections.) > > > > ..Allen > > > >> On Jan 3, 2019, at 01:00, Justin M. Streiner > wrote: > >> > >>> On Tue, 1 Jan 2019, Mitchell Lewis wrote: > >>> > >>> I am working on project that may involve building points of presence > in Cleveland & Cincinnati. Any suggestions as to which colocation facility > in each city to build in? The prime factor of consideration for this > project is access to waves to places like Chicago, New York & Ashburn. It > would be nice to have multiple wave provider options to choose from. > >>> > >>> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in > Cleveland. > >> > >> Expedient has two facilities in Cleveland that might be worth looking > at. > >> > >> Thank you > >> jms > > I’m in Expedient’s Cleveland DC and will second that they’re decent. > > — > Shawn > > ------------------------------ > > End of NANOG Digest, Vol 132, Issue 4 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjc+nanog at pumpky.net Mon Jan 7 00:06:04 2019 From: cjc+nanog at pumpky.net (Crist Clark) Date: Sun, 6 Jan 2019 16:06:04 -0800 Subject: Cleveland/Cincinnati Co-location In-Reply-To: References: <5D377D6CCA7EBD40AD0F62E94DF49375BB60420D@MAIL23.PDMBOARDMAN.local> Message-ID: On Sun, Jan 6, 2019 at 2:52 PM Ross Tajvar wrote: > I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has >> an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, >> is on the Century Link backbone, and has a solid rubber roof with no holes >> or cooling systems on the roof.) > > > Being on the CenturyLink backbone doesn't sound like a selling point to > me... > Also, which “CenturyLink?” Given it’s a DC, old Savvis network? Or Qwest? Or Level3? Or another acquisition? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkehoe at pdmi.com Mon Jan 7 00:08:26 2019 From: dkehoe at pdmi.com (David Kehoe) Date: Mon, 7 Jan 2019 00:08:26 +0000 Subject: Cleveland/Cincinnati Co-location In-Reply-To: References: <5D377D6CCA7EBD40AD0F62E94DF49375BB60420D@MAIL23.PDMBOARDMAN.local> , Message-ID: Not sure. From what I understood it sounds like Level 3's old network. But not 100% sure. Thank you, David Kehoe | Information Security Analyst d 330.757.0724 x5208 | c 567.233.2624 | www.pdmi.com PDMI | 1170 E. Western Reserve Road | Poland, Ohio 44514 Sent from Mobile Confidentiality Notice: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. 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 message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by reply e-mail or by telephone at (330) 757-0724, and destroy the original transmission and its attachments without reading them or saving them to disk. HIPAA NOTICE: It is against PDMI's policy to receive or send un-encrypted or non-secured E-mail correspondence containing Protected Health Information (PHI) as defined by the Health Insurance Portability and Accountability Act of 1996, as amended. Any email containing PHI is encrypted and sent securely. On Sun, Jan 6, 2019 at 7:06 PM -0500, "Crist Clark" > wrote: On Sun, Jan 6, 2019 at 2:52 PM Ross Tajvar > wrote: I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, is on the Century Link backbone, and has a solid rubber roof with no holes or cooling systems on the roof.) Being on the CenturyLink backbone doesn't sound like a selling point to me... Also, which “CenturyLink?” Given it’s a DC, old Savvis network? Or Qwest? Or Level3? Or another acquisition? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Mon Jan 7 14:28:17 2019 From: alfie at fdx.services (Alfie Pates) Date: Mon, 07 Jan 2019 14:28:17 +0000 Subject: attempted archive.is hijacking In-Reply-To: References: Message-ID: <1546871297.1632925.1627711800.16A16B92@webmail.messagingengine.com> ISNIC are incredibly manual (due to their small size) - they also require that you deal with them in Icelandic for anything legal-related. I helped somebody migrate they're .is domain away from a reseller last year and it was a whole load of faff. Probably not malice, just a quirk of this one particular registrar's "meat-in-the-loop" setup. ~a From Brent.Neader at druryhotels.com Sat Jan 5 03:29:23 2019 From: Brent.Neader at druryhotels.com (Neader, Brent) Date: Sat, 5 Jan 2019 03:29:23 +0000 Subject: Changing upstream providers, opinions/thoughts on 123.net and cogent Message-ID: Looks like they already are? https://bgp.he.net/AS14374 Depending on which peer you might be replacing 123.net or cogent with, that could possibly change someone’s opinion. However, at least from past topics on this, given cogent history with peering issues (such as HE.net cake), I think one would certainly want to understand what impact peering/routing quirks would cause them and their ability to work around them before selecting cogent. Given I doubt your international reach is a big deal, and given 123.net is more of a tier2 (https://bgp.he.net/AS12129) with local and regional peering ( https://www.peeringdb.com/net/3899 ), they could be better suited for your traffic patterns and local customers? Also if you are not already interconnected with 123.net from a transport perspective, given their footprint in the state, there could be opportunities for an NNI to expand your reach to help interconnect your customer’s locations (aka customer has a branch office inside and outside your direct footprint and wants ELAN type service). I have looked at them before but never got serious, and thus cannot offer any input on their actual service or support. From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ben Cannon Sent: Friday, January 4, 2019 8:16 PM To: Aaron Henderson Cc: nanog at nanog.org Subject: EXT_Re: Changing upstream providers, opinions/thoughts on 123.net and cogent Run BGP and use multiple upstream providers as soon as you can. -Ben On Jan 4, 2019, at 4:57 AM, Aaron Henderson > wrote: I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net and Cogent. I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Thanks, A -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianh at ianh.net.au Sat Jan 5 07:16:02 2019 From: ianh at ianh.net.au (Ian Henderson) Date: Sat, 5 Jan 2019 16:16:02 +0900 Subject: Cellular backup connections In-Reply-To: References: Message-ID: On 30 Dec 2018, at 2:16 am, Mark Milhollan wrote: > > Perhaps using MOSH can help make the interactive CLI session less annoying. Haven’t looked in a couple of years, but has anybody made mosh work on OpenGear? From team at snowflakeops.ch Mon Jan 7 14:42:44 2019 From: team at snowflakeops.ch (Ops One AG | Markus Ritzmann) Date: Mon, 7 Jan 2019 15:42:44 +0100 Subject: attempted archive.is hijacking In-Reply-To: References: Message-ID: <898412a2-d5ac-e44a-187e-07ca8b6170ea@opsone.ch> On 05.01.19 23:29, Dan Hollis wrote: > or if there is something specific about isnic that allows it to happen https://twitter.com/isnic/status/1082257946631987200 -- Markus Ritzmann | DevOps Engineer Ops One AG | Birmensdorferstrasse 94 | 8003 Zürich https://opsone.ch | team at opsone.ch | 058 255 00 22 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wjhns61 at hardakers.net Mon Jan 7 16:27:51 2019 From: wjhns61 at hardakers.net (Wes Hardaker) Date: Mon, 07 Jan 2019 08:27:51 -0800 Subject: Astronaut accidently calls 911 from space In-Reply-To: (Sean Donelan's message of "Thu, 3 Jan 2019 17:45:00 -0500 (EST)") References: Message-ID: Sean Donelan writes: > I was disappointed that it was just a misdial. I was looking forward > to how IP geolocation worked with 9-1-1 calls from space. I always > wondered how that altitude parameter in 911 packets was used. :-) Response time would have been slightly longer than the average 7 minutes too... And probably the single data point would have skewed the average afterward. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://blog.capturedonearth.com/ From aaron1 at gvtc.com Tue Jan 8 14:52:40 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 8 Jan 2019 08:52:40 -0600 Subject: Changing upstream providers, opinions/thoughts on 123.net and cogent In-Reply-To: References: Message-ID: <001101d4a761$cddc7330$69955990$@gvtc.com> I’ve never heard of 123 I’ve used Cogent for several years now… Price was good 10 gig link… for a few years 20 gig (2) 10 gigs lagged… for a year or so… 100 gig link for past few months… The support is quick and easy to deal with. DDOS RTBH is nice quick and easy (but different than other SP’s with communities…. Cogent ddos rtbh is a separate bgp neighbor session)… I like it IPv6 has issues with Google and HE I think still….been years now. Attacks come as often through cogent as any of my sp’s, but probably more on cogent than others…. Telia is catching up. -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From cunha at dcc.ufmg.br Tue Jan 8 16:41:07 2019 From: cunha at dcc.ufmg.br (Italo Cunha) Date: Tue, 8 Jan 2019 11:41:07 -0500 Subject: BGP Experiment In-Reply-To: References: Message-ID: NANOG, We've performed the first announcement in this experiment yesterday, and, despite the announcement being compliant with BGP standards, FRR routers reset their sessions upon receiving it. Upon notice of the problem, we halted the experiments. The FRR developers confirmed that this issue is specific to an unintended consequence of how FRR handles the attribute 0xFF (reserved for development) we used. The FRR devs already merged a fix and notified users. We plan to resume the experiments January 16th (next Wednesday), and have updated the experiment schedule [A] accordingly. As always, we welcome your feedback. [A] https://goo.gl/nJhmx1 On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > > NANOG, > > We would like to inform you of an experiment to evaluate alternatives > for speeding up adoption of BGP route origin validation (research > paper with details [A]). > > Our plan is to announce prefix 184.164.224.0/24 with a valid > standards-compliant unassigned BGP attribute from routers operated by > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > development), and size 0x20 (256bits). > > Our collaborators recently ran an equivalent experiment with no > complaints or known issues [A], and so we do not anticipate any > arising. Back in 2010, an experiment using unassigned attributes by > RIPE and Duke University caused disruption in Internet routing due to > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > attributes have been assigned (BGPsec-path) and adopted (large > communities). We have successfully tested propagation of the > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > 1.6.3. > > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > predefined period of 15 minutes starting 14:30 GMT, from Monday to > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > locations [E]). We will stop the experiment immediately in case any > issues arise. > > Although we do not expect the experiment to cause disruption, we > welcome feedback on its safety and especially on how to make it safer. > We can be reached at disco-experiment at googlegroups.com. > > Amir Herzberg, University of Connecticut > Ethan Katz-Bassett, Columbia University > Haya Shulman, Fraunhofer SIT > Ítalo Cunha, Universidade Federal de Minas Gerais > Michael Schapira, Hebrew University of Jerusalem > Tomas Hlavacek, Fraunhofer SIT > Yossi Gilad, MIT > > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > [B] http://peering.usc.edu > [C] https://goo.gl/AFR1Cn > [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > [E] https://goo.gl/nJhmx1 From niels=nanog at bakker.net Tue Jan 8 16:48:46 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 8 Jan 2019 17:48:46 +0100 Subject: BGP Experiment In-Reply-To: References: Message-ID: <20190108164846.GA2532@jima.tpb.net> * cunha at dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]: >[A] https://goo.gl/nJhmx1 For the archives, since goo.gl will cease to exist soon, this links to https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview After seeing this initial result I'm wondering why the researchers couldn't set up their own sandbox first before breaking code on the internet. I believe FRR is a free download and comes with GNU autoconf. -- Niels. From thomasammon at gmail.com Tue Jan 8 16:58:53 2019 From: thomasammon at gmail.com (Tom Ammon) Date: Tue, 8 Jan 2019 11:58:53 -0500 Subject: BGP Experiment In-Reply-To: <20190108164846.GA2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> Message-ID: On Tue, Jan 8, 2019, 11:50 AM * cunha at dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]: > >[A] https://goo.gl/nJhmx1 > > For the archives, since goo.gl will cease to exist soon, this links to > > https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview > > After seeing this initial result I'm wondering why the researchers > couldn't set up their own sandbox first before breaking code on the > internet. I believe FRR is a free download and comes with GNU autoconf. > > > -- Niels. > There are a fair number of open source BGP implementations now. It would require additional effort to test all of them. Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathalie at ripe.net Tue Jan 8 10:40:33 2019 From: nathalie at ripe.net (Nathalie Trenaman) Date: Tue, 8 Jan 2019 11:40:33 +0100 Subject: Report on Legal Barriers to RPKI Adoption In-Reply-To: References: Message-ID: Dear all, After reading the report, I agree with Job it was well written and a must-read for everyone with an interest in RPKI, even outside the ARIN region. Well done! As RIPE NCC is maintaining validator software, I would like to comment on point 2: > 2. Developers of RPKI validation software should consider integrating acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. > > > > To put it bluntly: item 2 is not going to happen. > > We’ve discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or IRR data - and we’re not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. > > I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN’s RPA into their installation process. I concur that for the RIPE NCC Validator this is something we don’t want to implement. Having said that, we do hear from our users that the current setup, where we point users to the ARIN TAL, is not optimal to say the least. Users simply don’t understand why the other TALs automatically are installed and the ARIN TAL isn’t, so we follow the discussions in the ARIN region closely. Best regards, Nathalie Trenaman RIPE NCC > Op 6 jan. 2019, om 17:02 heeft Job Snijders het volgende geschreven: > > Dear Christopher, David, NANOG community, > > Thank you for your research and report. I found the report quite readable (not having a legal background) and well structured. Definitely edifying and worth the read! In this mail I’ll reply specifically to a few points from the executive summary (and snip the rest). > > For those of you who don’t want to create a SSRN account here is a copy of the report: > http://instituut.net/~job/SSRN-id3309813.pdf > > > On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo > wrote: > Here is a summary of our recommendations: > > On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement (“RPA”), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: > > 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. > > > > I’m happy to see suggestions that dropping the RPA is a viable path. > > In December 2018 we’ve measured that around TWENTY percent of the networks deploying RPKI based Origin Validation are missing the ARIN TAL [source: benjojo]. This is an extremely worrying number, as it means that ARIN ROAs are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the root cause for ARIN being an outliner is absence of the ARIN TAL in the common RPKI Validation softwares. The absence of the ARIN TAL in software distributions can be directly attributed to the existence of the RPA and applicable contract doctrines. > > If no changes are made to the current situation, I expect the 20% number to remain the same or even grow, effectively making ARIN’s RPKI services unsuitable for the purpose of securing routing. > > > 2. Developers of RPKI validation software should consider integrating acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. > > > > To put it bluntly: item 2 is not going to happen. > > We’ve discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or IRR data - and we’re not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. > > I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN’s RPA into their installation process. > > > 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA’s prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. > > 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. > > > > To provide context for the above two paragraphs, at this point in time it’s unclear whether BGPMon’s WHOIS, NLNOG’s IRRExplorer, and the various “RPKI to IRR” services are violating the RPA. I believe it to be highly undesirable for this uncertainty to persist, nor would it be acceptable to require each and every (potential) innovator or researcher to sign contracts with ARIN. ARIN members would be significantly worse off if these services stop using the ARIN TAL. > > Finally, ARIN members should realize that the majority of ASNs on the Internet are *outside* North America and are not ARIN members. We want *all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and misconfigurations don’t know borders. It’s not reasonable to require Dutch, Indian, Russian and Chinese networks to enter into a contractual agreement with ARIN in order to protect the ARIN members. This is why we need things to work properly out of the box, just like was done with DNSSEC. Reform is needed. > > Kind regards, > > Job > > [benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018 > [rpki-client]: https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cunha at dcc.ufmg.br Tue Jan 8 17:01:28 2019 From: cunha at dcc.ufmg.br (Italo Cunha) Date: Tue, 8 Jan 2019 12:01:28 -0500 Subject: BGP Experiment In-Reply-To: <20190108164846.GA2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> Message-ID: Hi Niels, we did run the experiment in a controlled environment with different versions of Cisco, BIRD, and Quagga routers and observed no issues. We did add FRR to the test suite yesterday for future tests. On Tue, Jan 8, 2019 at 11:49 AM wrote: > > * cunha at dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]: > >[A] https://goo.gl/nJhmx1 > > For the archives, since goo.gl will cease to exist soon, this links to > https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview > > After seeing this initial result I'm wondering why the researchers > couldn't set up their own sandbox first before breaking code on the > internet. I believe FRR is a free download and comes with GNU autoconf. > > > -- Niels. From saku at ytti.fi Tue Jan 8 17:02:58 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 8 Jan 2019 19:02:58 +0200 Subject: BGP Experiment In-Reply-To: <20190108164846.GA2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> Message-ID: Hey, > After seeing this initial result I'm wondering why the researchers > couldn't set up their own sandbox first before breaking code on the > internet. I believe FRR is a free download and comes with GNU autoconf. We probably should avoid anything which might demotivate future good guys from finding breaking bugs and reporting them, while sending perfectly standard-compliant messages. Only ones who will win are bad guys who collect libraries of how-to-break-internet. There are certainly several transit packet of deaths and BGP parser bugs in each implementation, I'd rather have good guy trigger them and give me details why my network broke, than have bad guy store them for future use. -- ++ytti From valdis.kletnieks at vt.edu Tue Jan 8 17:06:09 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 08 Jan 2019 12:06:09 -0500 Subject: BGP Experiment In-Reply-To: <20190108164846.GA2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> Message-ID: <31375.1546967169@turing-police.cc.vt.edu> On Tue, 08 Jan 2019 17:48:46 +0100, niels=nanog at bakker.net said: > After seeing this initial result I'm wondering why the researchers > couldn't set up their own sandbox first before breaking code on the > internet. I believe FRR is a free download and comes with GNU autoconf. Perhaps you'd like to supply the researchers (and us) with a *complete* list of all BGP-speaking software in use on the Internet? (Personally, I'd never heard of FRR before) From nick at foobar.org Tue Jan 8 17:07:48 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 8 Jan 2019 17:07:48 +0000 Subject: BGP Experiment In-Reply-To: <20190108164846.GA2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> Message-ID: <6181d1a7-bdf1-ca83-6239-5640a59bebe0@foobar.org> niels=nanog at bakker.net wrote on 08/01/2019 16:48: > After seeing this initial result I'm wondering why the researchers > couldn't set up their own sandbox first before breaking code on the > internet.  I believe FRR is a free download and comes with GNU autoconf. the researchers didn't break code - their test unearthed broken code. That code has now been fixed, so this is a good result. Nick From niels=nanog at bakker.net Tue Jan 8 17:10:45 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 8 Jan 2019 18:10:45 +0100 Subject: BGP Experiment In-Reply-To: References: <20190108164846.GA2532@jima.tpb.net> Message-ID: <20190108171045.GB2532@jima.tpb.net> * thomasammon at gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]: >There are a fair number of open source BGP implementations now. It >would require additional effort to test all of them. In the real world, doing the correct thing is often harder than doing an incorrect thing, yes. -- Niels. From niels=nanog at bakker.net Tue Jan 8 17:15:37 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 8 Jan 2019 18:15:37 +0100 Subject: BGP Experiment In-Reply-To: <31375.1546967169@turing-police.cc.vt.edu> References: <20190108164846.GA2532@jima.tpb.net> <31375.1546967169@turing-police.cc.vt.edu> Message-ID: <20190108171537.GB2511@jima.tpb.net> * valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) [Tue 08 Jan 2019, 18:06 CET]: > (Personally, I'd never heard of FRR before) Martin Winter of OSR/FRR has attended many a NANOG, RIPE and other industry meetings, so it's not for their lack of trying -- Niels. From job at ntt.net Tue Jan 8 17:16:03 2019 From: job at ntt.net (Job Snijders) Date: Tue, 8 Jan 2019 20:16:03 +0300 Subject: BGP Experiment In-Reply-To: References: <20190108164846.GA2532@jima.tpb.net> Message-ID: OOn Tue, Jan 8, 2019 at 19:59 Tom Ammon wrote: > On Tue, Jan 8, 2019, 11:50 AM >> * cunha at dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]: >> >[A] https://goo.gl/nJhmx1 >> >> For the archives, since goo.gl will cease to exist soon, this links to >> >> https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview >> >> After seeing this initial result I'm wondering why the researchers >> couldn't set up their own sandbox first before breaking code on the >> internet. I believe FRR is a free download and comes with GNU autoconf. >> > > There are a fair number of open source BGP implementations now. It would > require additional effort to test all of them. > Not just every implementation, but also every version, and every configuration permutation. This type of black box testing is not scalable. It is not feasible work, nor the job of these researchers. It’s the job of the software the developer to ensure the product is standards compliant. In the case of FRR: - improper use of the 0xFF codepoint - FRR is not compliant with RFC 7606 (the devs indicated they will be working on this) Ultimately, the developers are responsible for their product, not random other internet users. This situation was avoidable if standards had been followed. I’m happy the FRR developers quickly identified the issue and published a fix. We can now all move on. Kind regards, Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Jan 8 17:16:45 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 8 Jan 2019 12:16:45 -0500 Subject: BGP Experiment In-Reply-To: <31375.1546967169@turing-police.cc.vt.edu> References: <20190108164846.GA2532@jima.tpb.net> <31375.1546967169@turing-police.cc.vt.edu> Message-ID: <4AC0EE8F-36B7-48AF-9243-AD9D8598D6FA@puck.nether.net> > On Jan 8, 2019, at 12:06 PM, valdis.kletnieks at vt.edu wrote: > > On Tue, 08 Jan 2019 17:48:46 +0100, niels=nanog at bakker.net said: > >> After seeing this initial result I'm wondering why the researchers >> couldn't set up their own sandbox first before breaking code on the >> internet. I believe FRR is a free download and comes with GNU autoconf. > > Perhaps you'd like to supply the researchers (and us) with a *complete* > list of all BGP-speaking software in use on the Internet? (Personally, I'd > never heard of FRR before) Yeah, I think it also gets complicated as some of us also have our own internal BGP speakers as well. Taking MRT files from route-views or RIPE RIS and replaying them is certainly helpful to simulate certain events. I’ve found a lot of interesting “new attribute” experiments when I had a poorly written MRT parser that would trigger periodically when something new hit the internet. (FRR is descendent of Zebra/Quagga world) - Jared From niels=nanog at bakker.net Tue Jan 8 17:17:21 2019 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Tue, 8 Jan 2019 18:17:21 +0100 Subject: BGP Experiment In-Reply-To: References: <20190108164846.GA2532@jima.tpb.net> Message-ID: <20190108171721.GC2532@jima.tpb.net> Hi Saku, >>After seeing this initial result I'm wondering why the researchers >>couldn't set up their own sandbox first before breaking code on the >>internet. I believe FRR is a free download and comes with GNU autoconf. > >We probably should avoid anything which might demotivate future good >guys from finding breaking bugs and reporting them, while sending >perfectly standard-compliant messages. Only ones who will win are bad >guys who collect libraries of how-to-break-internet. >There are certainly several transit packet of deaths and BGP parser >bugs in each implementation, I'd rather have good guy trigger them and >give me details why my network broke, than have bad guy store them for >future use. I fully agree with you. However, this doesn't give 'good guys' carte blanche to break stuff. I'm glad they've already taken action to improve their practices as confirmed by Italo Cunha in his earlier mail. -- Niels. From jared at puck.nether.net Tue Jan 8 17:20:32 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 8 Jan 2019 12:20:32 -0500 Subject: BGP Experiment In-Reply-To: <20190108171045.GB2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> <20190108171045.GB2532@jima.tpb.net> Message-ID: > On Jan 8, 2019, at 12:10 PM, niels=nanog at bakker.net wrote: > > * thomasammon at gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]: >> There are a fair number of open source BGP implementations now. It would require additional effort to test all of them. > > In the real world, doing the correct thing is often harder than doing an incorrect thing, yes. > And other times you just get BGP as art https://twitter.com/powerdns_bert/status/878291436034170881 - jared From ximaera at gmail.com Tue Jan 8 17:31:12 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 8 Jan 2019 20:31:12 +0300 Subject: BGP Experiment In-Reply-To: <20190108171045.GB2532@jima.tpb.net> References: <20190108164846.GA2532@jima.tpb.net> <20190108171045.GB2532@jima.tpb.net> Message-ID: 8 Jan. 2019 г., 20:19 : > In the real world, doing the correct thing — such as writing RFC compliant code — > is often harder than doing > an incorrect thing, yes. Evidently, yes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From snoble at sonn.com Tue Jan 8 18:42:21 2019 From: snoble at sonn.com (Steve Noble) Date: Tue, 8 Jan 2019 10:42:21 -0800 Subject: BGP Experiment In-Reply-To: References: <20190108164846.GA2532@jima.tpb.net> <20190108171045.GB2532@jima.tpb.net> Message-ID: There is no such thing as a fully RFC compliant BGP : https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/bgp.html does not list 7606 Cisco Bug: CSCvf06327 - Error Handling for RFC 7606 not implemented for NXOS This is as of today and a 2 second google search.. anyone running code from before RFC 7606 (2015) would also not be compliant. I did not see Juniper on the list of BGP speakers tested. Töma Gavrichenkov wrote on 1/8/19 9:31 AM: > 8 Jan. 2019 г., 20:19 >: > > In the real world, doing the correct thing > > — such as writing RFC compliant code — > > > is often harder than doing > > an incorrect thing, yes. > > Evidently, yes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Jan 8 19:54:18 2019 From: randy at psg.com (Randy Bush) Date: Tue, 08 Jan 2019 11:54:18 -0800 Subject: BGP Experiment In-Reply-To: References: Message-ID: > We plan to resume the experiments January 16th (next Wednesday), and > have updated the experiment schedule [A] accordingly. As always, we > welcome your feedback. i did not realize that frr updates propagated so quickly. very cool. randy From list at satchell.net Tue Jan 8 21:12:33 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 8 Jan 2019 13:12:33 -0800 Subject: BGP Experiment In-Reply-To: References: <20190108164846.GA2532@jima.tpb.net> <20190108171045.GB2532@jima.tpb.net> Message-ID: <06a08a8b-606a-a268-c488-f6df0a28556c@satchell.net> On 1/8/19 9:31 AM, Töma Gavrichenkov wrote: > 8 Jan. 2019 г., 20:19 : >> In the real world, doing the correct thing > > — such as writing RFC compliant code — > >> is often harder than doing >> an incorrect thing, yes. > > Evidently, yes. I "grew up" during the early days of PPP. As a member of the press I attended an "inter-op" session at Telebit's campus, and watched as a collection of engineers and programmers matched up implementations of PPP and found bugs in both the Proposed Standard and in the implementations thereof. Watching these guys with all sorts of data monitors trying to figure out who goofed was an interesting and fascinating experience. During my stint with the Telecommunications Industry Associate TR-30 committee hashing out modem standards like V.32 et al and V.25 ter was a similar exercise -- one that lead to me being in a near fight in a parking lot in San Jose with a Microsoft enginner over clarity problems with the proposed Standard for side-channel protocol. "Can you do better?" "Yes." "Prove it." And I did. My proposal was accepted by all, even the Microsoft guy. (We continued to collaborate until he cashed out of the company.) From adamv0025 at netconsultings.com Tue Jan 8 22:42:35 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Tue, 8 Jan 2019 22:42:35 -0000 Subject: BGP Experiment In-Reply-To: <002f01d4a7a0$e9350900$bb9f1b00$@netconsultings.com> References: <20190108164846.GA2532@jima.tpb.net> <20190108171045.GB2532@jima.tpb.net> <002f01d4a7a0$e9350900$bb9f1b00$@netconsultings.com> Message-ID: <003301d4a7a3$73503090$59f091b0$@netconsultings.com> > Steve Noble > Sent: Tuesday, January 8, 2019 6:42 PM > > There is no such thing as a fully RFC compliant BGP : > Which RFC do you mean 6286, 6608, 6793, 7606, 7607, 7705 or 8212 when you say fully RFC compliant BGP please? > https://www.juniper.net/documentation/en_US/junos/topics/reference/st > andards/bgp.html does not list 7606 > > Cisco Bug: CSCvf06327 - Error Handling for RFC 7606 not implemented for > NXOS > > This is as of today and a 2 second google search.. anyone running code from > before RFC 7606 (2015) would also not be compliant. > With regards to Revised Error Handling for BGP UPDATE Messages RFC 7606, My recollection is there was a very long discussion with working code preceding the various drafts as well as the final RFC standard. Regarding the Juniper case specifically a bit of googling reveals that: All Junos software releases built on or after 2009-06-29 have been enhanced to be more tolerant of malformed optional, transitive attributes. Releases containing the coding change specifically include: 9.1S2, 9.3R3, 9.6R1 and all subsequent releases (i.e. all releases built after 9.6R1). -so it's not quite black and white, there will be levels of protection available in current releases (albeit not fully compliant with RFC per se). Question is whether folks out there have it actually enabled. Oh and then there are bugs associated with the new feature (like the one in some versions of Junos which ,upon receiving malformed update won't bring the session down but rather the whole rpd if the bgp-error-tolerance feature is enabled ) adam From eric.kuhnke at gmail.com Wed Jan 9 04:56:28 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 8 Jan 2019 20:56:28 -0800 Subject: BGP Experiment In-Reply-To: References: Message-ID: FRR is undergoing a fairly rapid pace of development, thanks to the cloud-scale operators and hosting providers which are using it in production. https://cumulusnetworks.com/blog/welcoming-frrouting-to-the-linux-foundation/ On Tue, Jan 8, 2019 at 11:55 AM Randy Bush wrote: > > We plan to resume the experiments January 16th (next Wednesday), and > > have updated the experiment schedule [A] accordingly. As always, we > > welcome your feedback. > > i did not realize that frr updates propagated so quickly. very cool. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Jan 9 06:54:46 2019 From: randy at psg.com (Randy Bush) Date: Tue, 08 Jan 2019 22:54:46 -0800 Subject: BGP Experiment In-Reply-To: References: Message-ID: >>> We plan to resume the experiments January 16th (next Wednesday), and >>> have updated the experiment schedule [A] accordingly. As always, we >>> welcome your feedback. >> i did not realize that frr updates propagated so quickly. very cool. > > FRR is undergoing a fairly rapid pace of development that is impressive but irrelevant. the question is how soon the frr users out on the internet will upgrade. there are a lot of studies on this. it sure isn't on the order of a week. randy From job at instituut.net Wed Jan 9 06:59:12 2019 From: job at instituut.net (Job Snijders) Date: Wed, 9 Jan 2019 09:59:12 +0300 Subject: BGP Experiment In-Reply-To: References: Message-ID: On Wed, Jan 9, 2019 at 9:55 Randy Bush wrote: > >>> We plan to resume the experiments January 16th (next Wednesday), and > >>> have updated the experiment schedule [A] accordingly. As always, we > >>> welcome your feedback. > >> i did not realize that frr updates propagated so quickly. very cool. > > > > FRR is undergoing a fairly rapid pace of development > > that is impressive but irrelevant. the question is how soon the frr > users out on the internet will upgrade. there are a lot of studies on > this. it sure isn't on the order of a week. Given the severity of the bug, there is a strong incentive for people to upgrade ASAP. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Jan 9 07:34:35 2019 From: tore at fud.no (Tore Anderson) Date: Wed, 9 Jan 2019 08:34:35 +0100 Subject: BGP Experiment In-Reply-To: References: Message-ID: <7c6946a9-097e-9c30-0c8b-d55d53768dc0@fud.no> * Job Snijders > Given the severity of the bug, there is a strong incentive for people to upgrade ASAP. The buggy code path can also be disabled without upgrading, by building FRR with the --disable-bgp-vnc configure option, as I understand it. I've been told that this is the default in Cumulus Linux. Tore From owen at delong.com Wed Jan 9 17:27:29 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Jan 2019 09:27:29 -0800 Subject: BGP Experiment In-Reply-To: <31375.1546967169@turing-police.cc.vt.edu> References: <20190108164846.GA2532@jima.tpb.net> <31375.1546967169@turing-police.cc.vt.edu> Message-ID: <335BBCE4-974F-49A8-B84E-18C0FA155FE8@delong.com> > On Jan 8, 2019, at 09:06 , valdis.kletnieks at vt.edu wrote: > > On Tue, 08 Jan 2019 17:48:46 +0100, niels=nanog at bakker.net said: > >> After seeing this initial result I'm wondering why the researchers >> couldn't set up their own sandbox first before breaking code on the >> internet. I believe FRR is a free download and comes with GNU autoconf. > > Perhaps you'd like to supply the researchers (and us) with a *complete* > list of all BGP-speaking software in use on the Internet? (Personally, I'd > never heard of FRR before) +1 From ximaera at gmail.com Wed Jan 9 17:51:47 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 20:51:47 +0300 Subject: BGP Experiment In-Reply-To: References: Message-ID: 9 Jan. 2019 г., 9:56 Randy Bush : > the question is how soon the frr > users out on the internet will upgrade. > there are a lot of studies on > this. it sure isn't on the order of a week Which is, as usual, a pity, because, generally, synchronizing a piece of software with upstream security updates less frequently than once to twice in a week belongs in Jurassic Park today; and doing it hardly more frequently than once in 6 months, as ISPs usually do, clearly belongs in a bughouse. (wonder if this FRR update has got a CVE number though) -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Wed Jan 9 18:06:50 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2019 20:06:50 +0200 Subject: BGP Experiment In-Reply-To: References: Message-ID: On Wed, 9 Jan 2019 at 19:54, Töma Gavrichenkov wrote: > Which is, as usual, a pity, because, generally, synchronizing a piece of software with upstream security updates less frequently than once to twice in a week belongs in Jurassic Park today; and doing it hardly more frequently than once in 6 months, as ISPs usually do, clearly belongs in a bughouse. Not disputing bug or bog house as ideal location for said policy, just want to explain my perspective why it is so. SPs are making their reasonable effort to produce product that customers want to buy. Hitless upgrades are not really a thing yet, even though they've been marketed for 20 years now. Customers have expectation on how often their link flaps which is mutually exclusive with rapid upgrade cycles. And mostly all this is for show, the code is very broken, all of it. And the configurations are very broken, all of them. We regularly break Internet without trying, BGP parsing crashes are like bi-annual thing. I'm holding, without any motivation or attempt to do so, transit -packet-of-death for JNPR applicable to ~all JNPR backbones, and JNPR isn't outlier here. People happily deploy new devices which cannot be protected against even trivial (<10Mbps) control-plane attacks. Only reason things work as well as they do, is because bad guys are not trying to DoS the infrastructure with BGP or packet-of-deaths, it would be very cheap if someone should be so motivated. If this is something we think should be fixed, then we should have good guys intentionally fuzzing _public internet_ BGP and transit-packet-of-deaths with good reporting. But likely it doesn't actually matter at all that the configurations and implementations are fragile, if they are abused, Internet will fix those in no more than days, and trying to guarantee it cannot happen probably is fools errant If anything, I suspect if it's cheaper to enter the market with inferior security and quality then that is likely good business case, internet works so well, consumers are not willing to pay more for better, but would gladly sacrifice uptime for cheaper price. -- ++ytti From spoofer-info at caida.org Tue Jan 8 18:00:05 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Tue, 8 Jan 2019 10:00:05 -0800 Subject: Spoofer Report for NANOG for Dec 2018 Message-ID: <201901081800.x08I05ZP045289@fro.caida.org> 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 Dec 2018: ASN Name Fixed-By 393422 NEWVISIONS-CNY 2018-12-10 20009 WADSNET 2018-12-11 7922 COMCAST-7922 2018-12-14 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Dec 2018: ASN Name First-Spoofed Last-Spoofed 40065 CNServersLLC 2016-05-01 2018-12-22 7029 WINDSTREAM 2016-06-21 2018-12-14 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-12-27 6128 CABLE-NET-1 2016-09-03 2018-12-22 20412 CLARITY-TELECOM 2016-09-30 2018-12-26 6181 FUSE-NET 2016-10-10 2018-12-27 15305 SYRINGANETWORKS 2016-10-21 2018-12-15 25787 ROWE-NETWORKS 2016-10-21 2018-12-28 174 COGENT-174 2016-10-21 2018-12-20 31857 PRIORITY-TERABIT 2016-10-25 2018-12-28 30341 SCTA-ASN 2016-10-31 2018-12-31 32440 LONI 2016-11-03 2018-12-20 33182 DimeNOC 2016-11-08 2018-12-28 12083 WOW-INTERNET 2016-11-09 2018-12-31 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2018-12-25 3549 LVLT-3549 2016-11-16 2018-12-13 21832 KELLINCOM-1 2017-02-03 2018-12-27 7122 MTS-ASN 2017-05-16 2018-12-24 701 UUNET 2017-06-14 2018-12-09 6461 ZAYO-6461 2017-06-21 2018-12-14 63296 AMARILLO-WIRELESS 2017-09-01 2018-12-26 7233 YAHOO-US 2017-09-07 2018-12-21 33523 ROWANUNIVERSITY 2017-10-29 2018-12-17 546 PARSONS-PGS-1 2017-11-20 2018-12-19 12222 AKAMAI 2018-02-14 2018-12-30 29384 Qatar-Foundation 2018-03-08 2018-12-26 23148 TERRENAP 2018-03-15 2018-12-26 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2018-12-26 4201 ORST 2018-04-19 2018-12-27 11827 WSU 2018-04-19 2018-12-28 35911 BNQ-1 2018-06-06 2018-12-18 225 VIRGINIA 2018-06-18 2018-12-19 2381 WISCNET1 2018-09-04 2018-12-26 54804 CSMIII-BUNKIELA 2018-09-15 2018-12-30 33452 RW 2018-09-19 2018-12-27 20448 VPNTRANET-LLC 2018-09-20 2018-12-26 11215 LOGIXCOMM 2018-09-20 2018-12-13 11996 LOBOIS 2018-09-24 2018-12-27 19919 VSW 2018-10-23 2018-12-13 13825 TROYCABLE-NET 2018-11-21 2018-12-22 6453 AS6453 2018-12-11 2018-12-20 62957 HOSPITALITY-NETWORK 2018-12-30 2018-12-30 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=1 Please send any feedback or suggestions to spoofer-info at caida.org From blake.mckeeby at gmail.com Tue Jan 8 20:43:27 2019 From: blake.mckeeby at gmail.com (Blake Mckeeby) Date: Tue, 8 Jan 2019 15:43:27 -0500 Subject: DNS Hijacking? - FiOS Northeast Message-ID: We are seeing DNS requests for A and AAAA to 8.8.8.8 come back with erroneous replies resolving to 146.112.61.106 when sent via FiOS circuits in the northeast. Anyone else seeing issues with DNS on FiOS in Northeast? Issue started around 12:25 AM ET this morning and seems to be affecting customers in PA, RI, etc.. -- Sincerely, Blake McKeeby -------------- next part -------------- An HTML attachment was scrubbed... URL: From benm at workonline.africa Wed Jan 9 09:29:21 2019 From: benm at workonline.africa (Ben Maddison) Date: Wed, 9 Jan 2019 09:29:21 +0000 Subject: Report on Legal Barriers to RPKI Adoption In-Reply-To: References: , Message-ID: Hi all, Thanks Christopher and co-authors for this document. The issues that you have highlighted are critical to ensuring that SOV and other future applications of the RPKI can be deployed in production without becoming serious latent risk to the Internet community and RIR system. As a case in point with respect to your recommendations regarding the RPA, we, AS37271, have announced that we will implement strict SOV (i.e. dropping Invalids) as of 1 April 2019. As things stand today, we will not be making use of the ARIN TAL. We have arrived at this decision primarily because we are not willing to be bound by the indemnification clause (paragraph 7) of the RPA. In our assessment, the potential (and unbounded) liability that we could be exposed to under that clause presents a substantial business risk, and that it is inappropriate given the nature of the service and the role of an RIR in providing authoritative data on the allocation of number resources. I believe problems also exist in other sections of the RPA, and my strong preference would be for ARIN to dispense with it altogether. However, if paragraph 7 were to be removed, we would likely be inclined towards accepting it. Since the RPA imposes substantial obligations and risks on the relying party, I also believe that putting convenience methods (such as click-through acceptance during install of RP software packages) in place will simply encourage users to agree to accept those risks without fully understanding them, thus storing up unintended legal risks for Internet operators in the future. I therefore welcome Job and Nathalie's assertions that there is little interest in the community of RP software developers to implement these "features". This mail is already plenty long enough, but I am happy to discuss in more detail, either on- or off-list, if others are interested. Cheers, Ben Maddison Director Workonline Communications (Pty) Ltd ________________________________________ From: NANOG on behalf of Nathalie Trenaman Sent: 08 January 2019 12:40:33 To: Job Snijders Cc: David Wishnick; Christopher S. Yoo; nanog at nanog.org Subject: Re: Report on Legal Barriers to RPKI Adoption Dear all, After reading the report, I agree with Job it was well written and a must-read for everyone with an interest in RPKI, even outside the ARIN region. Well done! As RIPE NCC is maintaining validator software, I would like to comment on point 2: 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. To put it bluntly: item 2 is not going to happen. We've discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data - and we're not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN's RPA into their installation process. I concur that for the RIPE NCC Validator this is something we don't want to implement. Having said that, we do hear from our users that the current setup, where we point users to the ARIN TAL, is not optimal to say the least. Users simply don't understand why the other TALs automatically are installed and the ARIN TAL isn't, so we follow the discussions in the ARIN region closely. Best regards, Nathalie Trenaman RIPE NCC Op 6 jan. 2019, om 17:02 heeft Job Snijders > het volgende geschreven: Dear Christopher, David, NANOG community, Thank you for your research and report. I found the report quite readable (not having a legal background) and well structured. Definitely edifying and worth the read! In this mail I'll reply specifically to a few points from the executive summary (and snip the rest). For those of you who don't want to create a SSRN account here is a copy of the report: http://instituut.net/~job/SSRN-id3309813.pdf On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo > wrote: Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. I'm happy to see suggestions that dropping the RPA is a viable path. In December 2018 we've measured that around TWENTY percent of the networks deploying RPKI based Origin Validation are missing the ARIN TAL [source: benjojo]. This is an extremely worrying number, as it means that ARIN ROAs are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the root cause for ARIN being an outliner is absence of the ARIN TAL in the common RPKI Validation softwares. The absence of the ARIN TAL in software distributions can be directly attributed to the existence of the RPA and applicable contract doctrines. If no changes are made to the current situation, I expect the 20% number to remain the same or even grow, effectively making ARIN's RPKI services unsuitable for the purpose of securing routing. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. To put it bluntly: item 2 is not going to happen. We've discussed this extensively in the OpenBSD community (who are working on a new RPKI Validation implementation [source: rpki-client]), and concluded that collecting explicit consent to the RPA on behalf of ARIN is undesirable and without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data - and we're not going to make an exception for ARIN and encumber each and every OpenBSD or rpki-client(1) installation. I checked the temperature in the room of the other relevant RPKI Validation implementations, and it appears that *nobody* is planning to integrate acceptance of ARIN's RPA into their installation process. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. To provide context for the above two paragraphs, at this point in time it's unclear whether BGPMon's WHOIS, NLNOG's IRRExplorer, and the various "RPKI to IRR" services are violating the RPA. I believe it to be highly undesirable for this uncertainty to persist, nor would it be acceptable to require each and every (potential) innovator or researcher to sign contracts with ARIN. ARIN members would be significantly worse off if these services stop using the ARIN TAL. Finally, ARIN members should realize that the majority of ASNs on the Internet are *outside* North America and are not ARIN members. We want *all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and misconfigurations don't know borders. It's not reasonable to require Dutch, Indian, Russian and Chinese networks to enter into a contractual agreement with ARIN in order to protect the ARIN members. This is why we need things to work properly out of the box, just like was done with DNSSEC. Reform is needed. Kind regards, Job [benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018 [rpki-client]: https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65 From ximaera at gmail.com Wed Jan 9 18:24:25 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 21:24:25 +0300 Subject: BGP Experiment In-Reply-To: References: Message-ID: On Wed, Jan 9, 2019 at 9:07 PM Saku Ytti wrote: > Not disputing bug or bog house as ideal location for said policy, just > want to explain my perspective why it is so. So, network device vendors releasing security advisories twice a year isn't a big part of the explanation? > Hitless upgrades are not really a thing yet, even though they've been > marketed for 20 years now. This is correct; on the flip side, hitless vulnerabilities haven't even been marketed, much less invented. > Only reason things work as well as they do, is because bad > guys are not trying to DoS the infrastructure with BGP or > packet-of-deaths Err... don't they? My experience is quite the opposite. > If this is something we think should be fixed, then we should have > good guys intentionally fuzzing _public internet_ BGP and > transit-packet-of-deaths with good reporting. If we could be sure that after such fuzzing there would still be a working transport infrastructure to report on top of, then yes. > if they are abused, Internet will fix those in no more than > days — just like we did with IoT in 2016 — > and trying to guarantee it cannot happen probably is fools > errant > If anything, I suspect if it's cheaper to enter the market with > inferior security and quality then that is likely good business case This is also correct so far. I wonder if it's here to stay. -- Töma From phil.lavin at cloudcall.com Wed Jan 9 18:30:19 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 9 Jan 2019 18:30:19 +0000 Subject: DNS Hijacking? - FiOS Northeast In-Reply-To: References: Message-ID: > We are seeing DNS requests for A and AAAA to 8.8.8.8 come back with erroneous replies resolving to 146.112.61.106 when sent via FiOS circuits in the northeast. Anyone else seeing issues with DNS on FiOS in Northeast? Issue started around 12:25 AM ET this morning and seems to be affecting customers in PA, RI, etc..  146.112.61.106 appears to be an Anycast IP served by OpenDNS when pages are blocked by the Cisco Umbrella service - https://support.opendns.com/hc/en-us/articles/227986927-What-are-the-Cisco-Umbrella-Block-Page-IP-Addresses- Are you sure the queries are going to Google 8.8.8.8 and not OpenDNS? What URL(s) are you seeing this on? Do you have a traceroute to 8.8.8.8 from an affected site? From CKimball at misalliance.com Wed Jan 9 18:31:07 2019 From: CKimball at misalliance.com (Chris Kimball) Date: Wed, 9 Jan 2019 18:31:07 +0000 Subject: DNS Hijacking? - FiOS Northeast In-Reply-To: References: Message-ID: FWIW Looks to be OpenDNS IP https://support.opendns.com/hc/en-us/articles/227986927-What-are-the-Cisco-Umbrella-Block-Page-IP-Addresses- It’s being abused… https://www.abuseipdb.com/check/146.112.61.106 From: NANOG On Behalf Of Blake Mckeeby Sent: Tuesday, January 8, 2019 3:43 PM To: nanog at nanog.org Subject: DNS Hijacking? - FiOS Northeast We are seeing DNS requests for A and AAAA to 8.8.8.8 come back with erroneous replies resolving to 146.112.61.106 when sent via FiOS circuits in the northeast. Anyone else seeing issues with DNS on FiOS in Northeast? Issue started around 12:25 AM ET this morning and seems to be affecting customers in PA, RI, etc.. -- Sincerely, Blake McKeeby - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jan 9 18:31:48 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Jan 2019 10:31:48 -0800 Subject: BGP Experiment In-Reply-To: References: Message-ID: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> > On Jan 9, 2019, at 09:51 , Töma Gavrichenkov wrote: > > 9 Jan. 2019 г., 9:56 Randy Bush >: > > the question is how soon the frr > > users out on the internet will upgrade. > > there are a lot of studies on > > this. it sure isn't on the order of a week > > Which is, as usual, a pity, because, generally, synchronizing a piece of software with upstream security updates less frequently than once to twice in a week belongs in Jurassic Park today; and doing it hardly more frequently than once in 6 months, as ISPs usually do, clearly belongs in a bughouse. > > (wonder if this FRR update has got a CVE number though) So if I understand you correctly, your statement is that everyone should be (potentially) rebooting every core, backbone, edge, and other router at least once or twice a week… To quote Randy Bush… I encourage my competitors to try this. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Wed Jan 9 18:32:29 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2019 20:32:29 +0200 Subject: BGP Experiment In-Reply-To: References: Message-ID: On Wed, 9 Jan 2019 at 20:24, Töma Gavrichenkov wrote: > So, network device vendors releasing security advisories twice a year > isn't a big part of the explanation? Those are scheduled, they have to meet some criteria to be pushed on scheduled lot. There are also out of cycle SIRTs. And yes, vendors are delaying them, because customers don't want to upgrade often, because customer's customers don't want to see connections down often. > Err... don't they? My experience is quite the opposite. Well that is odd experience, considering anyone with rudimentary understanding of control-plane policing can bring internet down from single VPS. Majority of deployed devices _cannot_ be protected against DoS motivated attacker, and I'm not talking link congestion, I'm talking control-plane congestion with few Mbps. > If we could be sure that after such fuzzing there would still be a > working transport infrastructure to report on top of, then yes. If it's important to get right, we should try to prove it wrong actively and persistently by good guys, at least then reporting and statistics can be produced. But I'm not sure if it's important to get right, market seems to indicate security does not matter. > — just like we did with IoT in 2016 — Internet still running, I'm still getting paid. > > If anything, I suspect if it's cheaper to enter the market with > > inferior security and quality then that is likely good business case > > This is also correct so far. I wonder if it's here to stay. We'd need the current security posture to be sufficiently unmarketable. But motivation to simply DoS internet doesn't really exist. DoS is against service end points, infrastucture is trivial target, but for some reason not really targeted. I'm sure state actors have library of DoS transit packets and BGP UPDATE packets to be deployed when strategy requires given network or region to be disrupted. Because, we, the internet plumbers, keep finding those without trying, just trying to keep the network working, what can someone find who is funded and motivated to find those? -- ++ytti From ximaera at gmail.com Wed Jan 9 18:37:36 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 21:37:36 +0300 Subject: BGP Experiment In-Reply-To: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: On Wed, Jan 9, 2019 at 9:31 PM Owen DeLong wrote: > So if I understand you correctly, your statement is that everyone > should be (potentially) rebooting every core, backbone, edge, > and other router at least once or twice a week… Nope, this is a misunderstanding. One has to *check* for advisories at least once or twice a week and only update (and reboot is necessary) if there *is* a vulnerability. Checking is quite different from, actually, updating. What you may want to encourage your competition to do is to deploy a piece of software which actually *gets* a severe CVE twice in a week; that will certainly bring you a bunch of new customers. -- Töma From James at arenalgroup.co Wed Jan 9 18:48:25 2019 From: James at arenalgroup.co (James Breeden) Date: Wed, 9 Jan 2019 18:48:25 +0000 Subject: Centurylink/Level3 WDM? Message-ID: Anyone else having issues with Centurylink IP (Legacy Level3/3356) in/around Houston, or WDM issues between Houston and San Antonio? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Jan 9 18:50:15 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 21:50:15 +0300 Subject: BGP Experiment In-Reply-To: References: Message-ID: On Wed, Jan 9, 2019 at 9:32 PM Saku Ytti wrote: > Those are scheduled, they have to meet some criteria to be pushed on > scheduled lot. There are also out of cycle SIRTs. And yes, vendors are > delaying them, because customers don't want to upgrade often, because > customer's customers don't want to see connections down often. Yep. The same happened before e.g. to MSFT products and Adobe Flash for a decade before the former have started to update in days no matter what, and before the latter was effectively pushed out of most market niches. >> — just like we did with IoT in 2016 — > Internet still running, I'm still getting paid. Well, I know a couple of guys who aren't. > But motivation to simply DoS internet doesn't really > exist. Except for hacktivism, fun, gathering a rep within a cracker society, gathering a rep within one's middle school community, et cetera. But anyway, > DoS is against service end points, infrastucture is trivial > target, but for some reason not really targeted. It really is. ISPs don't get that quite frequently for now, but end-user network services sometimes do. > I'm sure state actors have library of DoS transit packets and > BGP UPDATE packets to be deployed when strategy requires > given network or region to be > disrupted. There's hardly a reason to rely on your next door neighbor's kid not chatting on the same Darknet forums where those "state actors" get their data from. "State actor" thing is highly overrated today. They are certainly powerful but hardly more powerful than a skilled team of anonymous blackhat researchers going in for ransom money. -- Töma From saku at ytti.fi Wed Jan 9 18:51:25 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2019 20:51:25 +0200 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: On Wed, 9 Jan 2019 at 20:45, Töma Gavrichenkov wrote: > Nope, this is a misunderstanding. One has to *check* for advisories at > least once or twice a week and only update (and reboot is necessary) > if there *is* a vulnerability. I think this contains some assumptions 1. discovering security issues in network devices is expensive (and thus only those you glean from vendor notices realistically exist) 2. downside of being affected by network device security issue is expensive I'm very skeptical if either are true. I think it's very cheap to find security issues in network devices, particularly DoS issues. And I don't think downside is expensive, maybe it's bad 4h and lot of angry customers, but ultimately not that expensive. I think lot of this is self-organising with delay around rules and justifications no one understands, and we're not upgrading often, because it's not (currently) sensible approach. -- ++ytti From ximaera at gmail.com Wed Jan 9 18:58:23 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 21:58:23 +0300 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: On Wed, Jan 9, 2019 at 9:51 PM Saku Ytti wrote: > I think this contains some assumptions > > 1. discovering security issues in network devices is expensive (and > thus only those you glean from vendor notices realistically exist) > 2. downside of being affected by network device security issue is expensive > > I'm very skeptical if either are true. Well, it's significantly harder to look for vulns in closed source firmware which only runs on certain expensive devices. My point is that e.g. FRR is an open source software which is designed to run on the same Intel-based systems as the one which probably powers your laptop. I've received a note from FRR devs stating that they're going to get a CVE number soon. It's a good sign, though it should have happened a bit before roughly a thousand of this mailing list subscribers have been informed about the issue, but anyway. -- Töma From saku at ytti.fi Wed Jan 9 19:03:35 2019 From: saku at ytti.fi (Saku Ytti) Date: Wed, 9 Jan 2019 21:03:35 +0200 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: Hey, > firmware which only runs on certain expensive devices. My point is > that e.g. FRR is an open source software which is designed to run on > the same Intel-based systems as the one which probably powers your > laptop. Most vendors have virtual image for your laptop, all of the modern routers run Linux and some vendor binary blob, with exception of Nokia running their own bootingOS (forked off of vxworks ages ago). Finding control-plane bugs, like BGP UPDATE crash is cheap for hobbyist, you can download the images off the Internet and run on your laptop. Finding forwarding issues indeed is harder due to the limited access to devices, so bit of security through obscurity I guess. -- ++ytti From ximaera at gmail.com Wed Jan 9 19:07:56 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 22:07:56 +0300 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: On Wed, Jan 9, 2019 at 10:03 PM Saku Ytti wrote: > Finding forwarding issues indeed is harder due to the limited access > to devices, so bit of security through obscurity I guess. Or, rather, security by complexity. Today's network infrastructure is complex enough for people to dive into it, looking for all the underlying issues. Right, it still saves us the day, though today's Web JS frontend is also quite complex but it's of no help. -- Töma From owen at delong.com Wed Jan 9 19:33:36 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Jan 2019 11:33:36 -0800 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: > On Jan 9, 2019, at 10:37 , Töma Gavrichenkov wrote: > > On Wed, Jan 9, 2019 at 9:31 PM Owen DeLong wrote: >> So if I understand you correctly, your statement is that everyone >> should be (potentially) rebooting every core, backbone, edge, >> and other router at least once or twice a week… > > Nope, this is a misunderstanding. One has to *check* for advisories at > least once or twice a week and only update (and reboot is necessary) > if there *is* a vulnerability. > > Checking is quite different from, actually, updating. What you may > want to encourage your competition to do is to deploy a piece of > software which actually *gets* a severe CVE twice in a week; that will > certainly bring you a bunch of new customers. Fair enough, but the frequency of vulnerability announcements even in some of the best implementations is still more often than I think my customers will tolerated reboots. At the end of the day, this is really about risk analysis and it helps to put things into 1 of 4 risk quadrants based on two axes… Axis 1 is the likelihood of the vulnerability being exploited, while axis 2 is the severity of the cost/consequences of exploitation. Obviously something that scores high on both axes will have me rolling out the upgrades as rapidly as possible, likely within 24 hours to at least the majority of the network. Something that scores low on both axes, conversely, is likely not worth the customer disruption and support call volume (not to mention SLA credits, etc.) that come from doing that level of maintenance on short notice (or without notice). The other two quadrants are a grey area that becomes more of a judgment call where other factors specific to each operator and their customer profile will come into play. Some operators may have a high tolerance for high-probability low-cost problem, while others may find this very urgent, for example. Owen From owen at delong.com Wed Jan 9 19:37:02 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Jan 2019 11:37:02 -0800 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: > On Jan 9, 2019, at 10:51 , Saku Ytti wrote: > > On Wed, 9 Jan 2019 at 20:45, Töma Gavrichenkov wrote: > >> Nope, this is a misunderstanding. One has to *check* for advisories at >> least once or twice a week and only update (and reboot is necessary) >> if there *is* a vulnerability. > > I think this contains some assumptions > > 1. discovering security issues in network devices is expensive (and > thus only those you glean from vendor notices realistically exist) Not really… I think the assumption here is that you can’t resolve an issue until the vendor publishes the fix. Outside of the open-source routing solutions (and even for most deployments, including those), I would say this is a valid assertion. (It’s more of an assertion than an assumption, IMHO). > 2. downside of being affected by network device security issue is expensive This depends on the issue, right? Owen From ximaera at gmail.com Wed Jan 9 19:41:48 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 22:41:48 +0300 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: On Wed, Jan 9, 2019 at 10:33 PM Owen DeLong wrote: > At the end of the day, this is really about risk analysis > and it helps to put things into 1 of 4 risk quadrants > based on two axes… Axis 1 is the likelihood of the > vulnerability being exploited, while axis 2 is the > severity of the cost/consequences of exploitation. > > Obviously something that scores high on both axes > will have me rolling out the upgrades as rapidly as > possible, likely within 24 hours to at least the > majority of the network. Good for you (not kidding). Not quite the same on average, as far as I can see. > The other two quadrants are a grey area that > becomes more of a judgment call where other > factors specific to each operator and their > customer profile will come into play. > Some operators may have a high tolerance > for high-probability low-cost problem, while > others may find this very urgent, for example. I agree with you; however, it's the other quadrant (high cost, seemingly low probability) which is a real gray area IMO which allows for collateral damage at a Hollywood blockbuster scale. -- Töma From ximaera at gmail.com Wed Jan 9 19:53:35 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 9 Jan 2019 22:53:35 +0300 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: On Wed, Jan 9, 2019 at 10:33 PM Owen DeLong wrote: > Fair enough, but the frequency of vulnerability announcements > even in some of the best implementations is still more often than > I think my customers will tolerated reboots. Well, and when I think about it for the second time, I can't help pointing out that there are long lived efforts from OS developers to come up with live patching, especially embedded and RTOS developers. As the recent you-know-which downtime has shown us, there are Internet-based services like 911 telephony which really start to treat Internet as a whole as a real time system. The question here is whether this encourages e.g. the aforementioned FRR developers (along with device vendors who actually get paid for the uninterruptible BGP availability) to accept this challenge. -- Töma From James at arenalgroup.co Wed Jan 9 21:51:08 2019 From: James at arenalgroup.co (James Breeden) Date: Wed, 9 Jan 2019 21:51:08 +0000 Subject: Centurylink/Level3 WDM? In-Reply-To: References: Message-ID: followup: they fixed it. Accidental fiber roll on their interface facing us during maintenance. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG on behalf of James Breeden Sent: Wednesday, January 9, 2019 12:48:25 PM To: nanog at nanog.org Subject: Centurylink/Level3 WDM? Anyone else having issues with Centurylink IP (Legacy Level3/3356) in/around Houston, or WDM issues between Houston and San Antonio? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Wed Jan 9 23:41:55 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 9 Jan 2019 23:41:55 -0000 Subject: BGP Experiment In-Reply-To: References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> Message-ID: <006a01d4a874$e7cbe8c0$b763ba40$@netconsultings.com> > Töma Gavrichenkov > Sent: Wednesday, January 9, 2019 7:08 PM > > On Wed, Jan 9, 2019 at 10:03 PM Saku Ytti wrote: > > Finding forwarding issues indeed is harder due to the limited access > > to devices, so bit of security through obscurity I guess. > > Or, rather, security by complexity. Today's network infrastructure is complex > enough for people to dive into it, looking for all the underlying issues. Right, it > still saves us the day, though today's Web JS frontend is also quite complex > but it's of no help. > I don't know about that, All modern NPUs are based on the models well explained to the sufficient level in Stanford lectures and other materials which you can download freely. Once you learn how an ideal routing system architecture should look like you can start discovering flaws in the vendor NPU blueprints. But the best fun is to put IXIA or Spirent in loop with your favourite carrier router. What I'm trying to say is it's not that complex to find these routing system architecture shortcomings - they will come out of the basic platform testing. adam From ximaera at gmail.com Thu Jan 10 00:36:33 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 10 Jan 2019 03:36:33 +0300 Subject: BGP Experiment In-Reply-To: <006a01d4a874$e7cbe8c0$b763ba40$@netconsultings.com> References: <303E611A-D0F9-4ADF-B6D9-9CD99240D075@delong.com> <006a01d4a874$e7cbe8c0$b763ba40$@netconsultings.com> Message-ID: Is that a competition in sarcasm? Because I can do better than that! 10 Jan. 2019 г., 2:41 : > > Töma Gavrichenkov > > Sent: Wednesday, January 9, 2019 7:08 PM > > > > On Wed, Jan 9, 2019 at 10:03 PM Saku Ytti wrote: > > > Finding forwarding issues indeed is harder due to the limited access > > > to devices, so bit of security through obscurity I guess. > > > > Or, rather, security by complexity. Today's network infrastructure is > complex > > enough for people to dive into it, looking for all the underlying > issues. Right, it > > still saves us the day, though today's Web JS frontend is also quite > complex > > but it's of no help. > > > I don't know about that, > All modern NPUs are based on the models well explained to the sufficient > level in Stanford lectures and other materials which you can download > freely. > Once you learn how an ideal routing system architecture should look like > you can start discovering flaws in the vendor NPU blueprints. > But the best fun is to put IXIA or Spirent in loop with your favourite > carrier router. > What I'm trying to say is it's not that complex to find these routing > system architecture shortcomings - they will come out of the basic > platform testing. > > adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno at NLnetLabs.nl Thu Jan 10 09:13:19 2019 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Thu, 10 Jan 2019 10:13:19 +0100 Subject: Call for presentations RIPE 78 Message-ID: <086916c1-1d8c-7dac-0a7b-8afabaa82317@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 78 below or at: https://ripe78.ripe.net/submit-topic/cfp/. The deadline for submissions is *3 March 2019*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. However, on an individual basis, participants can apply for a RIPE Fellowship or RACI, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe78.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. *RIPE 78 will take place from 20-24 May in Reykjavik, Iceland* The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 78. See the full descriptions of the different presentation formats: https://ripe78.ripe.net/submit-topic/presentation-formats/ Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *3 March 2019*. Proposals submitted after this date will be considered depending on the slots still available in the programme. The PC is looking for presentations covering the topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) ---- Speakers ---- Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. Please note that participants can apply for a RIPE Fellowship or RACI, on an individual basis, to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship https://www.ripe.net/participate/ripe/raci In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. ---- Submissions ---- Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe78.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and should not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes in total for both the presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe78.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe78.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. ---- Diversity and Inclusion - On-Site Childcare and the RIPE Meeting Code of Conduct ---- Did you know that RIPE Meetings now have on-site childcare? You can reserve a spot for your child (age 6 months - 10 years) during the registration process for the meeting. Childcare places are limited, so please be quick to reserve a spot for your child while registering for the meeting. More information at: https://ripe78.ripe.net/on-site/on-site-childcare/ Ensuring that RIPE Meeting values are upheld and that attendees experience a professional, respectful and safe meeting is a priority. Please do read the RIPE Meeting Code of Conduct: https://www.ripe.net/participate/meetings/ripe-meetings/ripe-meeting-code-of-conduct --- If you have any questions or requests concerning content submissions, please email pc at ripe.net. From tdonahue at donahuetechnology.com Wed Jan 9 22:20:50 2019 From: tdonahue at donahuetechnology.com (Tim Donahue) Date: Wed, 9 Jan 2019 22:20:50 +0000 Subject: Proofpoint Mail Delivery Issues Message-ID: Hi all, Sorry for the noise, but one of my clients is getting the standard "it's the other guy's fault" with some email delivery issues to/from Proofpoint "Enterprise" customers. If there is anyone from Proofpoint support monitoring this list, some assistance troubleshooting email delivery issues would be greatly appreciated. Thank you, Tim Donahue -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimpop at domainmail.org Thu Jan 10 02:08:48 2019 From: jimpop at domainmail.org (Jim Popovitch) Date: Wed, 09 Jan 2019 21:08:48 -0500 Subject: DNS Hijacking? - FiOS Northeast In-Reply-To: References: Message-ID: <1547086128.2275.1.camel@domainmail.org> On Wed, 2019-01-09 at 18:30 +0000, Phil Lavin wrote: > > We are seeing DNS requests for A and AAAA to 8.8.8.8 come back with > > erroneous replies resolving to 146.112.61.106 when sent via FiOS > > circuits in the northeast. Anyone else seeing issues with DNS on > > FiOS in Northeast? Issue started around 12:25 AM ET this morning > > and seems to be affecting customers in PA, RI, etc..  > > 146.112.61.106 appears to be an Anycast IP served by OpenDNS when > pages are blocked by the Cisco Umbrella service - https://support.ope > ndns.com/hc/en-us/articles/227986927-What-are-the-Cisco-Umbrella- > Block-Page-IP-Addresses- > > Are you sure the queries are going to Google 8.8.8.8 and not OpenDNS? > > What URL(s) are you seeing this on? > > Do you have a traceroute to 8.8.8.8 from an affected site? You can also do: ~$ dig TXT test.dns.google.com @8.8.8.8 "Thanks for using Google Public DNS." hth, -Jim P. From nanog at ics-il.net Thu Jan 10 16:01:07 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 10 Jan 2019 10:01:07 -0600 (CST) Subject: Proofpoint Mail Delivery Issues In-Reply-To: References: Message-ID: <1812968076.2413.1547136065612.JavaMail.mhammett@ThunderFuck> There is a mailing list dedicated to email system operators. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tim Donahue" To: nanog at nanog.org Sent: Wednesday, January 9, 2019 4:20:50 PM Subject: Proofpoint Mail Delivery Issues Hi all, Sorry for the noise, but one of my clients is getting the standard “it’s the other guy’s fault” with some email delivery issues to/from Proofpoint “Enterprise” customers. If there is anyone from Proofpoint support monitoring this list, some assistance troubleshooting email delivery issues would be greatly appreciated. Thank you, Tim Donahue -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Thu Jan 10 16:13:57 2019 From: Brian at ampr.org (Brian Kantor) Date: Thu, 10 Jan 2019 08:13:57 -0800 Subject: Proofpoint Mail Delivery Issues In-Reply-To: <1812968076.2413.1547136065612.JavaMail.mhammett@ThunderFuck> References: <1812968076.2413.1547136065612.JavaMail.mhammett@ThunderFuck> Message-ID: <20190110161357.GA97258@meow.BKantor.net> On Thu, Jan 10, 2019 at 10:01:07AM -0600, Mike Hammett wrote: > There is a mailing list dedicated to email system operators. > ----- > Mike Hammett > Intelligent Computing Solutions > Midwest Internet Exchange > The Brothers WISP Would you have subscription information for that mailing list, please? - Brian From rsk at gsp.org Thu Jan 10 16:22:20 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 10 Jan 2019 11:22:20 -0500 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues Message-ID: <20190110162220.GA7854@gsp.org> The "dumpsterfire" mailing list is for the discussion of security and privacy issues related to the IoT (Internet of Things). Arguably, the entire IoT *is* a security and privacy issue, but we'll get to that in good time. If you want to join, you can either use the list's web page: http://www.firemountain.net/mailman/listinfo/dumpsterfire or the list's subscription/unsubscription address: dumpsterfire-request at firemountain.net The list is public and so is its archive. ---rsk From dwhite at olp.net Thu Jan 10 16:30:53 2019 From: dwhite at olp.net (Dan White) Date: Thu, 10 Jan 2019 10:30:53 -0600 Subject: Proofpoint Mail Delivery Issues In-Reply-To: <20190110161357.GA97258@meow.BKantor.net> References: <1812968076.2413.1547136065612.JavaMail.mhammett@ThunderFuck> <20190110161357.GA97258@meow.BKantor.net> Message-ID: <20190110163052.GQ2172@dan.olp.net> On 01/10/19 08:13 -0800, Brian Kantor wrote: >On Thu, Jan 10, 2019 at 10:01:07AM -0600, Mike Hammett wrote: >> There is a mailing list dedicated to email system operators. >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> Midwest Internet Exchange >> The Brothers WISP > >Would you have subscription information for that mailing list, >please? > - Brian https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: dwhite at mybtc.com http://www.btcbroadband.com From jarenangerbauer at gmail.com Thu Jan 10 16:45:34 2019 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Thu, 10 Jan 2019 09:45:34 -0700 Subject: Proofpoint Mail Delivery Issues In-Reply-To: References: Message-ID: Responded to Tim off list. Thanks. --Jaren On Thu, Jan 10, 2019 at 8:59 AM Tim Donahue wrote: > Hi all, > > > > Sorry for the noise, but one of my clients is getting the standard “it’s > the other guy’s fault” with some email delivery issues to/from Proofpoint > “Enterprise” customers. If there is anyone from Proofpoint support > monitoring this list, some assistance troubleshooting email delivery issues > would be greatly appreciated. > > > > Thank you, > > > > Tim Donahue > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.mccabe at mcgill.ca Thu Jan 10 16:28:57 2019 From: david.mccabe at mcgill.ca (David McCabe) Date: Thu, 10 Jan 2019 16:28:57 +0000 Subject: Proofpoint Mail Delivery Issues In-Reply-To: <20190110161357.GA97258@meow.BKantor.net> References: <1812968076.2413.1547136065612.JavaMail.mhammett@ThunderFuck> <20190110161357.GA97258@meow.BKantor.net> Message-ID: mailop mailing list mailop at mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- David McCabe McGill University NCS Sent from laptop Outlook The only difference between Science and screwing around is writing it down - Adam Savage -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brian Kantor Sent: Thursday, January 10, 2019 11:14 To: Mike Hammett Cc: nanog at nanog.org Subject: Re: Proofpoint Mail Delivery Issues On Thu, Jan 10, 2019 at 10:01:07AM -0600, Mike Hammett wrote: > There is a mailing list dedicated to email system operators. > ----- > Mike Hammett > Intelligent Computing Solutions > Midwest Internet Exchange > The Brothers WISP Would you have subscription information for that mailing list, please? - Brian From jhellenthal at dataix.net Thu Jan 10 16:57:02 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 10 Jan 2019 10:57:02 -0600 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190110162220.GA7854@gsp.org> References: <20190110162220.GA7854@gsp.org> Message-ID: <20190110165703.44EB039837D2@DataIX.net> Unfortunately I don’t see this as having very much connectivity where I am at. host firemountain.net firemountain.net has address 207.114.3.55 firemountain.net mail is handled by 10 taos.firemountain.net. firemountain.net mail is handled by 20 ukiah.firemountain.net. host www.firemountain.net www.firemountain.net has address 207.114.3.55 Sending 5, 100-byte ICMP Echos to 207.114.3.55, timeout is 2 seconds: !.... Success rate is 20 percent (1/5), round-trip min/avg/max = 51/51/51 ms Tracing the route to firemountain.net (207.114.3.55) 1 0 msec 0 msec 0 msec 2 142.254.152.249 9 msec 9 msec 17 msec 3 ae62.nwblwi1801h.midwest.rr.com (24.164.241.145) 16 msec 16 msec 9 msec 4 be63.milzwift01r.midwest.rr.com (65.31.112.122) 25 msec 16 msec 17 msec 5 be40.clmkohpe01r.midwest.rr.com (65.25.137.109) 25 msec 25 msec 34 msec 6 be1.clmkohpe02r.midwest.rr.com (65.29.1.35) 34 msec 34 msec 25 msec 7 ae1.uparohgd01h.midwest.rr.com (24.33.161.209) 34 msec 42 msec 25 msec 8 69.23.10.160 34 msec 25 msec 25 msec 9 rrcs-98-102-146-106.central.biz.rr.com (98.102.146.106) 25 msec 34 msec 25 msec 10 xe-0-0-0.upa-core1.expedient.com (66.230.78.130) 33 msec 34 msec 25 msec 11 et-0-2-0.acm-core2.expedient.com (209.166.144.209) 34 msec 34 msec 34 msec 12 irb-4038.acm-core1.expedient.com (209.166.144.21) 33 msec 33 msec 25 msec 13 et-3-0-0.152-core2.expedient.com (66.230.78.194) 33 msec 33 msec 34 msec 14 ae2.152-core1.expedient.com (66.230.78.161) 42 msec 34 msec 34 msec 15 xe-0-3-0.fil-node.expedient.com (206.210.75.234) 42 msec 42 msec 51 msec 16 xe-0-3-0.1sc-node.expedient.com (216.230.108.246) 50 msec 42 msec 59 msec 17 ten1-6-2.tdp-core.expedient.com (216.230.108.229) 42 msec 42 msec 50 msec 18 firemountain.net (207.114.3.55) 50 msec 42 msec 51 msec HTH > On Jan 10, 2019, at 10:22, Rich Kulawiec wrote: > > The "dumpsterfire" mailing list is for the discussion of security and > privacy issues related to the IoT (Internet of Things). Arguably, > the entire IoT *is* a security and privacy issue, but we'll get to that > in good time. > > If you want to join, you can either use the list's web page: > > http://www.firemountain.net/mailman/listinfo/dumpsterfire > > or the list's subscription/unsubscription address: > > dumpsterfire-request at firemountain.net > > The list is public and so is its archive. > > ---rsk — J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: Message signed with OpenPGP URL: From cunha at dcc.ufmg.br Thu Jan 10 17:05:03 2019 From: cunha at dcc.ufmg.br (Italo Cunha) Date: Thu, 10 Jan 2019 12:05:03 -0500 Subject: BGP Experiment In-Reply-To: References: Message-ID: NANOG, The FRR devs have released binary packages including the fix and announced it on the FRR mailing lists. After considering the feedback on the list and discussing with FRR devs, we will postpone the experiments until Jan. 23rd, and have updated the schedule to reflect the delayed start and shorter timeline [A]. We will follow up with FRR devs and mailing lists/users. [A] https://goo.gl/nJhmx1 On Tue, Jan 8, 2019 at 11:41 AM Italo Cunha wrote: > > NANOG, > > We've performed the first announcement in this experiment yesterday, > and, despite the announcement being compliant with BGP standards, FRR > routers reset their sessions upon receiving it. Upon notice of the > problem, we halted the experiments. The FRR developers confirmed that > this issue is specific to an unintended consequence of how FRR handles > the attribute 0xFF (reserved for development) we used. The FRR devs > already merged a fix and notified users. > > We plan to resume the experiments January 16th (next Wednesday), and > have updated the experiment schedule [A] accordingly. As always, we > welcome your feedback. > > [A] https://goo.gl/nJhmx1 > > On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > > > > NANOG, > > > > We would like to inform you of an experiment to evaluate alternatives > > for speeding up adoption of BGP route origin validation (research > > paper with details [A]). > > > > Our plan is to announce prefix 184.164.224.0/24 with a valid > > standards-compliant unassigned BGP attribute from routers operated by > > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > > development), and size 0x20 (256bits). > > > > Our collaborators recently ran an equivalent experiment with no > > complaints or known issues [A], and so we do not anticipate any > > arising. Back in 2010, an experiment using unassigned attributes by > > RIPE and Duke University caused disruption in Internet routing due to > > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > > attributes have been assigned (BGPsec-path) and adopted (large > > communities). We have successfully tested propagation of the > > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > > 1.6.3. > > > > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > > predefined period of 15 minutes starting 14:30 GMT, from Monday to > > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > > locations [E]). We will stop the experiment immediately in case any > > issues arise. > > > > Although we do not expect the experiment to cause disruption, we > > welcome feedback on its safety and especially on how to make it safer. > > We can be reached at disco-experiment at googlegroups.com. > > > > Amir Herzberg, University of Connecticut > > Ethan Katz-Bassett, Columbia University > > Haya Shulman, Fraunhofer SIT > > Ítalo Cunha, Universidade Federal de Minas Gerais > > Michael Schapira, Hebrew University of Jerusalem > > Tomas Hlavacek, Fraunhofer SIT > > Yossi Gilad, MIT > > > > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > > [B] http://peering.usc.edu > > [C] https://goo.gl/AFR1Cn > > [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > > [E] https://goo.gl/nJhmx1 From tony at wicks.co.nz Thu Jan 10 18:18:50 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 11 Jan 2019 07:18:50 +1300 Subject: Proofpoint Mail Delivery Issues In-Reply-To: References: Message-ID: <001301d4a910$f03ae730$d0b0b590$@wicks.co.nz> This might be helpful - https://ipcheck.proofpoint.com/ From: NANOG On Behalf Of Tim Donahue Sent: Thursday, 10 January 2019 11:21 AM To: nanog at nanog.org Subject: Proofpoint Mail Delivery Issues Hi all, Sorry for the noise, but one of my clients is getting the standard "it's the other guy's fault" with some email delivery issues to/from Proofpoint "Enterprise" customers. If there is anyone from Proofpoint support monitoring this list, some assistance troubleshooting email delivery issues would be greatly appreciated. Thank you, Tim Donahue -------------- next part -------------- An HTML attachment was scrubbed... URL: From has at google.com Thu Jan 10 18:29:39 2019 From: has at google.com (Heather Schiller) Date: Thu, 10 Jan 2019 13:29:39 -0500 Subject: Google Fiber v6 PD only giving /64 In-Reply-To: <20190106045653.GA32738@cmadams.net> References: <20190106045653.GA32738@cmadams.net> Message-ID: I designed the original numbering plan, but handed it off a while back. Taking a look into this, thanks for the heads up. --Heather On Sat, Jan 5, 2019 at 11:58 PM Chris Adams wrote: > Anybody here from Google Fiber? When I first got it last year, my IPv6 > setup got a /56 prefix delegated. I now see that no matter what size I > request, I only get a /64. Is this intentional? > -- > Chris Adams > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Thu Jan 10 23:15:44 2019 From: john at essenz.com (John Von Essen) Date: Thu, 10 Jan 2019 18:15:44 -0500 Subject: Switch.com AS23005 Message-ID: Can someone from Switch.com / AS23005 contact me off-list? I have an IRR route object conflict issue that’s attention. John From ops.lists at gmail.com Fri Jan 11 14:27:25 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 11 Jan 2019 19:57:25 +0530 Subject: ARIN NS down? Message-ID: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more srs at Sureshs-MacBook-Pro-2 19:56:18 <~> $ dig +trace +norec whois.arin.net ; <<>> DiG 9.10.6 <<>> +trace +norec whois.arin.net ;; global options: +cmd . 2230 IN NS m.root-servers.net. . 2230 IN NS b.root-servers.net. . 2230 IN NS c.root-servers.net. . 2230 IN NS d.root-servers.net. . 2230 IN NS e.root-servers.net. . 2230 IN NS f.root-servers.net. . 2230 IN NS g.root-servers.net. . 2230 IN NS h.root-servers.net. . 2230 IN NS i.root-servers.net. . 2230 IN NS j.root-servers.net. . 2230 IN NS a.root-servers.net. . 2230 IN NS k.root-servers.net. . 2230 IN NS l.root-servers.net. . 2230 IN RRSIG NS 8 0 518400 20190121050000 20190108040000 16749 . JqXTRb0qik0Iy1zDpwKRfKr1iZjTeiJRTk1GCfIWh9dFFvhN0c7Fiz6H lbNfhgQbPsacG0b/1I3rguS13H2guX7apppK2w88h+z8mzym2Bw1C1HR ZR3ocj/jHLJbMqHdQ+DFyRdw/AxCXBdhnbX46C8+unhQ03D/MzS0M0t4 vgadYi7BN4sa+iZIilwFV56n2dOfpzyO+evVbcnTLRZ6D4bjCHZLCtO8 EDziAPUbVAPZWiflb7/Y2dECe5gbOuGYYU/xv/Pal5+v9cjgMjcf8buG S+iTIL/lnus0JJSRDmkM6yzfYMBXC2ZqhOp+Ls+EfvmqFjIZzi394XCi pdKRZw== ;; Received 525 bytes from 10.0.0.1#53(10.0.0.1) in 40 ms net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE net. 86400 IN RRSIG DS 8 1 86400 20190124130000 20190111120000 16749 . uahpltN27UkKaFJRaAU1on+IpC2lpgZo84XEM7Pk7dQysKfSnqUkaVLY PXQf9kvgW5eOx/+BttQB2OWFLckJs8vv5ScOpz7dDhs8zR2FPLm93HTD 4F/XEKDNOQbFGSA3g4pZq3fatY7kFEkV9sFTH90WqJt0sXe64LYFcwr2 FtrJaS/yhEV4XDbsN3RLkBP58bf526LPpvonwSZsMUTDZcnXtUnc57ZI dlTHg2snNhVWu4qJfHDsEQPwOZagRXJhjlRT8Ox/7HwXvplmRfmeuhZb Vj5kdiY+3j0RTxpLRCG/SZRDIRcvdFKh9umdwQvAzuTS0xzO8OyPw9q8 8QCCYg== ;; Received 1171 bytes from 192.112.36.4#53(g.root-servers.net) in 207 ms arin.net. 172800 IN NS ns1.arin.net. arin.net. 172800 IN NS ns2.arin.net. arin.net. 172800 IN NS u.arin.net. arin.net. 172800 IN NS ns3.arin.net. arin.net. 86400 IN DS 48281 5 2 6EB0CCF325A8101A768C93D10CE084303D3714D4E92FEE53D6E683D2 22291017 arin.net. 86400 IN DS 48281 5 1 FCBF93357C8FE3247CECB2CD277F45EB955EE4CE arin.net. 86400 IN RRSIG DS 8 2 86400 20190117062448 20190110051448 6140 net. stuWyfC0PDuk2hNF/Bnz0lnypk+bA/slTa2KYznjmoLXDtq7v1obJq41 ZfloQKXuC7MnzpCQj70GU9ZESZq1/XU+u6wDmCqmEUbJ3kyrILxkVrln bTEySJWPmurpwUVzDVfvqFpXEOhWxOjDu6drZMcC3wG9EdPqBuFC6wlf FIQ= couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more From jcurran at istaff.org Fri Jan 11 14:34:51 2019 From: jcurran at istaff.org (John Curran) Date: Fri, 11 Jan 2019 09:34:51 -0500 Subject: ARIN NS down? In-Reply-To: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> Message-ID: <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Suresh - We’re aware and working the problem. It looks to me like expired RRSIG/DNSKEY’s for the zone, so if you’re using a DNSSEC validating resolver (e.g. Google, Cloudflare, Cogent) then ARIN.NET is unreachable. ARIN’s engineering team is working on resolution now. /John John Curran President and CEO American Registry for Internet Numbers > On 11 Jan 2019, at 9:27 AM, Suresh Ramasubramanian > wrote: > > couldn't get address for 'ns1.arin.net ': not found > couldn't get address for 'ns2.arin.net ': not found > couldn't get address for 'u.arin.net ': not found > couldn't get address for 'ns3.arin.net ': not found > dig: couldn't get address for 'ns1.arin.net ': no more > > srs at Sureshs-MacBook-Pro-2 19:56:18 <~> $ dig +trace +norec whois.arin.net > > ; <<>> DiG 9.10.6 <<>> +trace +norec whois.arin.net > ;; global options: +cmd > . 2230 IN NS m.root-servers.net . > . 2230 IN NS b.root-servers.net . > . 2230 IN NS c.root-servers.net . > . 2230 IN NS d.root-servers.net . > . 2230 IN NS e.root-servers.net . > . 2230 IN NS f.root-servers.net . > . 2230 IN NS g.root-servers.net . > . 2230 IN NS h.root-servers.net . > . 2230 IN NS i.root-servers.net . > . 2230 IN NS j.root-servers.net . > . 2230 IN NS a.root-servers.net . > . 2230 IN NS k.root-servers.net . > . 2230 IN NS l.root-servers.net . > . 2230 IN RRSIG NS 8 0 518400 20190121050000 20190108040000 16749 . JqXTRb0qik0Iy1zDpwKRfKr1iZjTeiJRTk1GCfIWh9dFFvhN0c7Fiz6H lbNfhgQbPsacG0b/1I3rguS13H2guX7apppK2w88h+z8mzym2Bw1C1HR ZR3ocj/jHLJbMqHdQ+DFyRdw/AxCXBdhnbX46C8+unhQ03D/MzS0M0t4 vgadYi7BN4sa+iZIilwFV56n2dOfpzyO+evVbcnTLRZ6D4bjCHZLCtO8 EDziAPUbVAPZWiflb7/Y2dECe5gbOuGYYU/xv/Pal5+v9cjgMjcf8buG S+iTIL/lnus0JJSRDmkM6yzfYMBXC2ZqhOp+Ls+EfvmqFjIZzi394XCi pdKRZw== > ;; Received 525 bytes from 10.0.0.1#53(10.0.0.1) in 40 ms > > net. 172800 IN NS g.gtld-servers.net . > net. 172800 IN NS c.gtld-servers.net . > net. 172800 IN NS j.gtld-servers.net . > net. 172800 IN NS e.gtld-servers.net . > net. 172800 IN NS h.gtld-servers.net . > net. 172800 IN NS k.gtld-servers.net . > net. 172800 IN NS m.gtld-servers.net . > net. 172800 IN NS i.gtld-servers.net . > net. 172800 IN NS f.gtld-servers.net . > net. 172800 IN NS b.gtld-servers.net . > net. 172800 IN NS a.gtld-servers.net . > net. 172800 IN NS d.gtld-servers.net . > net. 172800 IN NS l.gtld-servers.net . > net. 86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE > net. 86400 IN RRSIG DS 8 1 86400 20190124130000 20190111120000 16749 . uahpltN27UkKaFJRaAU1on+IpC2lpgZo84XEM7Pk7dQysKfSnqUkaVLY PXQf9kvgW5eOx/+BttQB2OWFLckJs8vv5ScOpz7dDhs8zR2FPLm93HTD 4F/XEKDNOQbFGSA3g4pZq3fatY7kFEkV9sFTH90WqJt0sXe64LYFcwr2 FtrJaS/yhEV4XDbsN3RLkBP58bf526LPpvonwSZsMUTDZcnXtUnc57ZI dlTHg2snNhVWu4qJfHDsEQPwOZagRXJhjlRT8Ox/7HwXvplmRfmeuhZb Vj5kdiY+3j0RTxpLRCG/SZRDIRcvdFKh9umdwQvAzuTS0xzO8OyPw9q8 8QCCYg== > ;; Received 1171 bytes from 192.112.36.4#53(g.root-servers.net ) in 207 ms > > arin.net . 172800 IN NS ns1.arin.net . > arin.net . 172800 IN NS ns2.arin.net . > arin.net . 172800 IN NS u.arin.net . > arin.net . 172800 IN NS ns3.arin.net . > arin.net . 86400 IN DS 48281 5 2 6EB0CCF325A8101A768C93D10CE084303D3714D4E92FEE53D6E683D2 22291017 > arin.net . 86400 IN DS 48281 5 1 FCBF93357C8FE3247CECB2CD277F45EB955EE4CE > arin.net . 86400 IN RRSIG DS 8 2 86400 20190117062448 20190110051448 6140 net. stuWyfC0PDuk2hNF/Bnz0lnypk+bA/slTa2KYznjmoLXDtq7v1obJq41 ZfloQKXuC7MnzpCQj70GU9ZESZq1/XU+u6wDmCqmEUbJ3kyrILxkVrln bTEySJWPmurpwUVzDVfvqFpXEOhWxOjDu6drZMcC3wG9EdPqBuFC6wlf FIQ= > couldn't get address for 'ns1.arin.net ': not found > couldn't get address for 'ns2.arin.net ': not found > couldn't get address for 'u.arin.net ': not found > couldn't get address for 'ns3.arin.net ': not found > dig: couldn't get address for 'ns1.arin.net ': no more > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Fri Jan 11 14:37:53 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 11 Jan 2019 15:37:53 +0100 Subject: ARIN NS down? In-Reply-To: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> Message-ID: <20190111143753.6lxcpaxxpg2h2vfe@nic.fr> On Fri, Jan 11, 2019 at 07:57:25PM +0530, Suresh Ramasubramanian wrote a message of 56 lines which said: > couldn't get address for 'ns1.arin.net': not found DNSSEC issue, they let the signatures expire From martijnschmidt at i3d.net Fri Jan 11 15:39:13 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Fri, 11 Jan 2019 16:39:13 +0100 Subject: ARIN NS down? In-Reply-To: <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Message-ID: <25ab85e6-a80d-6834-9355-bcd8a40151a5@i3d.net> Is this the right time to ask whether everyone who operates DNSSEC validating resolvers was required to click somewhere on the ARIN website that they agree to be bound by the Relying Party Agreement before their resolver can make DNSSEC lookups against the ARIN nameservers? Or does that logic only apply for access to the RPKI TAL? Best regards, Martijn On 1/11/19 3:34 PM, John Curran wrote: > Suresh - > > We’re aware and working the problem.  It looks to me like expired > RRSIG/DNSKEY’s for the zone,  > so if you’re using a DNSSEC validating resolver (e.g. Google, > Cloudflare, Cogent) then ARIN.NET > is unreachable.   ARIN’s engineering team is working on resolution now. > > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > >> On 11 Jan 2019, at 9:27 AM, Suresh Ramasubramanian >> > wrote: >> >> couldn't get address for 'ns1.arin.net ': not found >> couldn't get address for 'ns2.arin.net ': not found >> couldn't get address for 'u.arin.net ': not found >> couldn't get address for 'ns3.arin.net ': not found >> dig: couldn't get address for 'ns1.arin.net ': >> no more >> >> srs at Sureshs-MacBook-Pro-2 19:56:18 <~> $ dig +trace +norec >> whois.arin.net >> >> ; <<>> DiG 9.10.6 <<>> +trace +norec whois.arin.net >> >> ;; global options: +cmd >> .2230INNSm.root-servers.net . >> .2230INNSb.root-servers.net . >> .2230INNSc.root-servers.net . >> .2230INNSd.root-servers.net . >> .2230INNSe.root-servers.net . >> .2230INNSf.root-servers.net . >> .2230INNSg.root-servers.net . >> .2230INNSh.root-servers.net . >> .2230INNSi.root-servers.net . >> .2230INNSj.root-servers.net . >> .2230INNSa.root-servers.net . >> .2230INNSk.root-servers.net . >> .2230INNSl.root-servers.net . >> .2230INRRSIGNS 8 0 518400 20190121050000 20190108040000 16749 . >> JqXTRb0qik0Iy1zDpwKRfKr1iZjTeiJRTk1GCfIWh9dFFvhN0c7Fiz6H >> lbNfhgQbPsacG0b/1I3rguS13H2guX7apppK2w88h+z8mzym2Bw1C1HR >> ZR3ocj/jHLJbMqHdQ+DFyRdw/AxCXBdhnbX46C8+unhQ03D/MzS0M0t4 >> vgadYi7BN4sa+iZIilwFV56n2dOfpzyO+evVbcnTLRZ6D4bjCHZLCtO8 >> EDziAPUbVAPZWiflb7/Y2dECe5gbOuGYYU/xv/Pal5+v9cjgMjcf8buG >> S+iTIL/lnus0JJSRDmkM6yzfYMBXC2ZqhOp+Ls+EfvmqFjIZzi394XCi pdKRZw== >> ;; Received 525 bytes from 10.0.0.1#53(10.0.0.1) in 40 ms >> >> net.172800INNSg.gtld-servers.net . >> net.172800INNSc.gtld-servers.net . >> net.172800INNSj.gtld-servers.net . >> net.172800INNSe.gtld-servers.net . >> net.172800INNSh.gtld-servers.net . >> net.172800INNSk.gtld-servers.net . >> net.172800INNSm.gtld-servers.net . >> net.172800INNSi.gtld-servers.net . >> net.172800INNSf.gtld-servers.net . >> net.172800INNSb.gtld-servers.net . >> net.172800INNSa.gtld-servers.net . >> net.172800INNSd.gtld-servers.net . >> net.172800INNSl.gtld-servers.net . >> net.86400INDS35886 8 2 >> 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE >> net.86400INRRSIGDS 8 1 86400 20190124130000 20190111120000 16749 . >> uahpltN27UkKaFJRaAU1on+IpC2lpgZo84XEM7Pk7dQysKfSnqUkaVLY >> PXQf9kvgW5eOx/+BttQB2OWFLckJs8vv5ScOpz7dDhs8zR2FPLm93HTD >> 4F/XEKDNOQbFGSA3g4pZq3fatY7kFEkV9sFTH90WqJt0sXe64LYFcwr2 >> FtrJaS/yhEV4XDbsN3RLkBP58bf526LPpvonwSZsMUTDZcnXtUnc57ZI >> dlTHg2snNhVWu4qJfHDsEQPwOZagRXJhjlRT8Ox/7HwXvplmRfmeuhZb >> Vj5kdiY+3j0RTxpLRCG/SZRDIRcvdFKh9umdwQvAzuTS0xzO8OyPw9q8 8QCCYg== >> ;; Received 1171 bytes from 192.112.36.4#53(g.root-servers.net >> ) in 207 ms >> >> arin.net .172800INNSns1.arin.net >> . >> arin.net .172800INNSns2.arin.net >> . >> arin.net .172800INNSu.arin.net . >> arin.net .172800INNSns3.arin.net >> . >> arin.net .86400INDS48281 5 2 >> 6EB0CCF325A8101A768C93D10CE084303D3714D4E92FEE53D6E683D2 22291017 >> arin.net .86400INDS48281 5 1 >> FCBF93357C8FE3247CECB2CD277F45EB955EE4CE >> arin.net .86400INRRSIGDS 8 2 86400 20190117062448 >> 20190110051448 6140 net. >> stuWyfC0PDuk2hNF/Bnz0lnypk+bA/slTa2KYznjmoLXDtq7v1obJq41 >> ZfloQKXuC7MnzpCQj70GU9ZESZq1/XU+u6wDmCqmEUbJ3kyrILxkVrln >> bTEySJWPmurpwUVzDVfvqFpXEOhWxOjDu6drZMcC3wG9EdPqBuFC6wlf FIQ= >> couldn't get address for 'ns1.arin.net ': not found >> couldn't get address for 'ns2.arin.net ': not found >> couldn't get address for 'u.arin.net ': not found >> couldn't get address for 'ns3.arin.net ': not found >> dig: couldn't get address for 'ns1.arin.net ': >> no more >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jan 11 15:39:55 2019 From: jcurran at arin.net (John Curran) Date: Fri, 11 Jan 2019 15:39:55 +0000 Subject: ARIN NS down? In-Reply-To: <20190111143753.6lxcpaxxpg2h2vfe@nic.fr> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <20190111143753.6lxcpaxxpg2h2vfe@nic.fr> Message-ID: <3DD245D6-A005-4FC8-A6B9-4B81F6512D85@arin.net> On Fri, Jan 11, 2019 at 07:57:25PM +0530, couldn't get address for 'ns1.arin.net': not found Folks - This has been resolved - arin.net zone is again correctly signed. Post-mortem forthcoming, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Fri Jan 11 15:58:25 2019 From: cb.list6 at gmail.com (Ca By) Date: Fri, 11 Jan 2019 07:58:25 -0800 Subject: =?UTF-8?Q?Dnssec_still_inoperable_on_the_internet_=3F=E2=80=94_was_ARI?= =?UTF-8?Q?N_NS_down=3F?= In-Reply-To: <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Message-ID: Thanks for the update that dnssec STILL causes more real world problems than it solves. ..... That said, arin is a pro outfit. If they can screw it up, like nasa, so can you. No your threats and deploy wisely ---------- Forwarded message --------- From: John Curran Date: Fri, Jan 11, 2019 at 6:36 AM Subject: Re: ARIN NS down? To: Suresh Ramasubramanian CC: NANOG Suresh - We’re aware and working the problem. It looks to me like expired RRSIG/DNSKEY’s for the zone, so if you’re using a DNSSEC validating resolver (e.g. Google, Cloudflare, Cogent) then ARIN.NET is unreachable. ARIN’s engineering team is working on resolution now. /John John Curran President and CEO American Registry for Internet Numbers On 11 Jan 2019, at 9:27 AM, Suresh Ramasubramanian wrote: couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more srs at Sureshs-MacBook-Pro-2 19:56:18 <~> $ dig +trace +norec whois.arin.net ; <<>> DiG 9.10.6 <<>> +trace +norec whois.arin.net ;; global options: +cmd . 2230 IN NS m.root-servers.net. . 2230 IN NS b.root-servers.net. . 2230 IN NS c.root-servers.net. . 2230 IN NS d.root-servers.net. . 2230 IN NS e.root-servers.net. . 2230 IN NS f.root-servers.net. . 2230 IN NS g.root-servers.net. . 2230 IN NS h.root-servers.net. . 2230 IN NS i.root-servers.net. . 2230 IN NS j.root-servers.net. . 2230 IN NS a.root-servers.net. . 2230 IN NS k.root-servers.net. . 2230 IN NS l.root-servers.net. . 2230 IN RRSIG NS 8 0 518400 20190121050000 20190108040000 16749 . JqXTRb0qik0Iy1zDpwKRfKr1iZjTeiJRTk1GCfIWh9dFFvhN0c7Fiz6H lbNfhgQbPsacG0b/1I3rguS13H2guX7apppK2w88h+z8mzym2Bw1C1HR ZR3ocj/jHLJbMqHdQ+DFyRdw/AxCXBdhnbX46C8+unhQ03D/MzS0M0t4 vgadYi7BN4sa+iZIilwFV56n2dOfpzyO+evVbcnTLRZ6D4bjCHZLCtO8 EDziAPUbVAPZWiflb7/Y2dECe5gbOuGYYU/xv/Pal5+v9cjgMjcf8buG S+iTIL/lnus0JJSRDmkM6yzfYMBXC2ZqhOp+Ls+EfvmqFjIZzi394XCi pdKRZw== ;; Received 525 bytes from 10.0.0.1#53(10.0.0.1) in 40 ms net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE net. 86400 IN RRSIG DS 8 1 86400 20190124130000 20190111120000 16749 . uahpltN27UkKaFJRaAU1on+IpC2lpgZo84XEM7Pk7dQysKfSnqUkaVLY PXQf9kvgW5eOx/+BttQB2OWFLckJs8vv5ScOpz7dDhs8zR2FPLm93HTD 4F/XEKDNOQbFGSA3g4pZq3fatY7kFEkV9sFTH90WqJt0sXe64LYFcwr2 FtrJaS/yhEV4XDbsN3RLkBP58bf526LPpvonwSZsMUTDZcnXtUnc57ZI dlTHg2snNhVWu4qJfHDsEQPwOZagRXJhjlRT8Ox/7HwXvplmRfmeuhZb Vj5kdiY+3j0RTxpLRCG/SZRDIRcvdFKh9umdwQvAzuTS0xzO8OyPw9q8 8QCCYg== ;; Received 1171 bytes from 192.112.36.4#53(g.root-servers.net) in 207 ms arin.net. 172800 IN NS ns1.arin.net. arin.net. 172800 IN NS ns2.arin.net. arin.net. 172800 IN NS u.arin.net. arin.net. 172800 IN NS ns3.arin.net. arin.net. 86400 IN DS 48281 5 2 6EB0CCF325A8101A768C93D10CE084303D3714D4E92FEE53D6E683D2 22291017 arin.net. 86400 IN DS 48281 5 1 FCBF93357C8FE3247CECB2CD277F45EB955EE4CE arin.net. 86400 IN RRSIG DS 8 2 86400 20190117062448 20190110051448 6140 net. stuWyfC0PDuk2hNF/Bnz0lnypk+bA/slTa2KYznjmoLXDtq7v1obJq41 ZfloQKXuC7MnzpCQj70GU9ZESZq1/XU+u6wDmCqmEUbJ3kyrILxkVrln bTEySJWPmurpwUVzDVfvqFpXEOhWxOjDu6drZMcC3wG9EdPqBuFC6wlf FIQ= couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Fri Jan 11 16:10:52 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 11 Jan 2019 17:10:52 +0100 Subject: Dnssec still inoperable on =?utf-8?Q?t?= =?utf-8?Q?he_internet_=3F=E2=80=94?= was ARIN NS down? In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Message-ID: <20190111161052.txby627oixn5zujw@nic.fr> On Fri, Jan 11, 2019 at 07:58:25AM -0800, Ca By wrote a message of 488 lines which said: > No your threats and deploy wisely Say no to the threats :-) From cb.list6 at gmail.com Fri Jan 11 16:13:17 2019 From: cb.list6 at gmail.com (Ca By) Date: Fri, 11 Jan 2019 08:13:17 -0800 Subject: =?UTF-8?Q?Re=3A_Dnssec_still_inoperable_on_the_internet_=3F=E2=80=94_was?= =?UTF-8?Q?_ARIN_NS_down=3F?= In-Reply-To: <20190111161052.txby627oixn5zujw@nic.fr> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> <20190111161052.txby627oixn5zujw@nic.fr> Message-ID: On Fri, Jan 11, 2019 at 8:10 AM Stephane Bortzmeyer wrote: > On Fri, Jan 11, 2019 at 07:58:25AM -0800, > Ca By wrote > a message of 488 lines which said: > > > No your threats and deploy wisely > > Say no to the threats :-) > This is nanog, so i used the cisco no Its like , negate threats :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yang.yu.list at gmail.com Fri Jan 11 16:23:31 2019 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 11 Jan 2019 08:23:31 -0800 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190110162220.GA7854@gsp.org> References: <20190110162220.GA7854@gsp.org> Message-ID: On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec wrote: > > The "dumpsterfire" mailing list is for the discussion of security and > privacy issues related to the IoT (Internet of Things). Arguably, > the entire IoT *is* a security and privacy issue, but we'll get to that > in good time. > > If you want to join, you can either use the list's web page: > > http://www.firemountain.net/mailman/listinfo/dumpsterfire > > or the list's subscription/unsubscription address: > > dumpsterfire-request at firemountain.net > > The list is public and so is its archive. * no HTTPS * archive is returning HTTP 403 From ross at tajvar.io Fri Jan 11 16:27:42 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 11 Jan 2019 11:27:42 -0500 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> Message-ID: A dumpster fire, indeed. On Fri, Jan 11, 2019, 11:26 AM Yang Yu On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec wrote: > > > > The "dumpsterfire" mailing list is for the discussion of security and > > privacy issues related to the IoT (Internet of Things). Arguably, > > the entire IoT *is* a security and privacy issue, but we'll get to that > > in good time. > > > > If you want to join, you can either use the list's web page: > > > > http://www.firemountain.net/mailman/listinfo/dumpsterfire > > > > or the list's subscription/unsubscription address: > > > > dumpsterfire-request at firemountain.net > > > > The list is public and so is its archive. > > * no HTTPS > * archive is returning HTTP 403 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Jan 11 16:30:57 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 11 Jan 2019 10:30:57 -0600 (CST) Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> Message-ID: <1050675483.3245.1547224257379.JavaMail.mhammett@ThunderFuck> No HTTPS?!?! Where are the tar and feathers??!?!! This isn't something that needs HTTPS. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Yang Yu" To: "Rich Kulawiec" Cc: "NANOG list" Sent: Friday, January 11, 2019 10:23:31 AM Subject: Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec wrote: > > The "dumpsterfire" mailing list is for the discussion of security and > privacy issues related to the IoT (Internet of Things). Arguably, > the entire IoT *is* a security and privacy issue, but we'll get to that > in good time. > > If you want to join, you can either use the list's web page: > > http://www.firemountain.net/mailman/listinfo/dumpsterfire > > or the list's subscription/unsubscription address: > > dumpsterfire-request at firemountain.net > > The list is public and so is its archive. * no HTTPS * archive is returning HTTP 403 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Fri Jan 11 16:35:57 2019 From: Brian at ampr.org (Brian Kantor) Date: Fri, 11 Jan 2019 08:35:57 -0800 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <1050675483.3245.1547224257379.JavaMail.mhammett@ThunderFuck> References: <20190110162220.GA7854@gsp.org> <1050675483.3245.1547224257379.JavaMail.mhammett@ThunderFuck> Message-ID: <20190111163557.GA3065@meow.BKantor.net> On Fri, Jan 11, 2019 at 10:30:57AM -0600, Mike Hammett wrote: > No HTTPS?!?! Where are the tar and feathers??!?!! > > This isn't something that needs HTTPS. > ----- > Mike Hammett > Intelligent Computing Solutions True, but our browser overlords would condemn it because they seem to believe that EVERYTHING should be guarded by https. - Brian From maxtul at netassist.ua Fri Jan 11 16:36:44 2019 From: maxtul at netassist.ua (Max Tulyev) Date: Fri, 11 Jan 2019 18:36:44 +0200 Subject: =?UTF-8?Q?Re:_Dnssec_still_inoperable_on_the_internet_=3f=e2=80=94_?= =?UTF-8?Q?was_ARIN_NS_down=3f?= In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Message-ID: <2d8658c1-1f7c-c35c-7550-63a30e9b376b@netassist.ua> It's because you see problems it causes, and do not see problems it solves ;) 11.01.19 17:58, Ca By пише: > Thanks for the update that dnssec STILL causes more real world problems > than it solves.  > > ..... > > That said, arin is a pro outfit. If they can screw it up, like nasa, so > can you. No your threats and deploy wisely > > ---------- Forwarded message --------- > From: *John Curran* > > Date: Fri, Jan 11, 2019 at 6:36 AM > Subject: Re: ARIN NS down? > To: Suresh Ramasubramanian > > CC: NANOG > > > > Suresh - > > We’re aware and working the problem.  It looks to me like expired > RRSIG/DNSKEY’s for the zone,  > so if you’re using a DNSSEC validating resolver (e.g. Google, > Cloudflare, Cogent) then ARIN.NET > is unreachable.   ARIN’s engineering team is working on resolution now. > > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > >> On 11 Jan 2019, at 9:27 AM, Suresh Ramasubramanian >> > wrote: >> >> couldn't get address for 'ns1.arin.net ': not found >> couldn't get address for 'ns2.arin.net ': not found >> couldn't get address for 'u.arin.net ': not found >> couldn't get address for 'ns3.arin.net ': not found >> dig: couldn't get address for 'ns1.arin.net ': >> no more >> >> srs at Sureshs-MacBook-Pro-2 19:56:18 <~> $ dig +trace +norec >> whois.arin.net >> >> ; <<>> DiG 9.10.6 <<>> +trace +norec whois.arin.net >> >> ;; global options: +cmd >> .2230INNSm.root-servers.net . >> .2230INNSb.root-servers.net . >> .2230INNSc.root-servers.net . >> .2230INNSd.root-servers.net . >> .2230INNSe.root-servers.net . >> .2230INNSf.root-servers.net . >> .2230INNSg.root-servers.net . >> .2230INNSh.root-servers.net . >> .2230INNSi.root-servers.net . >> .2230INNSj.root-servers.net . >> .2230INNSa.root-servers.net . >> .2230INNSk.root-servers.net . >> .2230INNSl.root-servers.net . >> .2230INRRSIGNS 8 0 518400 20190121050000 20190108040000 16749 . >> JqXTRb0qik0Iy1zDpwKRfKr1iZjTeiJRTk1GCfIWh9dFFvhN0c7Fiz6H >> lbNfhgQbPsacG0b/1I3rguS13H2guX7apppK2w88h+z8mzym2Bw1C1HR >> ZR3ocj/jHLJbMqHdQ+DFyRdw/AxCXBdhnbX46C8+unhQ03D/MzS0M0t4 >> vgadYi7BN4sa+iZIilwFV56n2dOfpzyO+evVbcnTLRZ6D4bjCHZLCtO8 >> EDziAPUbVAPZWiflb7/Y2dECe5gbOuGYYU/xv/Pal5+v9cjgMjcf8buG >> S+iTIL/lnus0JJSRDmkM6yzfYMBXC2ZqhOp+Ls+EfvmqFjIZzi394XCi pdKRZw== >> ;; Received 525 bytes from 10.0.0.1#53(10.0.0.1) in 40 ms >> >> net.172800INNSg.gtld-servers.net . >> net.172800INNSc.gtld-servers.net . >> net.172800INNSj.gtld-servers.net . >> net.172800INNSe.gtld-servers.net . >> net.172800INNSh.gtld-servers.net . >> net.172800INNSk.gtld-servers.net . >> net.172800INNSm.gtld-servers.net . >> net.172800INNSi.gtld-servers.net . >> net.172800INNSf.gtld-servers.net . >> net.172800INNSb.gtld-servers.net . >> net.172800INNSa.gtld-servers.net . >> net.172800INNSd.gtld-servers.net . >> net.172800INNSl.gtld-servers.net . >> net.86400INDS35886 8 2 >> 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE >> net.86400INRRSIGDS 8 1 86400 20190124130000 20190111120000 16749 . >> uahpltN27UkKaFJRaAU1on+IpC2lpgZo84XEM7Pk7dQysKfSnqUkaVLY >> PXQf9kvgW5eOx/+BttQB2OWFLckJs8vv5ScOpz7dDhs8zR2FPLm93HTD >> 4F/XEKDNOQbFGSA3g4pZq3fatY7kFEkV9sFTH90WqJt0sXe64LYFcwr2 >> FtrJaS/yhEV4XDbsN3RLkBP58bf526LPpvonwSZsMUTDZcnXtUnc57ZI >> dlTHg2snNhVWu4qJfHDsEQPwOZagRXJhjlRT8Ox/7HwXvplmRfmeuhZb >> Vj5kdiY+3j0RTxpLRCG/SZRDIRcvdFKh9umdwQvAzuTS0xzO8OyPw9q8 8QCCYg== >> ;; Received 1171 bytes from 192.112.36.4#53(g.root-servers.net >> ) in 207 ms >> >> arin.net .172800INNSns1.arin.net . >> arin.net .172800INNSns2.arin.net . >> arin.net .172800INNSu.arin.net . >> arin.net .172800INNSns3.arin.net . >> arin.net .86400INDS48281 5 2 >> 6EB0CCF325A8101A768C93D10CE084303D3714D4E92FEE53D6E683D2 22291017 >> arin.net .86400INDS48281 5 1 >> FCBF93357C8FE3247CECB2CD277F45EB955EE4CE >> arin.net .86400INRRSIGDS 8 2 86400 20190117062448 >> 20190110051448 6140 net. >> stuWyfC0PDuk2hNF/Bnz0lnypk+bA/slTa2KYznjmoLXDtq7v1obJq41 >> ZfloQKXuC7MnzpCQj70GU9ZESZq1/XU+u6wDmCqmEUbJ3kyrILxkVrln >> bTEySJWPmurpwUVzDVfvqFpXEOhWxOjDu6drZMcC3wG9EdPqBuFC6wlf FIQ= >> couldn't get address for 'ns1.arin.net ': not found >> couldn't get address for 'ns2.arin.net ': not found >> couldn't get address for 'u.arin.net ': not found >> couldn't get address for 'ns3.arin.net ': not found >> dig: couldn't get address for 'ns1.arin.net ': >> no more >> >> > From rsk at gsp.org Fri Jan 11 17:17:09 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 11 Jan 2019 12:17:09 -0500 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> Message-ID: <20190111171709.GA29449@gsp.org> On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote: > * no HTTPS HTTPS isn't needed for this application. I'll probably add it anyway when I have a chance, but there are other things ahead of it. > * archive is returning HTTP 403 That is exactly what you should expect to see when a Mailman archive is empty, as it is for any new mailing list. Now it's not. So now you won't. ---rsk From rsk at gsp.org Fri Jan 11 17:20:22 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 11 Jan 2019 12:20:22 -0500 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190110165703.44EB039837D2@DataIX.net> References: <20190110162220.GA7854@gsp.org> <20190110165703.44EB039837D2@DataIX.net> Message-ID: <20190111172022.GB29449@gsp.org> On Thu, Jan 10, 2019 at 10:57:02AM -0600, J. Hellenthal via NANOG wrote: > Unfortunately I don???t see this as having very much connectivity where I am at. It's not the best-connected or most powerful server, however it's been running a bunch of public/private mailing lists for many years and for that purpose, it's sufficed nicely. (That's one of the many major advantages of mailing lists over web forums: they don't need much in the way of connectivity, bandwidth, or horsepower.) Sure, I'd like to have bigger/better/faster/more, but since I'm paying for this out of my own pocket... ---rsk From ximaera at gmail.com Fri Jan 11 17:58:25 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 11 Jan 2019 20:58:25 +0300 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190110162220.GA7854@gsp.org> References: <20190110162220.GA7854@gsp.org> Message-ID: Thank you! Forwarded that to the RIPE IoT WG. 10 Jan. 2019 г., 19:23 Rich Kulawiec : > The "dumpsterfire" mailing list is for the discussion of security and > privacy issues related to the IoT (Internet of Things). Arguably, > the entire IoT *is* a security and privacy issue, but we'll get to that > in good time. > > If you want to join, you can either use the list's web page: > > http://www.firemountain.net/mailman/listinfo/dumpsterfire > > or the list's subscription/unsubscription address: > > dumpsterfire-request at firemountain.net > > The list is public and so is its archive. > > ---rsk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Jan 11 18:03:20 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Jan 2019 04:03:20 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190111180320.5D994C44B7@thyme.apnic.net> 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-stats at 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 12 Jan, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 733674 Prefixes after maximum aggregation (per Origin AS): 282062 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 353352 Total ASes present in the Internet Routing Table: 62885 Prefixes per ASN: 11.67 Origin-only ASes present in the Internet Routing Table: 54196 Origin ASes announcing only one prefix: 23519 Transit ASes present in the Internet Routing Table: 8689 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 23 Number of instances of unregistered ASNs: 25 Number of 32-bit ASNs allocated by the RIRs: 25439 Number of 32-bit ASNs visible in the Routing Table: 20634 Prefixes from 32-bit ASNs in the Routing Table: 89143 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 288 Number of addresses announced to Internet: 2841162851 Equivalent to 169 /8s, 88 /16s and 180 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 245674 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 199728 Total APNIC prefixes after maximum aggregation: 57048 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 196822 Unique aggregates announced from the APNIC address blocks: 81412 APNIC Region origin ASes present in the Internet Routing Table: 9352 APNIC Prefixes per ASN: 21.05 APNIC Region origin ASes announcing only one prefix: 2635 APNIC Region transit ASes present in the Internet Routing Table: 1395 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4356 Number of APNIC addresses announced to Internet: 769082882 Equivalent to 45 /8s, 215 /16s and 70 /24s APNIC AS Blocks 4608-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: 217169 Total ARIN prefixes after maximum aggregation: 103060 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 216418 Unique aggregates announced from the ARIN address blocks: 103683 ARIN Region origin ASes present in the Internet Routing Table: 18314 ARIN Prefixes per ASN: 11.82 ARIN Region origin ASes announcing only one prefix: 6811 ARIN Region transit ASes present in the Internet Routing Table: 1845 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2538 Number of ARIN addresses announced to Internet: 1079462304 Equivalent to 64 /8s, 87 /16s and 73 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 201112 Total RIPE prefixes after maximum aggregation: 95726 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 197454 Unique aggregates announced from the RIPE address blocks: 116555 RIPE Region origin ASes present in the Internet Routing Table: 25737 RIPE Prefixes per ASN: 7.67 RIPE Region origin ASes announcing only one prefix: 11482 RIPE Region transit ASes present in the Internet Routing Table: 3615 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7720 Number of RIPE addresses announced to Internet: 716067520 Equivalent to 42 /8s, 174 /16s and 82 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 95416 Total LACNIC prefixes after maximum aggregation: 22002 LACNIC Deaggregation factor: 4.34 Prefixes being announced from the LACNIC address blocks: 96820 Unique aggregates announced from the LACNIC address blocks: 42306 LACNIC Region origin ASes present in the Internet Routing Table: 7964 LACNIC Prefixes per ASN: 12.16 LACNIC Region origin ASes announcing only one prefix: 2166 LACNIC Region transit ASes present in the Internet Routing Table: 1486 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5513 Number of LACNIC addresses announced to Internet: 173145344 Equivalent to 10 /8s, 81 /16s and 253 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 20225 Total AfriNIC prefixes after maximum aggregation: 4208 AfriNIC Deaggregation factor: 4.81 Prefixes being announced from the AfriNIC address blocks: 25872 Unique aggregates announced from the AfriNIC address blocks: 9135 AfriNIC Region origin ASes present in the Internet Routing Table: 1236 AfriNIC Prefixes per ASN: 20.93 AfriNIC Region origin ASes announcing only one prefix: 425 AfriNIC Region transit ASes present in the Internet Routing Table: 245 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 20 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 507 Number of AfriNIC addresses announced to Internet: 102989312 Equivalent to 6 /8s, 35 /16s and 126 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4645 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4622 519 520 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3044 1160 91 VIETEL-AS-AP Viettel Group, VN 45899 2990 1721 112 VNPT-AS-VN VNPT Corp, VN 4766 2810 11129 767 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2465 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2405 4906 29 CTTNET China TieTong Telecommunications 4755 2143 437 181 TATACOMM-AS TATA Communications formerl 17974 2088 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3511 1326 92 SHAW - Shaw Communications Inc., CA 11492 3486 225 599 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2608 5389 982 AMAZON-02 - Amazon.com, Inc., US 16625 2210 1233 1699 AKAMAI-AS - Akamai Technologies, Inc., 20115 2150 2754 533 CHARTER-20115 - Charter Communications, 18566 2136 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2101 350 134 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2087 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2074 5077 589 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5277 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3290 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2635 575 1936 AKAMAI-ASN1, US 12389 2228 2221 626 ROSTELECOM-AS, RU 34984 2055 338 523 TELLCOM-AS, TR 9121 1736 1691 17 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 8402 1301 545 15 CORBINA-AS OJSC "Vimpelcom", RU 9009 1242 135 695 M247, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5494 3319 592 Uninet S.A. de C.V., MX 10620 3150 475 905 Telmex Colombia S.A., CO 11830 2679 371 71 Instituto Costarricense de Electricidad 6503 1631 449 54 Axtel, S.A.B. de C.V., MX 7303 1441 961 226 Telecom Argentina S.A., AR 28573 1184 2239 183 CLARO S.A., BR 6147 1084 377 29 Telefonica del Peru S.A.A., PE 3816 1026 511 112 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 935 143 66 Alestra, S. de R.L. de C.V., MX 13999 928 535 250 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1162 393 22 LINKdotNET-AS, EG 37611 902 107 9 Afrihost, ZA 36903 797 401 139 MT-MPLS, MA 36992 780 1411 44 ETISALAT-MISR, EG 24835 683 634 21 RAYA-AS, EG 8452 635 1731 19 TE-AS TE-AS, EG 29571 481 70 12 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 15399 417 45 11 WANANCHI-, KE 37342 410 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5494 3319 592 Uninet S.A. de C.V., MX 12479 5277 1628 138 UNI2-AS, ES 4538 4645 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4622 519 520 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3511 1326 92 SHAW - Shaw Communications Inc., CA 11492 3486 225 599 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3290 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3150 475 905 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5277 5139 UNI2-AS, ES 4538 4645 4571 ERX-CERNET-BKB China Education and Research Net 7545 4622 4102 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3511 3419 SHAW - Shaw Communications Inc., CA 8551 3290 3247 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3310 3136 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3044 2953 VIETEL-AS-AP Viettel Group, VN 11492 3486 2887 CABLEONE - CABLE ONE, INC., US 45899 2990 2878 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 4200058511 PRIVATE 103.111.177.0/24 137522 OERL-AS-AP Origin Energy Retai 4200058511 PRIVATE 103.111.178.0/24 137522 OERL-AS-AP Origin Energy Retai 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.83.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:36 /11:99 /12:292 /13:568 /14:1129 /15:1916 /16:13354 /17:7872 /18:13845 /19:25525 /20:39678 /21:46133 /22:91220 /23:74692 /24:414403 /25:924 /26:822 /27:883 /28:32 /29:18 /30:9 /31:2 /32:200 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4127 5277 UNI2-AS, ES 6327 3274 3511 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2764 3486 CABLEONE - CABLE ONE, INC., US 8551 2746 3290 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2550 3310 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2031 2136 MEGAPATH5-US - MegaPath Corporation, US 11830 2024 2679 Instituto Costarricense de Electricidad y Telec 30036 1849 2101 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2087 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1613 2:894 3:1 4:23 5:2776 6:43 7:1 8:1176 12:1874 13:306 14:1876 15:37 16:2 17:215 18:59 20:48 23:2566 24:2415 25:2 27:2551 31:2014 32:92 35:31 36:822 37:3006 38:1606 39:283 40:122 41:3153 42:726 43:2006 44:140 45:6525 46:3150 47:244 49:1332 50:1083 51:319 52:1081 54:363 55:1 56:6 57:41 58:1714 59:1071 60:456 61:2079 62:2206 63:1813 64:5101 65:2193 66:4817 67:2684 68:1170 69:3455 70:1145 71:601 72:2281 74:2750 75:415 76:543 77:1718 78:1747 79:2323 80:1647 81:1432 82:1068 83:878 84:1080 85:2139 86:562 87:1536 88:994 89:2398 90:213 91:6540 92:1224 93:2381 94:2401 95:3190 96:908 97:349 98:939 99:169 100:87 101:1157 102:339 103:19758 104:3573 105:243 106:895 107:1826 108:697 109:3634 110:1637 111:1867 112:1398 113:1379 114:1154 115:1709 116:1622 117:1915 118:2199 119:1684 120:1056 121:1030 122:2368 123:1640 124:1446 125:1953 128:1196 129:691 130:525 131:1622 132:716 133:213 134:1043 135:230 136:541 137:676 138:1977 139:796 140:566 141:762 142:802 143:1010 144:896 145:504 146:1246 147:774 148:1704 149:805 150:782 151:1000 152:975 153:325 154:2435 155:969 156:1640 157:859 158:656 159:1903 160:1492 161:898 162:2663 163:774 164:1118 165:1581 166:462 167:1364 168:3234 169:872 170:4039 171:497 172:1059 173:2146 174:1003 175:878 176:2290 177:4052 178:2567 179:1295 180:2089 181:2355 182:2678 183:1057 184:1136 185:14558 186:3714 187:2515 188:2976 189:2104 190:8270 191:1438 192:10038 193:6500 194:5334 195:4033 196:2913 197:1724 198:5696 199:5963 200:7395 201:5028 202:10188 203:10176 204:4635 205:3017 206:3301 207:3283 208:3945 209:4225 210:3917 211:1994 212:3081 213:2805 214:1067 215:52 216:5973 217:2188 218:889 219:575 220:1835 221:995 222:978 223:1427 End of report From andreas at naund.org Fri Jan 11 18:11:36 2019 From: andreas at naund.org (Andreas Ott) Date: Fri, 11 Jan 2019 10:11:36 -0800 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190111171709.GA29449@gsp.org>; from rsk@gsp.org on Fri, Jan 11, 2019 at 12:17:09PM -0500 References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> Message-ID: <20190111101136.A998@naund.org> On Fri, Jan 11, 2019 at 12:17:09PM -0500, Rich Kulawiec wrote: > On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote: > > * no HTTPS > > HTTPS isn't needed for this application. I'll probably add it anyway > when I have a chance, but there are other things ahead of it. I respectfully disagree: http://www.firemountain.net/mailman/options/dumpsterfire/bofh at example.com asks for a "password" which is then transported over clear text. The year is 2019 and there's always letsencrypt SSL certs. Admittedly, mailman does send you the password in clear text over SMTP if you ask for it. -andreas To borrow a quote: The 'S' in IoT stands for 'Security'. From randy at psg.com Fri Jan 11 18:16:53 2019 From: randy at psg.com (Randy Bush) Date: Fri, 11 Jan 2019 10:16:53 -0800 Subject: Dnssec still inoperable on the internet =?ISO-2022-JP?B?Pw==?= =?ISO-2022-JP?B?GyRCIT0bKEI=?= was ARIN NS down? In-Reply-To: <2d8658c1-1f7c-c35c-7550-63a30e9b376b@netassist.ua> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> <2d8658c1-1f7c-c35c-7550-63a30e9b376b@netassist.ua> Message-ID: > It's because you see problems it causes, and do not see problems it > solves ;) > >> Thanks for the update that dnssec STILL causes more real world problems >> than it solves.  hmmm. has anyone set about to measure that? randy From daknob.mac at gmail.com Fri Jan 11 18:29:04 2019 From: daknob.mac at gmail.com (Antonios Chariton) Date: Fri, 11 Jan 2019 20:29:04 +0200 Subject: =?utf-8?Q?Re=3A_Dnssec_still_inoperable_on_the_internet_=3F?= =?utf-8?Q?=E2=80=94_was_ARIN_NS_down=3F?= In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> <2d8658c1-1f7c-c35c-7550-63a30e9b376b@netassist.ua> Message-ID: <04BAEEEE-A0B8-431A-94CC-7073A4B8DABE@gmail.com> Maybe a Report-URI for DNSSEC Validation Errors? :-) > On 11 Jan 2019, at 20:16, Randy Bush wrote: > >> It's because you see problems it causes, and do not see problems it >> solves ;) >> >>> Thanks for the update that dnssec STILL causes more real world problems >>> than it solves. > > hmmm. has anyone set about to measure that? > > randy From swmike at swm.pp.se Fri Jan 11 18:54:28 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 11 Jan 2019 19:54:28 +0100 (CET) Subject: =?UTF-8?Q?Re=3A_Dnssec_still_inoperable_on_the_internet_=3F=E2=80=94_was_ARIN_NS_down=3F?= In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Message-ID: On Fri, 11 Jan 2019, Ca By wrote: > Thanks for the update that dnssec STILL causes more real world problems > than it solves. Do you feel the same way about RPKI? -- Mikael Abrahamsson email: swmike at swm.pp.se From rob at invaluement.com Fri Jan 11 19:32:17 2019 From: rob at invaluement.com (Rob McEwen) Date: Fri, 11 Jan 2019 14:32:17 -0500 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190111101136.A998@naund.org> References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> Message-ID: On 1/11/2019 1:11 PM, Andreas Ott wrote: > Admittedly, mailman does > send you the password in clear text over SMTP if you ask for it  but if done right, fwiw,, wouldn't that be sent over SMTP using TLS encryption? (but, then again, that ALSO requires a certificate!) -- Rob McEwen, invaluement From cb.list6 at gmail.com Fri Jan 11 19:33:56 2019 From: cb.list6 at gmail.com (Ca By) Date: Fri, 11 Jan 2019 11:33:56 -0800 Subject: =?UTF-8?Q?Re=3A_Dnssec_still_inoperable_on_the_internet_=3F=E2=80=94_was?= =?UTF-8?Q?_ARIN_NS_down=3F?= In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <4800B579-879C-4D7B-A0C6-E72AB25B70EF@istaff.org> Message-ID: On Fri, Jan 11, 2019 at 10:54 AM Mikael Abrahamsson wrote: > On Fri, 11 Jan 2019, Ca By wrote: > > > Thanks for the update that dnssec STILL causes more real world problems > > than it solves. > > Do you feel the same way about RPKI? > Misorgination is a real threat we see all the time (threat on uptime, if not more) That said, i think history has shown we get more kilometers out of good BGP policy control hygiene and IRR data than RPKI. I don’t think that will change in the future. I do wish irr data was better, for many values of better. My routes are rpki signed. But, my router kit and ops procedure don’t make me enforcing near-term achievable. > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Fri Jan 11 19:36:05 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 11 Jan 2019 22:36:05 +0300 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> Message-ID: 11 Jan. 2019 г., 22:33 Rob McEwen : > but if done right, fwiw,, wouldn't that > be sent over SMTP using TLS encryption So STARTTLS strip is not a problem anymore? -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Fri Jan 11 19:50:06 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 11 Jan 2019 12:50:06 -0700 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> Message-ID: <1ab1783a-8dda-71c6-eddf-68d22ab6f06c@spamtrap.tnetconsulting.net> On 01/11/2019 12:32 PM, Rob McEwen wrote: > but if done right, fwiw,, wouldn't that be sent over SMTP using TLS > encryption? Oy vey. in-flight vs at-rest encryption. > (but, then again, that ALSO requires a certificate!) Let's Encrypt works perfectly fine for that too. }:-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From bryan at shout.net Fri Jan 11 20:05:49 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 11 Jan 2019 14:05:49 -0600 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190111101136.A998@naund.org> References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> Message-ID: On 1/11/19 12:11 PM, Andreas Ott wrote: > On Fri, Jan 11, 2019 at 12:17:09PM -0500, Rich Kulawiec wrote: >> On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote: >>> * no HTTPS >> >> HTTPS isn't needed for this application. I'll probably add it anyway >> when I have a chance, but there are other things ahead of it. > > I respectfully disagree: > > http://www.firemountain.net/mailman/options/dumpsterfire/bofh at example.com > > asks for a "password" which is then transported over clear text. The year > is 2019 and there's always letsencrypt SSL certs. Admittedly, mailman does > send you the password in clear text over SMTP if you ask for it. > > > -andreas > > To borrow a quote: The 'S' in IoT stands for 'Security'. > I thought it stood for ZEPPELIN. From amitchell at isipp.com Fri Jan 11 20:18:28 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 11 Jan 2019 13:18:28 -0700 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <20190110165703.44EB039837D2@DataIX.net> References: <20190110162220.GA7854@gsp.org> <20190110165703.44EB039837D2@DataIX.net> Message-ID: Additionally, subscribe mail to the email address is bouncing. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification http://www.SuretyMail.com/ Certified Sender DNSBL here: iadb.isipp.com Info here: https://www.isipp.com/email-accreditation/for-isps/ GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting > On Jan 10, 2019, at 9:57 AM, J. Hellenthal via NANOG wrote: > > Unfortunately I don’t see this as having very much connectivity where I am at. > > host firemountain.net > firemountain.net has address 207.114.3.55 > firemountain.net mail is handled by 10 taos.firemountain.net. > firemountain.net mail is handled by 20 ukiah.firemountain.net. > > host www.firemountain.net > www.firemountain.net has address 207.114.3.55 > > Sending 5, 100-byte ICMP Echos to 207.114.3.55, timeout is 2 seconds: > !.... > Success rate is 20 percent (1/5), round-trip min/avg/max = 51/51/51 ms > > Tracing the route to firemountain.net (207.114.3.55) > > 1 0 msec 0 msec 0 msec > 2 142.254.152.249 9 msec 9 msec 17 msec > 3 ae62.nwblwi1801h.midwest.rr.com (24.164.241.145) 16 msec 16 msec 9 msec > 4 be63.milzwift01r.midwest.rr.com (65.31.112.122) 25 msec 16 msec 17 msec > 5 be40.clmkohpe01r.midwest.rr.com (65.25.137.109) 25 msec 25 msec 34 msec > 6 be1.clmkohpe02r.midwest.rr.com (65.29.1.35) 34 msec 34 msec 25 msec > 7 ae1.uparohgd01h.midwest.rr.com (24.33.161.209) 34 msec 42 msec 25 msec > 8 69.23.10.160 34 msec 25 msec 25 msec > 9 rrcs-98-102-146-106.central.biz.rr.com (98.102.146.106) 25 msec 34 msec 25 msec > 10 xe-0-0-0.upa-core1.expedient.com (66.230.78.130) 33 msec 34 msec 25 msec > 11 et-0-2-0.acm-core2.expedient.com (209.166.144.209) 34 msec 34 msec 34 msec > 12 irb-4038.acm-core1.expedient.com (209.166.144.21) 33 msec 33 msec 25 msec > 13 et-3-0-0.152-core2.expedient.com (66.230.78.194) 33 msec 33 msec 34 msec > 14 ae2.152-core1.expedient.com (66.230.78.161) 42 msec 34 msec 34 msec > 15 xe-0-3-0.fil-node.expedient.com (206.210.75.234) 42 msec 42 msec 51 msec > 16 xe-0-3-0.1sc-node.expedient.com (216.230.108.246) 50 msec 42 msec 59 msec > 17 ten1-6-2.tdp-core.expedient.com (216.230.108.229) 42 msec 42 msec 50 msec > 18 firemountain.net (207.114.3.55) 50 msec 42 msec 51 msec > > > HTH > >> On Jan 10, 2019, at 10:22, Rich Kulawiec wrote: >> >> The "dumpsterfire" mailing list is for the discussion of security and >> privacy issues related to the IoT (Internet of Things). Arguably, >> the entire IoT *is* a security and privacy issue, but we'll get to that >> in good time. >> >> If you want to join, you can either use the list's web page: >> >> http://www.firemountain.net/mailman/listinfo/dumpsterfire >> >> or the list's subscription/unsubscription address: >> >> dumpsterfire-request at firemountain.net >> >> The list is public and so is its archive. >> >> ---rsk > > > — > > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > > > > > From marka at isc.org Fri Jan 11 20:19:07 2019 From: marka at isc.org (Mark Andrews) Date: Sat, 12 Jan 2019 07:19:07 +1100 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> Message-ID: <94825BE0-8015-4B79-9B23-250219C5A3A8@isc.org> > On 12 Jan 2019, at 6:36 am, Töma Gavrichenkov wrote: > > 11 Jan. 2019 г., 22:33 Rob McEwen : > > but if done right, fwiw,, wouldn't that > > be sent over SMTP using TLS encryption > > So STARTTLS strip is not a problem anymore? If you deploy DANE (client and server sides) then stripping STARTTLS is ineffective for the target domain. We (isc.org) have but gmail.com hasn’t (server side at least). On could be asking why you are using gmail.com when they don’t care enough to signal to the world that STARTTLS is supported and should be there in the EHLO. % dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4910 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: bfabca20a2ed6fe032fae4e75c38f7eecca21769def0a3e3 (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org. 7140 IN MX 20 mx.ams1.isc.org. isc.org. 7140 IN MX 10 mx.pao1.isc.org. isc.org. 7140 IN RRSIG MX 5 2 7200 20190206233314 20190107233314 19923 isc.org. UBu26XwokUyCwZvBzp5+kajy686RF4cdA/Un3Z3vtEARG8qx0hQfHoTk lGfGPkt21QdZmqX+ZJcdO3LfA+qU9A3aEJMXZi9aMZkPDWu1aPsJBu6U 3U3Tj9j+DsqL2Uk780TAqQQQWFUwIHF+y0hcRIWPaqUuvygl/5jxdVDN Mls= ;; ADDITIONAL SECTION: mx.pao1.isc.org. 3541 IN A 149.20.64.53 mx.ams1.isc.org. 3544 IN A 199.6.1.65 mx.pao1.isc.org. 3541 IN AAAA 2001:4f8:0:2::2b mx.ams1.isc.org. 3544 IN AAAA 2001:500:60::65 mx.pao1.isc.org. 3541 IN RRSIG A 5 4 3600 20190206233333 20190107233333 13902 pao1.isc.org. WrDcCGC0SmNUSh+DBxogVXWU2PQVpJ/6S/WJxpU4fLDpI+0J85aep+e1 NwZRUuw9N5RRuslQSz0y+aiwB0RACq2wbPUxDem21KpzKE8rlrAlf0U9 k9sT1PeCkWu7QOiWgEksnoJijyCVY41Q/GB0HnWzaO4jUtay6e/PBj4c IiA= mx.pao1.isc.org. 3541 IN RRSIG AAAA 5 4 3600 20190206233333 20190107233333 13902 pao1.isc.org. EaYgxAGrmJ9oiX4u2DfIcHKCqen3RNGylmWT0VjJ8VWY5e/c5TA1eI5U evGsvYhvLD4WvR8hzvKxp4Pc5EYKLoB+YRI4ttUgnTydsEI0xFCcgB4+ dFb+89h8e6tHSPhUa1wa7ObriKm1O5FzplEXLfNFbgEUN6oJOIMw7q8w cC8= _25._tcp.mx.pao1.isc.org. 3543 IN RRSIG TLSA 5 6 3600 20190206233333 20190107233333 13902 pao1.isc.org. liSDcLgGpDXqgTxkv2sQBI3OsACPflpxoZxcrgSge4yTe5gA97NOPe0l ECmDBPzUkhcRI6Mwv+uBCmm5FBvgh0leNxLXzACdkCX8EscE3v74wd5o ReCRGFAhV6TBjycwejkGARVTYF23RyRflq2/fRV2hoOdH2ImcW7/SMqA 8Jg= mx.ams1.isc.org. 3544 IN RRSIG A 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. E+6nzEbFAcftlr3UTaCcw0LAHYIdVe5TNfyIwVwU71AzZB22jiif/BrQ KxemOrR7LT7ukfDRjnEzfV1/s0Wwfxh0b79otxrDwssKzNKz9XhaIhVf j17oyuQBkYjYv5RBuwsrmKQmSbu56Zu7G35xp2qbKi6E+3lpXPghnrnJ DBk= mx.ams1.isc.org. 3544 IN RRSIG AAAA 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. ov/6HUTx8v7t31KBYVgDy02Bpe8rJX431vPDdRZvKKhffFrYmUOIXEqD Q/3+DNV1axSJCTONJ1NwzoSC8LDwQQFUcAsXnhcW/C/Z3rbaEthetmmP TERuRGjF3QdA+qFM8RCc83s+hp1RXo5cU+9wA8OTPT5nTmfthkDs/cUi 0o8= _25._tcp.mx.ams1.isc.org. 3545 IN RRSIG TLSA 5 6 3600 20190206233315 20190107233315 5730 ams1.isc.org. qdzOyIbkPhufqw6/B5bwpxJ0pfVeUay2v8O5spUa+xgHdLQFNS851vlW KOYrNfZALDomXkOyfAVTEZXQ1g3xf0gzIcRCy0PHcgDtgl5a56AilFGB n6LZVkh6lbAkQ8lSmlKWmOvAmJnXh6L6dX8/CQzpWT7G0EEL1EcvLW6p uZ0= _25._tcp.mx.pao1.isc.org. 3543 IN TLSA 3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0 _25._tcp.mx.ams1.isc.org. 3545 IN TLSA 3 0 1 5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916 ;; Query time: 7 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 12 07:09:18 AEDT 2019 ;; MSG SIZE rcvd: 1555 % > -- > Töma -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ximaera at gmail.com Fri Jan 11 20:50:44 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 11 Jan 2019 23:50:44 +0300 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <94825BE0-8015-4B79-9B23-250219C5A3A8@isc.org> References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> <94825BE0-8015-4B79-9B23-250219C5A3A8@isc.org> Message-ID: 11 Jan. 2019 г., 23:19 Mark Andrews : >> So STARTTLS strip is not a problem anymore? > > If you deploy DANE (client and server > sides) then stripping STARTTLS is > ineffective for the target domain. If you defer to send (and finally bounce) everything targeted at a domain that fails TLSA lookup, then fair enough. I don't think this is (and is going to be in the near future) the case for the dumpsterfire mailing list, but you may rightfully assume I haven't checked yet. > gmail.com hasn’t (server side at least). Google folks are on this mailing list, so it's best if they speak for me (though I believe I pretry much know their reasoning). -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jan 11 20:59:10 2019 From: jcurran at arin.net (John Curran) Date: Fri, 11 Jan 2019 20:59:10 +0000 Subject: =?utf-8?B?MjAxOS0wMS0xMSBBUklOLk5FVCBETlNTRUMgT3V0YWdlIOKAkyBQb3N0LU1v?= =?utf-8?Q?rtem_(was:_Re:_ARIN_NS_down=3F)?= In-Reply-To: <3DD245D6-A005-4FC8-A6B9-4B81F6512D85@arin.net> References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <20190111143753.6lxcpaxxpg2h2vfe@nic.fr> <3DD245D6-A005-4FC8-A6B9-4B81F6512D85@arin.net> Message-ID: On 11 Jan 2019, at 10:39 AM, John Curran > wrote: On Fri, Jan 11, 2019 at 07:57:25PM +0530, couldn't get address for 'ns1.arin.net': not found Folks - This has been resolved - arin.net zone is again correctly signed. Post-mortem forthcoming, Folks - The ARIN.NET zone on our public signed DNS servers are populated via an internal DNS server and associated workflow. As part of system maintenance near the end of 2018, the zone file used by the master internal DNS server was updated incorrectly, resulting in an invalid zone file. Since the zone file was invalid, the zone did not reload on our internal master, and the associated workflow to DNSSEC sign and push this zone to the public servers did not execute. Our monitoring systems reported being green until the signatures expired as they presently check that the SOA's match on the internal and external nameservers. At approximately 8:30AM eastern time today (11 January 2019), ARIN operations started seeing issues within its monitoring. Initial review suggested the problem was DNSSEC-related due to expired signatures. We pulled the DS record from the zone so that DNSSEC validation would not be performed by those validating resolvers that had not already cached our DS records. Upon further investigation we determined that it was the result of human error in editing a zone file that went undetected and resulted in interruption of our routine zone publication process. The issue was fixed and signed zones where then pushed out at 10:25 AM ET. The DS record was reinstated in the parent at 10:30AM ET. As a result of this incident, we will add additional alerting to the zone loading process for any errors and perform monitoring of zone signature lifetimes, with appropriate alerting for any potential expiration of DNSSEC signatures. My apologies for this incident – while ARIN does have some fragility in our older systems (which we have been working aggressively to phase out via system refresh and replacements), it is not acceptable to have this situation with key infrastructure such as our DNS zones. We will prioritize the necessary alert and monitor changes and I will report back to the community once that has been completed. Thank you for your patience in this regard. /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton.mielke at gmail.com Fri Jan 11 21:39:09 2019 From: clinton.mielke at gmail.com (cosmo) Date: Fri, 11 Jan 2019 13:39:09 -0800 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> <94825BE0-8015-4B79-9B23-250219C5A3A8@isc.org> Message-ID: Whaddya expect guys, the mailing list is hosted on an embedded DVR recorder On Fri, Jan 11, 2019 at 12:52 PM Töma Gavrichenkov wrote: > 11 Jan. 2019 г., 23:19 Mark Andrews : > >> So STARTTLS strip is not a problem anymore? > >> > > If you deploy DANE (client and server > > sides) then stripping STARTTLS is > > ineffective for the target domain. > > If you defer to send (and finally bounce) everything targeted at a domain > that fails TLSA lookup, then fair enough. I don't think this is (and is > going to be in the near future) the case for the dumpsterfire mailing list, > but you may rightfully assume I haven't checked yet. > > > gmail.com hasn’t (server side at least). > > Google folks are on this mailing list, so it's best if they speak for me > (though I believe I pretry much know their reasoning). > > -- > Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Fri Jan 11 17:38:21 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Fri, 11 Jan 2019 23:08:21 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] Message-ID: Hello NANOG, Belated new year wishes. I would like to gather some feedback from you all. I'm trying to propose two things to the Internet Standard and it's related to SMTP. (1) STARTTLS downgrade protection in a dead simple way (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. I posted my proposal in IETF mailing list. I got very good feedback there. Some support my proposal. Many are against it. I would love to know where you stand on this proposal. Let me give you the abstract first. ----- SMTP is still suffering from downgrade attacks like STRIPTLS. While we have "Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP. Don't take this in the wrong way. We do have "Implicit TLS" for "SMTP Submission" on port 465. But we don't have a secure port 25 alternative. i.e. The real SMTPS Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue. However the implementation is not simple. The former requires a HTTPS server and the latter requires DNSSEC to even get started. This proposal fixes STARTTLS downgrade issue and propose a new port 26, an "Implicit TLS" alternative for port 25 and recommends the MX server to signal the port via a prefix. This proposal offers two ways. (1) STARTTLS Prefix Use this prefix only to deal with STARTTLS downgrade issue. e.g. mx1.example.com should be prefixed like starttls-mx1.example.com. Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection". (2) SMTPS Prefix Use this prefix if you wanna support Implicit TLS on port 26 and Opportunistic TLS on port 25. e.g. mx1.example.com should be prefixed like smtps-mx1.example.com. Where "smtps-" says "We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25. And our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection". In "starttls-" prefix port 25 *MUST* support encryption with *valid SSL* certificates. In "smtps-" prefix, *BOTH* port 26 and port 25 *MUST* support encryption with *valid SSL* certificates. Note: You need to enable DNSSEC to prevent MX record spoofing. My proposal highly recommends DNSSEC. Not mandates that. ------- What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port." What I think? - Implicit TLS still fall under the "best practices". So it will send out the positive vibe that IETF still cares about email security. What the world thinks? - https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f What do you all think? - https://medium.com/@dombox/smtp-over-tls-on-port-26-efc67e8a99ce -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Sat Jan 12 00:50:17 2019 From: mike at mtcc.com (Michael Thomas) Date: Fri, 11 Jan 2019 16:50:17 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <40ef84a9-e456-8ebb-fcfb-7728559c598e@mtcc.com> Having been through this many times, I'd say that probably the best way to advocate for something is to advocate for what the *problem* is much more than what the *solution* is. Invariably, things are more complex than we imagine in the solution space and the people who inhabit that space are more than happy to inform you of it. Writing an I-D on what the problem is can be a very useful exercise to rally support without putting on a bullseye on your back about a solution. I will say that downgrade attacks are taken seriously by the security geeks I know. But everything is messy, especially with something as ancient as email so listening is a virtue too. Which isn't so say that running code is bad -- it's one of the best things about ietf -- but people have to understand why it's running at all :) Mike, one of the authors of rfc 4871 On 1/11/19 9:38 AM, Viruthagiri Thirumavalavan wrote: > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's > related to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > I posted my proposal in IETF mailing list. I got very good feedback > there. Some support my proposal. Many are against it. > > I would love to know where you stand on this proposal. Let me give you > the abstract first. > > ----- > > SMTP is still suffering from downgrade attacks like STRIPTLS. While we > have "Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP. > > Don't take this in the wrong way. We do have "Implicit TLS" for "SMTP > Submission" on port 465. But we don't have a secure port 25 > alternative. i.e. The real SMTPS > > Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue. > However the implementation is not simple. The former requires a HTTPS > server and the latter requires DNSSEC to even get started. > > This proposal fixes STARTTLS downgrade issue and propose a new port > 26, an "Implicit TLS" alternative for port 25 and recommends the MX > server to signal the port via a prefix. > > This proposal offers two ways. > > (1) STARTTLS Prefix > > Use this prefix only to deal with STARTTLS downgrade issue. > > e.g. mx1.example.com should be prefixed like > starttls-mx1.example.com . > > Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if > STARTTLS command not found in the EHLO response or certificate is > invalid, then drop the connection". > > (2) SMTPS Prefix > > Use this prefix if you wanna support Implicit TLS on port 26 and > Opportunistic TLS on port 25. > > e.g. mx1.example.com should be prefixed like > smtps-mx1.example.com . > > Where "smtps-" says "We prefer if you connect to our SMTPS in port 26. > But we also accept mails in port 25. And our port 25 supports > Opportunistic TLS. So if STARTTLS command not found in the EHLO > response or certificate is invalid, then drop the connection". > > In "starttls-" prefix port 25 *MUST* support encryption with *valid > SSL* certificates. > > In "smtps-" prefix, *BOTH* port 26 and port 25 *MUST* support > encryption with *valid SSL* certificates. > > Note: You need to enable DNSSEC to prevent MX record spoofing. My > proposal highly recommends DNSSEC. Not mandates that. > > ------- > > What IETF Mailing list thinks? - "Implicit TLS doesn't offer any > additional security than a downgrade protected STARTTLS. Let's not > waste a port." > > What I think? - Implicit TLS still fall under the "best practices". So > it will send out the positive vibe that IETF still cares about email > security. > > What the world thinks? - > https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f > > What do you all think? - > https://medium.com/@dombox/smtp-over-tls-on-port-26-efc67e8a99ce > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglasroyer at gmail.com Sat Jan 12 01:04:43 2019 From: douglasroyer at gmail.com (Doug Royer) Date: Fri, 11 Jan 2019 18:04:43 -0700 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <9bb0f1ca-3a16-81fa-82f9-7da03aee6c36@gmail.com> On 1/11/19 10:38 AM, Viruthagiri Thirumavalavan wrote: > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's > related to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > I posted my proposal in IETF mailing list. I got very good feedback > there. Some support my proposal. Many are against it. > What is the IETF draft name? Which IETF mailing list did this discussion happen on? -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer at gmail.com 714-989-6135 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4000 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Sat Jan 12 01:41:12 2019 From: bill at herrin.us (William Herrin) Date: Fri, 11 Jan 2019 17:41:12 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, Jan 11, 2019 at 4:22 PM Viruthagiri Thirumavalavan wrote: > What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port." In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so. > e.g. mx1.example.com should be prefixed like smtps-mx1.example.com. I'm not a fan over overloading semantic information in part of a protocol where it doesn't belong, That's dug us in to a lot of deep holes over the years. If you want to do this, seek a new DNS record type or do like everybody else and create a TXT record to inform internet peers of the availability of your new semantics for port 25. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Sat Jan 12 02:00:14 2019 From: bill at herrin.us (William Herrin) Date: Fri, 11 Jan 2019 18:00:14 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan wrote: >> In addition, it bypasses all the security folks have built around the >> idea of blocking port 25 traffic from sources which should not be >> operating as mail servers. Let's not make the network less secure in >> the name of making it more so. > > I already addressed this issue in the "security considerations" section. > > "Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary." While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From giri at dombox.org Sat Jan 12 01:21:18 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 06:51:18 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <9bb0f1ca-3a16-81fa-82f9-7da03aee6c36@gmail.com> References: <9bb0f1ca-3a16-81fa-82f9-7da03aee6c36@gmail.com> Message-ID: Hello Doug, it's happening in ietf-smtp. This is my first proposal. So haven't created the I-D yet. I'm not sure how to create one. That's why I published my proposal in the medium. Please see the medium link I posted earlier. Thanks. On Sat, Jan 12, 2019, 6:46 AM Doug Royer On 1/11/19 10:38 AM, Viruthagiri Thirumavalavan wrote: > > Hello NANOG, Belated new year wishes. > > > > I would like to gather some feedback from you all. > > > > I'm trying to propose two things to the Internet Standard and it's > > related to SMTP. > > > > (1) STARTTLS downgrade protection in a dead simple way > > > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > > > I posted my proposal in IETF mailing list. I got very good feedback > > there. Some support my proposal. Many are against it. > > > > What is the IETF draft name? > Which IETF mailing list did this discussion happen on? > > -- > > Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) > DouglasRoyer at gmail.com > 714-989-6135 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 01:50:21 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 07:20:21 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: > > In addition, it bypasses all the security folks have built around the > idea of blocking port 25 traffic from sources which should not be > operating as mail servers. Let's not make the network less secure in > the name of making it more so. I already addressed this issue in the "security considerations" section. "Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary." I'm not a fan over overloading semantic information in part of a > protocol where it doesn't belong, That's dug us in to a lot of deep > holes over the years. If you want to do this, seek a new DNS record > type or do like everybody else and create a TXT record to inform > internet peers of the availability of your new semantics for port 25. Yes, This suggestion came up on our discussions. On Sat, Jan 12, 2019 at 7:11 AM William Herrin wrote: > On Fri, Jan 11, 2019 at 4:22 PM Viruthagiri Thirumavalavan > wrote: > > What IETF Mailing list thinks? - "Implicit TLS doesn't offer any > additional security than a downgrade protected STARTTLS. Let's not waste a > port." > > In addition, it bypasses all the security folks have built around the > idea of blocking port 25 traffic from sources which should not be > operating as mail servers. Let's not make the network less secure in > the name of making it more so. > > > e.g. mx1.example.com should be prefixed like smtps-mx1.example.com. > > I'm not a fan over overloading semantic information in part of a > protocol where it doesn't belong, That's dug us in to a lot of deep > holes over the years. If you want to do this, seek a new DNS record > type or do like everybody else and create a TXT record to inform > internet peers of the availability of your new semantics for port 25. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 02:14:40 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 07:44:40 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: > > While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed Come on Mr. Herrin. Blocking a port is much easier than deprecating a heavily used protocol. Google stats show ~75% use IPv4. On Sat, Jan 12, 2019 at 7:30 AM William Herrin wrote: > On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan > wrote: > >> In addition, it bypasses all the security folks have built around the > >> idea of blocking port 25 traffic from sources which should not be > >> operating as mail servers. Let's not make the network less secure in > >> the name of making it more so. > > > > I already addressed this issue in the "security considerations" section. > > > > "Port 26 will be a secure alternative for Port 25. So Internet Service > Providers are adviced to take precautions to prevent email spam abuse. They > are advised to block port 26, if necessary." > > While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed. > > -Bill > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Sat Jan 12 02:25:51 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 12 Jan 2019 02:25:51 +0000 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <9bb0f1ca-3a16-81fa-82f9-7da03aee6c36@gmail.com>, Message-ID: But why do you think creating an out of band verification channel and separate port is going to work for this? There is plenty of local policy available as well to mandate that tls be negotiated with a set of allowed ciphers and prohibit others —srs ________________________________ From: NANOG on behalf of Viruthagiri Thirumavalavan Sent: Saturday, January 12, 2019 7:43 AM To: Doug Royer Cc: nanog at nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] Hello Doug, it's happening in ietf-smtp. This is my first proposal. So haven't created the I-D yet. I'm not sure how to create one. That's why I published my proposal in the medium. Please see the medium link I posted earlier. Thanks. On Sat, Jan 12, 2019, 6:46 AM Doug Royer wrote: On 1/11/19 10:38 AM, Viruthagiri Thirumavalavan wrote: > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's > related to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > I posted my proposal in IETF mailing list. I got very good feedback > there. Some support my proposal. Many are against it. > What is the IETF draft name? Which IETF mailing list did this discussion happen on? -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer at gmail.com 714-989-6135 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mureninc at gmail.com Sat Jan 12 02:48:21 2019 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 11 Jan 2019 20:48:21 -0600 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, 11 Jan 2019 at 20:01, William Herrin wrote: > > On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan > wrote: > >> In addition, it bypasses all the security folks have built around the > >> idea of blocking port 25 traffic from sources which should not be > >> operating as mail servers. Let's not make the network less secure in > >> the name of making it more so. > > > > I already addressed this issue in the "security considerations" section. > > > > "Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary." > > While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed. 100% agree. If mx1.example.com is prefixed like ip6-smtps-mx1.example.com, then mail should only be deliverable to the domain if all of ports 25, 26 and 27 support TLS with valid SSL certificates over IPv6. Why? Because I think there's too much confusion between the same ports working on both IPv4 and IPv6, and with Happy-Eyeballs, no certainty which protocol would be used; resulting in downgrade-to-IPv4 attacks in certain situations. For this reason, we should use port 27 in order to guarantee that the connection will happen iff (if-and-only-if) it can be established over IPv6, so that there's no confusion. We can then use port 26 to send out reports of mail being undeliverable over IPv6 with TLS, and port 25 to send out bounces of bounces, which still has to support opportunistic StartTLS, in case we still get TLS errors on port 26 trying to deliver the bounces over IPv4 over TLS. Does this cover every possible scenario, or does anyone think we gotta use a few more ports? Hopefully, this'll teach folks like CogentCo to get their IPv6 peering act together; especially if we get Google with Gmail and G Suite on board, and Cogent will suddenly stop getting their mails from pretty much all of their customers due to all the peering disputes with pretty much the rest of the IPv6 internet. I posted my proposal to the IPv6 zealots Slack channel. I got very good feedback there. Many support my proposal. Some are against it. C. From bill at herrin.us Sat Jan 12 02:52:23 2019 From: bill at herrin.us (William Herrin) Date: Fri, 11 Jan 2019 18:52:23 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, Jan 11, 2019 at 6:14 PM Viruthagiri Thirumavalavan wrote: >> While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed > > Come on Mr. Herrin. Hi Viruthagiri, If you don't want to face the hyperbole then don't stick your head in the sand. Unless you grossly underestimate the cost of operations change, you propose to make the spam problem worse for some nontrivial period of time. In exchange, you offer an explanation for how a new port will succeed where starttls fails that frankly doesn't hold water. Any scenario where starttls is disrupted is at least as vulnerable to a new tcp port being blocked. Your other idea of signaling via DNS that a man in the middle is present if the target SMTP server fails to support encryption could have merit. I think the specific mechanism (overloading the host name) is unwise but I'd be interested to see the concept developed further. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lists.nanog at monmotha.net Sat Jan 12 02:58:22 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 11 Jan 2019 21:58:22 -0500 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On 1/11/19 9:52 PM, William Herrin wrote: > Your other idea of signaling via DNS that a man in the middle is > present if the target SMTP server fails to support encryption could > have merit. I think the specific mechanism (overloading the host name) > is unwise but I'd be interested to see the concept developed further. If there's one takeaway I have from this thread to date, it's this. An advisory mechanism in DNS, such as via a TXT record, that says something along the lines of "We always support STARTTLS - if you can't negotiate that, then you are probably experiencing a MITM" could have merit. DANE appears to already offer this (and more), but as has been pointed out, can be complex to deploy. The downside I potentially see to this is that, if someone can MITM DNS (even if not the SMTP TCP session itself) and DNSSEC is not mandatory for this mechanism, that attacker could potentially cause a DoS against anyone they choose who does NOT support STARTTLS by falsely signaling that it is to be expected. I'm not sure how real-world of a threat that is given increasing adoption of STARTTLS, but it's definitely something to consider. -- Brandon Martin From giri at dombox.org Sat Jan 12 03:48:48 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 09:18:48 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: If you all think my prefix proposal have some merits, it still paves the way for future smtps proposals. So I have no issues with killing smtps part of my proposal. As for signalling, I'm not sure whether moving the signalling part to another record type is a good idea. Because my signalling proposal is flawed without DNSSEC as Brandon Martin pointed out. So if we move the signalling part to another record type, then we may have to deal with multiple record set signatures. Also there is one more configuration for the end user. But i'm open for suggestions. To the person who trolled me. I'm here to have some intellectual conversation. So please stop trolling me. You are an engineer. So don't behave like a teen in youtube comments section. I'm proposing these stuffs, so the world can benefit something. By trolling me, you are just killing that. To everyone else, please go easy on me. If I'm little off on something, please forgive my ignorance. The reason I'm here is because you all know these stuffs better than me. I'm here to get some feedback. If you all think opening a new port is waste of time, I'm ok with that. But if you see some benefits on Implicit TLS over Opportunistic TLS, please point that out too. Thank you for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Sat Jan 12 03:58:39 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 12 Jan 2019 03:58:39 +0000 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: , Message-ID: Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now? How much more of a problem will it be over the next year or two as older hardware is retired and new servers + software deployed, or as is more likely, people move their mail to cloud services that already do support strong ciphers for TLS? How worth solving is rhe problem - what is the return for all this effort? --srs ________________________________ From: NANOG on behalf of Viruthagiri Thirumavalavan Sent: Saturday, January 12, 2019 9:21 AM To: nanog at nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] If you all think my prefix proposal have some merits, it still paves the way for future smtps proposals. So I have no issues with killing smtps part of my proposal. As for signalling, I'm not sure whether moving the signalling part to another record type is a good idea. Because my signalling proposal is flawed without DNSSEC as Brandon Martin pointed out. So if we move the signalling part to another record type, then we may have to deal with multiple record set signatures. Also there is one more configuration for the end user. But i'm open for suggestions. To the person who trolled me. I'm here to have some intellectual conversation. So please stop trolling me. You are an engineer. So don't behave like a teen in youtube comments section. I'm proposing these stuffs, so the world can benefit something. By trolling me, you are just killing that. To everyone else, please go easy on me. If I'm little off on something, please forgive my ignorance. The reason I'm here is because you all know these stuffs better than me. I'm here to get some feedback. If you all think opening a new port is waste of time, I'm ok with that. But if you see some benefits on Implicit TLS over Opportunistic TLS, please point that out too. Thank you for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 04:15:12 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 09:45:12 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: Hello Mr. Ramasubramanian, When I originally drafted the SMTPS proposal, I thought those plaint text part before the STARTTLS command leaks some sensitive info. e.g. 220 mail.ashleymadison.com AshleyMadison ESMTP Service Ready Those text will always be transferred in plain text. So I thought Implicit TLS would prevent leaking that info. But guys in the IETF mailing list actually showed me a way to get that info. You just get the IP address from 3 way handshake and do reverse lookup / Connect to port 26 to fill the rest of the info. So a new port doesn't offer much security. And I totally I agree with them on that from my understanding of it. But I still want the future of email to adopt Implicit TLS. So someday we can kill Opportunistic TLS. I already lost the case for security. So my smtps part of the proposal not gonna fly. I'm just here to learn whether Implicit TLS can offer anything better than Opportunistic TLS that's worth wasting a port. Thanks On Sat, Jan 12, 2019 at 9:28 AM Suresh Ramasubramanian wrote: > Most new MTA implementations over the past several years default to TLS > with strong ciphers. So how much of a problem is low or no TLS right now? > > How much more of a problem will it be over the next year or two as older > hardware is retired and new servers + software deployed, or as is more > likely, people move their mail to cloud services that already do support > strong ciphers for TLS? > > How worth solving is rhe problem - what is the return for all this effort? > > --srs > > ------------------------------ > *From:* NANOG on behalf of > Viruthagiri Thirumavalavan > *Sent:* Saturday, January 12, 2019 9:21 AM > *To:* nanog at nanog.org > *Subject:* Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback > Request] > > If you all think my prefix proposal have some merits, it still paves the > way for future smtps proposals. So I have no issues with killing smtps part > of my proposal. > > As for signalling, I'm not sure whether moving the signalling part to > another record type is a good idea. > > Because my signalling proposal is flawed without DNSSEC as Brandon Martin > pointed out. > > So if we move the signalling part to another record type, then we may have > to deal with multiple record set signatures. Also there is one more > configuration for the end user. But i'm open for suggestions. > > To the person who trolled me. I'm here to have some intellectual > conversation. So please stop trolling me. You are an engineer. So don't > behave like a teen in youtube comments section. I'm proposing these > stuffs, so the world can benefit something. By trolling me, you are just > killing that. > > To everyone else, please go easy on me. If I'm little off on something, > please forgive my ignorance. The reason I'm here is because you all know > these stuffs better than me. I'm here to get some feedback. > > If you all think opening a new port is waste of time, I'm ok with that. > But if you see some benefits on Implicit TLS over Opportunistic TLS, please > point that out too. > > Thank you for your time. > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mureninc at gmail.com Sat Jan 12 04:37:50 2019 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 11 Jan 2019 22:37:50 -0600 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian wrote: > Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now? The real problem is that opportunistic StartTLS stops being opportunistic the minute you encounter a `STARTTLS` extension on `EHLO`. At that point and henceforth, TLS is pretty much 100% mandatory. What happens if there are SSL negotiation failures? I'll tell you what happens — the sender will receive a few bounces, X hours and Y days after sending the mail; recipient doesn't receive anything at all. (Unless, of course, one of the administrators would magically decide to change the SSL options in the meantime to be compatible, or to disable the "opportunistic" StartTLS to start with, before the final bounce gets generated by the MTA of the sender.) These problems are real. They're already happening today. StartTLS being "opportunistic" is a pretty big scam. C. From ops.lists at gmail.com Sat Jan 12 04:51:40 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 12 Jan 2019 04:51:40 +0000 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: , Message-ID: Any place that has a TLS misconfig will pretty much notice it very quickly indeed Opportunistic just means use TLS if it is advertised as available else continue encrypted. Not sure why encountering a starttls negates it. To the OP - what's the point of hiding the hostname in the smtp banner? You already know from the dns. Concerned about the MTA version? You can configure postfix to claim it is exchange or avian carrier for that matter --srs ________________________________ From: Constantine A. Murenin Sent: Saturday, January 12, 2019 10:08 AM To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian wrote: > Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now? The real problem is that opportunistic StartTLS stops being opportunistic the minute you encounter a `STARTTLS` extension on `EHLO`. At that point and henceforth, TLS is pretty much 100% mandatory. What happens if there are SSL negotiation failures? I'll tell you what happens — the sender will receive a few bounces, X hours and Y days after sending the mail; recipient doesn't receive anything at all. (Unless, of course, one of the administrators would magically decide to change the SSL options in the meantime to be compatible, or to disable the "opportunistic" StartTLS to start with, before the final bounce gets generated by the MTA of the sender.) These problems are real. They're already happening today. StartTLS being "opportunistic" is a pretty big scam. C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sat Jan 12 05:03:18 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 12 Jan 2019 00:03:18 -0500 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <13104.1547269398@turing-police.cc.vt.edu> On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said: > When I originally drafted the SMTPS proposal, I thought those plaint text > part before the STARTTLS command leaks some sensitive info. So - given that multiple people have explained to you on the ietf-smtp list that there's no really sensitive info before STARTTLS, what *exactly* does your proposal buy us? What *real* problem is port 26 fixing? And is this something that *you* think is a problem, or that somebody who runs an actual production mail system thinks is a problem? From valdis.kletnieks at vt.edu Sat Jan 12 05:07:43 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 12 Jan 2019 00:07:43 -0500 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <13239.1547269663@turing-police.cc.vt.edu> On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said: > But I still want the future of email to adopt Implicit TLS. So someday we > can kill Opportunistic TLS. I already lost the case for security. So my > smtps part of the proposal not gonna fly. I'm just here to learn whether > Implicit TLS can offer anything better than Opportunistic TLS that's worth > wasting a port. Well, the summary on the ietf-smtp list was that the new port doesn't actually buy you anything unless you have DANE, and once you have DANE, the new port doesn't add anything. The conclusion is that we should be deploying DANE more rather than burning a port. Not sure why you expect to hear much differently from NANOG. From giri at dombox.org Sat Jan 12 05:43:14 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 11:13:14 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <13239.1547269663@turing-police.cc.vt.edu> References: <13239.1547269663@turing-police.cc.vt.edu> Message-ID: > To the OP - what's the point of hiding the hostname in the smtp banner? > You already know from the dns. Concerned about the MTA version? You can > configure postfix to claim it is exchange or avian carrier for that matter I was concerned about the Brand name right next to the 220 hostname example I posted earlier. I thought it would offer little more privacy. I was wrong. So - given that multiple people have explained to you on the ietf-smtp list > that there's no really sensitive info before STARTTLS, what *exactly* does > your proposal buy us? What *real* problem is port 26 fixing? > And is this something that *you* think is a problem, or that somebody who > runs an actual production mail system thinks is a problem? Thanks Mr. Kletnieks, Nice to meet you again. [To everyone else - he is one of the nicest person who provided suggestions in ietf-smtp] When I proposed I thought this was an issue. But seem like it's not. What I'm looking for here is will there be any additional pros if we introduce Implicit TLS? Pros of introducing Implicit TLS: + Falls under Best Practices + Sets an early date to deprecate Opportunistic TLS in the future. (e.g. 20 years from now) + Seems like it's what the world wants. Cons of introducing Implicit TLS: - Wastes a port - ISP needs to add little code to block port 26 Well, the summary on the ietf-smtp list was that the new port doesn't > actually > buy you anything unless you have DANE, and once you have DANE, the new port > doesn't add anything. > The conclusion is that we should be deploying DANE more rather than > burning a > port. > Not sure why you expect to hear much differently from NANOG. I improved my proposal a lot based on feedback I received from people like you. My proposal doesn't rely on DANE. Only DNSSEC. Even for that part, it doesn't mandates that. When example.com mails are third party hosted, example.com needs DNSSEC and third party mail servers (e.g. Google) needs DNSSEC+DANE. But google seem like it's not interested in DNSSEC. Thus Google provides a DANE alternative called MTA-STS. Let's say my domain supports DNSSEC. If my domain mails are hosted in Google, then I have no other way other than going for MTA-STS. MTA-STS needs another https server just for the sake of mail security. My proposal just changes that. Google gonna name their MX servers with starttls- prefix. And now example.com can protect MX record spoofing via DNSSEC. My point is, the signalling mechanism is handed over to third party mail providers like Google in DANE. My solution embeds the signalling mechanism in the hostname. Thus google don't have to evangelise MTA-STS to their millions of customers. Please correct me if I'm wrong with those statements On Sat, Jan 12, 2019 at 10:36 AM wrote: > On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said: > > > But I still want the future of email to adopt Implicit TLS. So someday we > > can kill Opportunistic TLS. I already lost the case for security. So my > > smtps part of the proposal not gonna fly. I'm just here to learn whether > > Implicit TLS can offer anything better than Opportunistic TLS that's > worth > > wasting a port. > > Well, the summary on the ietf-smtp list was that the new port doesn't > actually > buy you anything unless you have DANE, and once you have DANE, the new port > doesn't add anything. > > The conclusion is that we should be deploying DANE more rather than > burning a > port. > > Not sure why you expect to hear much differently from NANOG. > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mureninc at gmail.com Sat Jan 12 05:56:45 2019 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 11 Jan 2019 23:56:45 -0600 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, 11 Jan 2019 at 22:51, Suresh Ramasubramanian wrote: > Any place that has a TLS misconfig will pretty much notice it very quickly indeed I disagree. Plenty of evidence that Microsoft/Hotmail doesn't notice / doesn't care. Many people don't notice / don't care about Hotmail, either. Gmail doesn't care either, because it'll be the small parties that'll notice and would probably care. > Opportunistic just means use TLS if it is advertised as available else continue encrypted. Not sure why encountering a starttls negates it. I'm pretty certain it's only in the TLS world where "opportunistic" means to use it even if it doesn't actually work, just because it's advertised as (potentially) available. C. […] > --srs > > ________________________________ > From: Constantine A. Murenin > Sent: Saturday, January 12, 2019 10:08 AM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] > > On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian > wrote: > > Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now? > > The real problem is that opportunistic StartTLS stops being > opportunistic the minute you encounter a `STARTTLS` extension on > `EHLO`. > > At that point and henceforth, TLS is pretty much 100% mandatory. > > What happens if there are SSL negotiation failures? I'll tell you > what happens — the sender will receive a few bounces, X hours and Y > days after sending the mail; recipient doesn't receive anything at > all. (Unless, of course, one of the administrators would magically > decide to change the SSL options in the meantime to be compatible, or > to disable the "opportunistic" StartTLS to start with, before the > final bounce gets generated by the MTA of the sender.) > > These problems are real. They're already happening today. StartTLS > being "opportunistic" is a pretty big scam. > > C. From rob at invaluement.com Sat Jan 12 06:37:53 2019 From: rob at invaluement.com (Rob McEwen) Date: Sat, 12 Jan 2019 01:37:53 -0500 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues In-Reply-To: <1ab1783a-8dda-71c6-eddf-68d22ab6f06c@spamtrap.tnetconsulting.net> References: <20190110162220.GA7854@gsp.org> <20190111171709.GA29449@gsp.org> <20190111101136.A998@naund.org> <1ab1783a-8dda-71c6-eddf-68d22ab6f06c@spamtrap.tnetconsulting.net> Message-ID: On 1/11/2019 2:50 PM, Grant Taylor via NANOG wrote: > On 01/11/2019 12:32 PM, Rob McEwen wrote: >> but if done right, fwiw,, wouldn't that be sent over SMTP using TLS >> encryption? > > Oy vey.  in-flight vs at-rest encryption.  which is why i said "fwiw", acknowledging upfront that TLS transmission encryption has a limited scope. I guess you missed that?  But I was specifically replying to a complaint about passwords being sent in plain text, and I was suggesting that TLS would solve that problem. At that point in the discussion, it wasn't a discussion about all things encryption. ("context" is very helpful - are you still facepalming?) > On 01/11/2019 12:32 PM, Rob McEwen wrote: >> (but, then again, that ALSO requires a certificate!) > Let's Encrypt works perfectly fine for that too.  }:-) Exactly! That was sort of my point too. The person creating that dumpsterfire list seemed to be trying to avoid having to install a security certificate, but having that security certificate solves other problems besides the website getting https, such as enabling TLS, too. That was my basic point, I was just trying to be less wordy. -- Rob McEwen, invaluement -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Sat Jan 12 10:32:10 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sat, 12 Jan 2019 13:32:10 +0300 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <13239.1547269663@turing-police.cc.vt.edu> Message-ID: 12 Jan. 2019 г., 8:44 Viruthagiri Thirumavalavan : > Pros of introducing Implicit TLS: > + Falls under Best Practices > + Seems like it's what the world wants. None of the above is really a technical argument within standards process. The world wants emojis in domain names, so what? > + Sets an early date to deprecate Opportunistic TLS in the future. There's nothing bad in opportunistic TLS per se, and no reason to deprecate it. The real problem is the (absent) downgrade resistance: SMTP in cleartext is historically the default, and there's no tool to reliably advertise to *everyone* on the Internet that your particular SMTP server is not obsolete. Also, TOFU is similarly unreliable for that matter and too opaque for troubleshooting. None of the issues above are solved by adding yet another port to the already overblown e-mail port bundle. In fact, implicit TLS still has some advantages over the explicit version (e.g. 0-RTT) that you've missed, but they are of questionable profit for e-mail. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 11:42:56 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 17:12:56 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <13239.1547269663@turing-police.cc.vt.edu> Message-ID: Hi Töma, Those are valid points. Thanks for the input. On Sat, Jan 12, 2019 at 4:02 PM Töma Gavrichenkov wrote: > 12 Jan. 2019 г., 8:44 Viruthagiri Thirumavalavan : > > Pros of introducing Implicit TLS: > > + Falls under Best Practices > > + Seems like it's what the world wants. > > None of the above is really a technical argument within standards process. > > The world wants emojis in domain names, so what? > > > + Sets an early date to deprecate Opportunistic TLS in the future. > > There's nothing bad in opportunistic TLS per se, and no reason to > deprecate it. The real problem is the (absent) downgrade resistance: SMTP > in cleartext is historically the default, and there's no tool to reliably > advertise to *everyone* on the Internet that your particular SMTP server is > not obsolete. Also, TOFU is similarly unreliable for that matter and too > opaque for troubleshooting. > > None of the issues above are solved by adding yet another port to the > already overblown e-mail port bundle. > > In fact, implicit TLS still has some advantages over the explicit version > (e.g. 0-RTT) that you've missed, but they are of questionable profit for > e-mail. > > -- > Töma > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Sat Jan 12 15:53:44 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 12 Jan 2019 07:53:44 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On 1/11/19 9:38 AM, Viruthagiri Thirumavalavan wrote: > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's > related to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. Why would anyone need this when you can just set an option in most (all modern?) SMTP servers to refuse clear connections if you want to force TLS at all times? From giri at dombox.org Sat Jan 12 16:14:13 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 21:44:13 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: Hi Seth, My solution is intended for clients. A client should decide whether to transmit mails in clear text or not. In other words, the server can accept mails in clear text. The prefix informs the client, that the server supports TLS. A client that knows what "starttls-" prefix stands for, would come to know downgrade attacks if the STARTTLS command not found in EHLO response. If I force the server to accept only TLS, then that's not backward compatible. Thanks On Sat, Jan 12, 2019 at 9:24 PM Seth Mattinen wrote: > On 1/11/19 9:38 AM, Viruthagiri Thirumavalavan wrote: > > Hello NANOG, Belated new year wishes. > > > > I would like to gather some feedback from you all. > > > > I'm trying to propose two things to the Internet Standard and it's > > related to SMTP. > > > > (1) STARTTLS downgrade protection in a dead simple way > > > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > > Why would anyone need this when you can just set an option in most (all > modern?) SMTP servers to refuse clear connections if you want to force > TLS at all times? > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egon at egon.cc Sat Jan 12 16:39:26 2019 From: egon at egon.cc (James Downs) Date: Sat, 12 Jan 2019 08:39:26 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <9152A5AA-D196-4172-A323-D51F3358CAF6@egon.cc> > On Jan 12, 2019, at 08:14, Viruthagiri Thirumavalavan wrote: > My solution is intended for clients. A client should decide whether to transmit mails in clear text or not. You should spend some time doing research by reading RFCs, and doing a little searching on the internet. Your proposal, would, canonically be called SMTPS. If you put that into a search engine, you'll find not only is it deprecated, but has an assigned port number of 465. https://en.wikipedia.org/wiki/SMTPS From giri at dombox.org Sat Jan 12 16:43:44 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sat, 12 Jan 2019 22:13:44 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <9152A5AA-D196-4172-A323-D51F3358CAF6@egon.cc> References: <9152A5AA-D196-4172-A323-D51F3358CAF6@egon.cc> Message-ID: What makes you think I never did any research? https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636 On Sat, Jan 12, 2019 at 10:10 PM James Downs wrote: > > On Jan 12, 2019, at 08:14, Viruthagiri Thirumavalavan > wrote: > > > My solution is intended for clients. A client should decide whether to > transmit mails in clear text or not. > > You should spend some time doing research by reading RFCs, and doing a > little searching on the internet. Your proposal, would, canonically be > called SMTPS. > > If you put that into a search engine, you'll find not only is it > deprecated, but has an assigned port number of 465. > > https://en.wikipedia.org/wiki/SMTPS > > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Sat Jan 12 20:44:46 2019 From: johnl at iecc.com (John Levine) Date: 12 Jan 2019 15:44:46 -0500 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: Message-ID: <20190112204446.CDFE0200C917AA@ary.qy> In article you write: >What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional >security than a downgrade protected STARTTLS. Let's not waste a port." He's forum shopping. He's already take this to two IETF lists and we've explained to him why it's not a good idea. If you want to say that all your mail servers use TLS, we already have DANE for people who can deal with DNSSEC and MTA-STS for people who can't (or don't want to for whatever reason.) We do not need yet another hack, particularly one which attempts to reserve string patterns in DNS names. R's, John From mattlists at rivervalleyinternet.net Sat Jan 12 21:18:24 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sat, 12 Jan 2019 16:18:24 -0500 Subject: Could Someone From Yahoo Mail Please Contact Me Message-ID: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> Our customers who use yahoo.com e-mail addresses are saying they aren't receiving invoices from our billing system. I checked our mail logs and I'm getting this: Jan 12 16:11:34 account postfix/smtp[9802]: 1FA906C0E61: host mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command) The link suggests several things to do and we've waited over 48 hours and still can't get invoices through. The invoice server is definitely not compromised, and honestly I can't imagine there would be enough complaints to trigger a global block of that IP address, and we only have a small number of customers using @epix.net e-mail addresses. Thanks! From nanog at ics-il.net Sat Jan 12 21:20:31 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 12 Jan 2019 15:20:31 -0600 (CST) Subject: Could Someone From Yahoo Mail Please Contact Me In-Reply-To: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> References: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> Message-ID: <68941057.4069.1547328028102.JavaMail.mhammett@ThunderFuck> Try the mailop mailing list linked to in the past couple days. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matt Hoppes" To: "North American Network Operators' Group" Sent: Saturday, January 12, 2019 3:18:24 PM Subject: Could Someone From Yahoo Mail Please Contact Me Our customers who use yahoo.com e-mail addresses are saying they aren't receiving invoices from our billing system. I checked our mail logs and I'm getting this: Jan 12 16:11:34 account postfix/smtp[9802]: 1FA906C0E61: host mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command) The link suggests several things to do and we've waited over 48 hours and still can't get invoices through. The invoice server is definitely not compromised, and honestly I can't imagine there would be enough complaints to trigger a global block of that IP address, and we only have a small number of customers using @epix.net e-mail addresses. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sat Jan 12 21:22:46 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 12 Jan 2019 16:22:46 -0500 Subject: Could Someone From Yahoo Mail Please Contact Me In-Reply-To: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> References: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> Message-ID: Hey Matt, Someone the other day posted about a mailing list for mail server operators. You might have better luck there. Info below. mailop mailing list mailop at mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop On Sat, Jan 12, 2019 at 4:21 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Our customers who use yahoo.com e-mail addresses are saying they aren't > receiving invoices from our billing system. I checked our mail logs and > I'm getting this: > > Jan 12 16:11:34 account postfix/smtp[9802]: 1FA906C0E61: host > mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages > temporarily deferred due to user complaints - 4.16.55.1; see > https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM > command) > > The link suggests several things to do and we've waited over 48 hours > and still can't get invoices through. > > The invoice server is definitely not compromised, and honestly I can't > imagine there would be enough complaints to trigger a global block of > that IP address, and we only have a small number of customers using > @epix.net e-mail addresses. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 21:50:26 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 03:20:26 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <20190112204446.CDFE0200C917AA@ary.qy> References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: Hello Mr. Levine, 5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left. Last week I posted in IETF list. To be very honest, I don't like you. That's because you spent your time only on attacking me on DMARC list. I'm happy to post the private mail screenshots if anyone wants that. Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work. I asked you to provide evidence to support your criticisms, but you never did. You called my work as fantasy, whereas guys in this thread says it has at least some merits. https://mailarchive.ietf.org/arch/msg/uta/CaMj7xkGpkDg6c3qKGlLjksG5do To quote his words Sorry, but this is a fantasy. SMTP routing still falls back to an A > record if there's no MX and the DNS has been around for 30 years. And > your assmptions about what is hard and what is easy may be correct for > your personal situation, but they are not true in general. > Look at it this way -- if you can set up an STS server in less than a > decade, you're ahead of the game. This is what I responded for that. ----- Here is the problem with that part. A records are IE6 equivalent in the SMTP world. These days everyone moved to the MX records. There are rare cases where some mail servers still rely on A records. My solution doesn't deal with A records. It's the clients decision whether to use MX record or A record. Let's just pretend my solution rely on A records, you are criticising my work saying that 0.1% people not gonna upgrade to "MX Records". On the other hand, you think 100% of the internet gonna upgrade to a completely new system STS. Isn't that irony? ----- These are some of his responses to my thread. ------ MTA-STS does a great deal of this. It has a way for a domain to say "all my inbound mail uses TLS" (RFC 8461) and for other systems to report back and say whether they're actually seeing that (RFC 8460.) I don't understand why people are trying to reinvent the wheel when we just defined a fairly round one a few months ago. https://mailarchive.ietf.org/arch/msg/uta/XVHBasNzVBTKbFE2EcLmI9fK324 ----- We went through all of this when we invented MTA-STS. We know that setting up a web server can be non-trivial but for a lot of places, it's far easier than geting DNSSEC to work. I recall a dinner at the Buenos Aires IETF where we were trying to figure out if there were a reasonable way to signal stuff in the DNS. Magic names certainly came up. I think it would be a good idea for anyone interested in this topic to go back through the mailing list discussion and read the drafts and explain what is different now that we didn't know when we defined MTA-STS a few months ago https://mailarchive.ietf.org/arch/msg/uta/nmB53F9Hg9yfPXCXeXv248evYhM ----- John, you should know, I'm doing forum shopping here because of you. I totally understand others tried to help me. But you are not. You created this thread just to attack me. So this is the prime example of you trying to silence my work. Most decent folks never do such thing. To everyone else, my solution is an EASY alternative for both DANE and MTA-STS. John seem like he has vested interest in MTA-STS. Guys, feel free to take a look at our whole conversation in the uta ietf list. And then please tell me this man is not biased at all. I'm happy to terminate my proposal in that case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Sat Jan 12 22:03:34 2019 From: Brian at ampr.org (Brian Kantor) Date: Sat, 12 Jan 2019 14:03:34 -0800 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: <20190112220334.GA14087@meow.BKantor.net> >From this point forward, all mail containing the phrase "TLS on port 26" in the Subject line will be shunted into my junk mail box, unread, because I do not wish to see any more correspondence on this matter. 'procmail' is my friend. - Brian On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote: > Hello Mr. Levine, > [...] From giri at dombox.org Sat Jan 12 22:09:35 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 03:39:35 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <20190112220334.GA14087@meow.BKantor.net> References: <20190112204446.CDFE0200C917AA@ary.qy> <20190112220334.GA14087@meow.BKantor.net> Message-ID: I'm not sure why are being angry here. For the record, this conversation isn't about TLS on port 26. It's about STARTTLS downgrade protection on port 25. On Sun, Jan 13, 2019 at 3:33 AM Brian Kantor wrote: > From this point forward, all mail containing the phrase "TLS on > port 26" in the Subject line will be shunted into my junk mail box, > unread, because I do not wish to see any more correspondence on > this matter. > > 'procmail' is my friend. > - Brian > > > On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote: > > Hello Mr. Levine, > > [...] > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric-list at truenet.com Sat Jan 12 22:37:02 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Sat, 12 Jan 2019 17:37:02 -0500 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> <20190112220334.GA14087@meow.BKantor.net> Message-ID: <654DB814-A98A-45AD-BD79-FDCD24EDC911@truenet.com> In my opinion, the problem isn’t that great. As others have stated, you can locally enforce only STARTTLS on the receive connector or send connector locally to ensure that only encrypted transmission occurs. If the MTA doesn’t send/accept STARTTLS send an error message. That the host name is given, doesn’t really matter as most MiTM will still see IP SRC and IP DST so that’s given that transmission occurred. DNSSEC already will ensure the same IP, and RPKI can help on BGP hijacks, given this is still an ongoing process. In my opinion, the major issue is data at rest which would rely on PGP, S/MIME, et al. Another option would be DMTP, like I emailed off list which encrypts even headers. My guess though is that if this gains traction, there will be a corresponding law like CALEA for LEO to intercept. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 > On Jan 12, 2019, at 5:09 PM, Viruthagiri Thirumavalavan wrote: > > I'm not sure why are being angry here. > > For the record, this conversation isn't about TLS on port 26. It's about STARTTLS downgrade protection on port 25. > > On Sun, Jan 13, 2019 at 3:33 AM Brian Kantor > wrote: > From this point forward, all mail containing the phrase "TLS on > port 26" in the Subject line will be shunted into my junk mail box, > unread, because I do not wish to see any more correspondence on > this matter. > > 'procmail' is my friend. > - Brian > > > On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote: > > Hello Mr. Levine, > > [...] > > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sat Jan 12 22:47:54 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 12 Jan 2019 17:47:54 -0500 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <654DB814-A98A-45AD-BD79-FDCD24EDC911@truenet.com> References: <20190112204446.CDFE0200C917AA@ary.qy> <20190112220334.GA14087@meow.BKantor.net> <654DB814-A98A-45AD-BD79-FDCD24EDC911@truenet.com> Message-ID: <20129.1547333274@turing-police.cc.vt.edu> On Sat, 12 Jan 2019 17:37:02 -0500, Eric Tykwinski said: > even headers. My guess though is that if this gains traction, there will be a > corresponding law like CALEA for LEO to intercept. Hopefully *this* time we'll do it in such a way that LEO use will remain higher than bad-guys use. I'm not holding my breath though... From giri at dombox.org Sat Jan 12 23:07:40 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 04:37:40 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <20129.1547333274@turing-police.cc.vt.edu> References: <20190112204446.CDFE0200C917AA@ary.qy> <20190112220334.GA14087@meow.BKantor.net> <654DB814-A98A-45AD-BD79-FDCD24EDC911@truenet.com> <20129.1547333274@turing-police.cc.vt.edu> Message-ID: > > Go and check how many of these match. Then ask yourself why you might > be getting a poor reception on lists composed of people who do this stuff > for a living. Hello Mr. Kletnieks, I have no problem when people criticising my work. I even dropped the idea of port 26 because people like you showed me why it's bad. As for port 25 downgrade proposal, I'm happy to walk away if it is really flawed. But I can't walk away when biased people attack me to protect their interests. Remember, I posted in ietf-smtp to put a disclaimer when there is a "conflict of interest" when responding to my messages? I was talking about John and DANE author after seeing their messages in my uta thread. No matter how much time you might have spent, repeating a bad idea over > and over and over again will not turn it into a good idea. If you are biased, how can I know it's a bad idea. Are you gonna say you are not biased when criticising my work? I just proved you are biased. The people on the IETF lists, particularly Ned Freed, and John Klensin, > know more about mail than anyone in the world. If they don't like your > idea, you should pay attention. I interacted with Mr. Klensin in the ietf-smtp forum. More than knowing things, he seem like a man who respect others work. This is what he said Especially if you are new, please interpret my response (and > those of several others) as "we aren't convinced about your > idea" or "we think there are better alternatives", not as "your > proposal is bad and will cause problems". I'd like to see a > lot more discussion before the latter conclusion is reached > although I'd encourage you to read the comments carefully and > see if they suggest ways to improve the proposal. I believe > that it is very important that new ideas to which long-time > participants have initial negative reasons get careful > consideration and every reasonable chance to succeed before they > are dismissed. I have improved my solution based on feedback I received. I dropped my port 26 proposal and concentrating only on port 25. How can I get feedback from others, if you are gonna post anti-messages about my work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Sat Jan 12 23:16:30 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sun, 13 Jan 2019 02:16:30 +0300 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan wrote: > 5 months back I posted my spam research on DMARC list. > You have gone through only 50 words and judged my work. > The whole thread gone haywire because of you. I was > humiliated there and left. By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment. > To be very honest, I don't like you. Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else. > Although I don't like you, I still managed to respond politely in > IETF lists. Again... In that list the only thing you did was > attacking my work. So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement. > And then please tell me this man is not biased at all. Sorry, he's not. -- Töma From ops.lists at gmail.com Sat Jan 12 23:21:23 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 12 Jan 2019 23:21:23 +0000 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> , Message-ID: To the IP Other people try to sugar coat what they tell you John has never minced his words in the past two decades that I know him and that's good Yes, 50 words are more than enough to decide a bad idea is bad. You don't have to like that, or like any of us, but facts are facts --srs ________________________________ From: NANOG on behalf of Töma Gavrichenkov Sent: Sunday, January 13, 2019 4:48 AM To: Viruthagiri Thirumavalavan Cc: John Levine; nanog list Subject: Re: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan wrote: > 5 months back I posted my spam research on DMARC list. > You have gone through only 50 words and judged my work. > The whole thread gone haywire because of you. I was > humiliated there and left. By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment. > To be very honest, I don't like you. Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else. > Although I don't like you, I still managed to respond politely in > IETF lists. Again... In that list the only thing you did was > attacking my work. So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement. > And then please tell me this man is not biased at all. Sorry, he's not. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 23:21:40 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 04:51:40 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: I don't know why you are all try to defend a man who try to silence my work. Are you saying this thread is necessary? On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov wrote: > On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan > wrote: > > 5 months back I posted my spam research on DMARC list. > > You have gone through only 50 words and judged my work. > > The whole thread gone haywire because of you. I was > > humiliated there and left. > > By the way, since that you've left no traces of whatever piece of work > you've posted to that list. The website is empty, slides are removed > from Speakerdeck, etc. > > In theory, I can easily recall a few cases in my life when going > through just 50 words was quite enough for a judgment. > > > To be very honest, I don't like you. > > Please keep our busy mailing list out of this information, though for > me it's a valuable piece of data that someone I don't know personally > doesn't like someone else. > > > Although I don't like you, I still managed to respond politely in > > IETF lists. Again... In that list the only thing you did was > > attacking my work. > > So, I've read the whole thread, and, as far as I can see, there was > nothing coming from John except for a balanced judgement. > > > And then please tell me this man is not biased at all. > > Sorry, he's not. > > -- > Töma > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccummings at coeur.com Sat Jan 12 23:26:48 2019 From: ccummings at coeur.com (Cummings, Chris) Date: Sat, 12 Jan 2019 23:26:48 +0000 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> , Message-ID: Can we please have a mod step in and shut this thread down? Any conversation of value is long gone. /Chris On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" > wrote: I don't know why you are all try to defend a man who try to silence my work. Are you saying this thread is necessary? On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov > wrote: On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan > wrote: > 5 months back I posted my spam research on DMARC list. > You have gone through only 50 words and judged my work. > The whole thread gone haywire because of you. I was > humiliated there and left. By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment. > To be very honest, I don't like you. Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else. > Although I don't like you, I still managed to respond politely in > IETF lists. Again... In that list the only thing you did was > attacking my work. So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement. > And then please tell me this man is not biased at all. Sorry, he's not. -- Töma -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 23:27:26 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 04:57:26 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: > > By the way, since that you've left no traces of whatever piece of work > you've posted to that list. The website is empty, slides are removed > from Speakerdeck, etc. > In theory, I can easily recall a few cases in my life when going > through just 50 words was quite enough for a judgment. Yes, 50 words are more than enough to decide a bad idea is bad. You don't > have to like that, or like any of us, but facts are facts Guys, I can't able to disclose my work at this point. But I'm happy to publish my work again next month. In the meantime, I have no issues if you all think my work is bad. But if you all think, my work has some novelty and this man made the wrong choice, be sure to tell that too. On Sun, Jan 13, 2019 at 4:51 AM Viruthagiri Thirumavalavan wrote: > I don't know why you are all try to defend a man who try to silence my > work. > > Are you saying this thread is necessary? > > On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov > wrote: > >> On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan >> wrote: >> > 5 months back I posted my spam research on DMARC list. >> > You have gone through only 50 words and judged my work. >> > The whole thread gone haywire because of you. I was >> > humiliated there and left. >> >> By the way, since that you've left no traces of whatever piece of work >> you've posted to that list. The website is empty, slides are removed >> from Speakerdeck, etc. >> >> In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. >> >> > To be very honest, I don't like you. >> >> Please keep our busy mailing list out of this information, though for >> me it's a valuable piece of data that someone I don't know personally >> doesn't like someone else. >> >> > Although I don't like you, I still managed to respond politely in >> > IETF lists. Again... In that list the only thing you did was >> > attacking my work. >> >> So, I've read the whole thread, and, as far as I can see, there was >> nothing coming from John except for a balanced judgement. >> >> > And then please tell me this man is not biased at all. >> >> Sorry, he's not. >> >> -- >> Töma >> > > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sat Jan 12 23:28:37 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 04:58:37 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: Yes please, Thanks Mr. Cummings On Sun, Jan 13, 2019 at 4:56 AM Cummings, Chris wrote: > Can we please have a mod step in and shut this thread down? Any > conversation of value is long gone. > > /Chris > > > > On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" < > giri at dombox.org> wrote: > > I don't know why you are all try to defend a man who try to silence my >> work. >> >> Are you saying this thread is necessary? >> >> On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov >> wrote: >> >>> On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan >>> wrote: >>> > 5 months back I posted my spam research on DMARC list. >>> > You have gone through only 50 words and judged my work. >>> > The whole thread gone haywire because of you. I was >>> > humiliated there and left. >>> >>> By the way, since that you've left no traces of whatever piece of work >>> you've posted to that list. The website is empty, slides are removed >>> from Speakerdeck, etc. >>> >>> In theory, I can easily recall a few cases in my life when going >>> through just 50 words was quite enough for a judgment. >>> >>> > To be very honest, I don't like you. >>> >>> Please keep our busy mailing list out of this information, though for >>> me it's a valuable piece of data that someone I don't know personally >>> doesn't like someone else. >>> >>> > Although I don't like you, I still managed to respond politely in >>> > IETF lists. Again... In that list the only thing you did was >>> > attacking my work. >>> >>> So, I've read the whole thread, and, as far as I can see, there was >>> nothing coming from John except for a balanced judgement. >>> >>> > And then please tell me this man is not biased at all. >>> >>> Sorry, he's not. >>> >>> -- >>> Töma >>> >> >> >> -- >> Best Regards, >> >> Viruthagiri Thirumavalavan >> Dombox, Inc. >> > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sat Jan 12 23:30:34 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 12 Jan 2019 18:30:34 -0500 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: Viruthagiri, You are being too defensive. You've made this discussion about whether or not someone is attacking you, rather than the merit of your idea. It is not about networking or mail anymore. Please end the conversation here. -Ross On Sat, Jan 12, 2019 at 6:26 PM Viruthagiri Thirumavalavan wrote: > I don't know why you are all try to defend a man who try to silence my > work. > > Are you saying this thread is necessary? > > On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov > wrote: > >> On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan >> wrote: >> > 5 months back I posted my spam research on DMARC list. >> > You have gone through only 50 words and judged my work. >> > The whole thread gone haywire because of you. I was >> > humiliated there and left. >> >> By the way, since that you've left no traces of whatever piece of work >> you've posted to that list. The website is empty, slides are removed >> from Speakerdeck, etc. >> >> In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. >> >> > To be very honest, I don't like you. >> >> Please keep our busy mailing list out of this information, though for >> me it's a valuable piece of data that someone I don't know personally >> doesn't like someone else. >> >> > Although I don't like you, I still managed to respond politely in >> > IETF lists. Again... In that list the only thing you did was >> > attacking my work. >> >> So, I've read the whole thread, and, as far as I can see, there was >> nothing coming from John except for a balanced judgement. >> >> > And then please tell me this man is not biased at all. >> >> Sorry, he's not. >> >> -- >> Töma >> > > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sat Jan 12 23:34:24 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 12 Jan 2019 18:34:24 -0500 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: <22103.1547336064@turing-police.cc.vt.edu> On Sun, 13 Jan 2019 04:51:40 +0530, Viruthagiri Thirumavalavan said: > I don't know why you are all try to defend a man who try to silence my work. Rest assured that if he was actually trying to silence your work you wouldn't have been able to post your message to NANOG. From giri at dombox.org Sat Jan 12 23:32:50 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 05:02:50 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: Ok guys, let's stop the discussion on this thread. On Sun, Jan 13, 2019 at 5:00 AM Ross Tajvar wrote: > Viruthagiri, > > You are being too defensive. You've made this discussion about whether or > not someone is attacking you, rather than the merit of your idea. It is not > about networking or mail anymore. Please end the conversation here. > > -Ross > > On Sat, Jan 12, 2019 at 6:26 PM Viruthagiri Thirumavalavan < > giri at dombox.org> wrote: > >> I don't know why you are all try to defend a man who try to silence my >> work. >> >> Are you saying this thread is necessary? >> >> On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov >> wrote: >> >>> On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan >>> wrote: >>> > 5 months back I posted my spam research on DMARC list. >>> > You have gone through only 50 words and judged my work. >>> > The whole thread gone haywire because of you. I was >>> > humiliated there and left. >>> >>> By the way, since that you've left no traces of whatever piece of work >>> you've posted to that list. The website is empty, slides are removed >>> from Speakerdeck, etc. >>> >>> In theory, I can easily recall a few cases in my life when going >>> through just 50 words was quite enough for a judgment. >>> >>> > To be very honest, I don't like you. >>> >>> Please keep our busy mailing list out of this information, though for >>> me it's a valuable piece of data that someone I don't know personally >>> doesn't like someone else. >>> >>> > Although I don't like you, I still managed to respond politely in >>> > IETF lists. Again... In that list the only thing you did was >>> > attacking my work. >>> >>> So, I've read the whole thread, and, as far as I can see, there was >>> nothing coming from John except for a balanced judgement. >>> >>> > And then please tell me this man is not biased at all. >>> >>> Sorry, he's not. >>> >>> -- >>> Töma >>> >> >> >> -- >> Best Regards, >> >> Viruthagiri Thirumavalavan >> Dombox, Inc. >> > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sat Jan 12 23:46:46 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 12 Jan 2019 18:46:46 -0500 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: <22610.1547336806@turing-police.cc.vt.edu> On Sun, 13 Jan 2019 04:57:26 +0530, Viruthagiri Thirumavalavan said: > Guys, I can't able to disclose my work at this point. But I'm happy to > publish my work again next month. In the meantime, I have no issues if you > all think my work is bad. You'd probably do the world a favor if you spent that month instead finding mail software that does quoting and attribution correctly. You've made several posts that quoted me, and then quoted others in such a way that it looked like I said it. > But if you all think, my work has some novelty and this man made the wrong > choice, be sure to tell that too. Note that there are far more bad ideas than good ones, and sheer novelty doesn't mean an idea is good. From giri at dombox.org Sun Jan 13 00:01:11 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 05:31:11 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <22610.1547336806@turing-police.cc.vt.edu> References: <20190112204446.CDFE0200C917AA@ary.qy> <22610.1547336806@turing-police.cc.vt.edu> Message-ID: > > You'd probably do the world a favor if you spent that month instead > finding mail > software that does quoting and attribution correctly. You've made several > posts > that quoted me, and then quoted others in such a way that it looked like I > said it. Oh, I'm sorry about that. I'll pay attention next time. Note that there are far more bad ideas than good ones, and sheer novelty > doesn't > mean an idea is good. Ok -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Sun Jan 13 00:07:20 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sat, 12 Jan 2019 18:07:20 -0600 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> Message-ID: <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> Honestly, you feel very highly of your work in which any of us do in this field but John has a very good point and constructive criticism shroud not be the down fall of anyone. Read it 100 times without taking any thought of your own work and try to see the whole picture. Not agreeing with John or you but it is very straight forward and industry leading. It’s polite. I would feel the proper response from you would be to acknowledge the feedback and ask for some correction and guidance as John has had a lot of involvement here as so many others. He is not saying what you are doing is bad or such but more of guidance in a more proper direction so delusions are not set in the future. The whole picture of any outcome is not only had by just one person trying to make a difference but by the whole for a greater good for which makes sense for the current architectures and policies that are in place. I solute both you and John plus the community at which contribute highly valuable aspects to evolving “our” beat practices and judgements. Whether it’s positive or negative or proof of concept, it is how we get to where we “think” we should be. Criticism is how we get there regardless. Let’s cut out the other non-sense and discontinue this thread and work positively instead of against one-another. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jan 12, 2019, at 17:26, Cummings, Chris wrote: > > Can we please have a mod step in and shut this thread down? Any conversation of value is long gone. > > /Chris > > > > On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" wrote: > >> I don't know why you are all try to defend a man who try to silence my work. >> >> Are you saying this thread is necessary? >> >>> On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov wrote: >>> On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan >>> wrote: >>> > 5 months back I posted my spam research on DMARC list. >>> > You have gone through only 50 words and judged my work. >>> > The whole thread gone haywire because of you. I was >>> > humiliated there and left. >>> >>> By the way, since that you've left no traces of whatever piece of work >>> you've posted to that list. The website is empty, slides are removed >>> from Speakerdeck, etc. >>> >>> In theory, I can easily recall a few cases in my life when going >>> through just 50 words was quite enough for a judgment. >>> >>> > To be very honest, I don't like you. >>> >>> Please keep our busy mailing list out of this information, though for >>> me it's a valuable piece of data that someone I don't know personally >>> doesn't like someone else. >>> >>> > Although I don't like you, I still managed to respond politely in >>> > IETF lists. Again... In that list the only thing you did was >>> > attacking my work. >>> >>> So, I've read the whole thread, and, as far as I can see, there was >>> nothing coming from John except for a balanced judgement. >>> >>> > And then please tell me this man is not biased at all. >>> >>> Sorry, he's not. >>> >>> -- >>> Töma >> >> >> -- >> Best Regards, >> >> Viruthagiri Thirumavalavan >> Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sun Jan 13 00:13:24 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 05:43:24 +0530 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> References: <20190112204446.CDFE0200C917AA@ary.qy> <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> Message-ID: Jason, Your comment is one of the best I have seen in this thread. Thanks for the input and being neutral. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Sun Jan 13 00:19:50 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sat, 12 Jan 2019 18:19:50 -0600 Subject: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <20190112204446.CDFE0200C917AA@ary.qy> <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> Message-ID: <6075FF08-AFCA-4F85-988D-7142E4786768@dataix.net> No problem. We all come across this here and there. We all fail 100 times or more but perception will always be key in how we obtain a final objective that benefits everyone. Thomas Edison failed thousands of times but of all those times his success only came from the knowledge of those so many failures. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jan 12, 2019, at 18:13, Viruthagiri Thirumavalavan wrote: > > Jason, Your comment is one of the best I have seen in this thread. > > Thanks for the input and being neutral. From rgolodner at infratection.com Sun Jan 13 00:28:02 2019 From: rgolodner at infratection.com (Richard) Date: Sat, 12 Jan 2019 18:28:02 -0600 Subject: Enough port 26 talk... In-Reply-To: <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> References: <20190112204446.CDFE0200C917AA@ary.qy> <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> Message-ID: What Jason said in red. On 1/12/19 6:07 PM, Jason Hellenthal via NANOG wrote: > Honestly, you feel very highly of your work in which any of us do in > this field but John has a very good point and constructive criticism > shroud not be the down fall of anyone. Read it 100 times without > taking any thought of your own work and try to see the whole picture. > > Not agreeing with John or you but it is very straight forward and > industry leading. It’s polite. I would feel the proper response from > you would be to acknowledge the feedback and ask for some correction > and guidance as John has had a lot of involvement here as so many others.  > > He is not saying what you are doing is bad or such but more of > guidance in a more proper direction so delusions are not set in the > future. > > The whole picture of any outcome is not only had by just one person > trying to make a difference but by the whole for a greater good for > which makes sense for the current architectures and policies that are > in place. > > I solute both you and John plus the community at which contribute > highly valuable aspects to evolving “our” beat practices and judgements. > > Whether it’s positive or negative or proof of concept, it is how we > get to where we “think” we should be. > > Criticism is how we get there regardless. > > Let’s cut out the other non-sense and discontinue this thread and work > positively instead of against one-another.  > > --  >  J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven > says a lot about anticipated traffic volume. > > On Jan 12, 2019, at 17:26, Cummings, Chris > wrote: > >> Can we please have a mod step in and shut this thread down? Any >> conversation of value is long gone.  >> >> /Chris >> >> >> >> On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" >> > wrote: >> >> I don't know why you are all try to defend a man who try to >> silence my work. >> >> Are you saying this thread is necessary? >> >> On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov >> > wrote: >> >> On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan >> > wrote: >> > 5 months back I posted my spam research on DMARC list. >> > You have gone through only 50 words and judged my work. >> > The whole thread gone haywire because of you. I was >> > humiliated there and left. >> >> By the way, since that you've left no traces of whatever >> piece of work >> you've posted to that list. The website is empty, slides are >> removed >> from Speakerdeck, etc. >> >> In theory, I can easily recall a few cases in my life when going >> through just 50 words was quite enough for a judgment. >> >> > To be very honest, I don't like you. >> >> Please keep our busy mailing list out of this information, >> though for >> me it's a valuable piece of data that someone I don't know >> personally >> doesn't like someone else. >> >> > Although I don't like you, I still managed to respond >> politely in >> > IETF lists. Again... In that list the only thing you did was >> > attacking my work. >> >> So, I've read the whole thread, and, as far as I can see, >> there was >> nothing coming from John except for a balanced judgement. >> >> > And then please tell me this man is not biased at all. >> >> Sorry, he's not. >> >> -- >> Töma >> >> >> >> -- >> Best Regards, >> >> Viruthagiri Thirumavalavan >> Dombox, Inc. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Sun Jan 13 00:35:06 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sat, 12 Jan 2019 19:35:06 -0500 Subject: Could Someone From Yahoo Mail Please Contact Me In-Reply-To: References: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> Message-ID: Thanks. > On Jan 12, 2019, at 19:31, Udeme Ukutt wrote: > > Matt, > > Visit https://help.yahoo.com/kb/postmaster/, probably clicking the “new sender application” option would trigger a ticket to yahoo. Someone there should be able to help. > > U > >> On Sat, Jan 12, 2019 at 4:19 PM Matt Hoppes wrote: >> Our customers who use yahoo.com e-mail addresses are saying they aren't >> receiving invoices from our billing system. I checked our mail logs and >> I'm getting this: >> >> Jan 12 16:11:34 account postfix/smtp[9802]: 1FA906C0E61: host >> mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages >> temporarily deferred due to user complaints - 4.16.55.1; see >> https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM >> command) >> >> The link suggests several things to do and we've waited over 48 hours >> and still can't get invoices through. >> >> The invoice server is definitely not compromised, and honestly I can't >> imagine there would be enough complaints to trigger a global block of >> that IP address, and we only have a small number of customers using >> @epix.net e-mail addresses. >> >> Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jan 13 04:15:24 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 12 Jan 2019 20:15:24 -0800 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <71C4C965-5EB1-4ECC-B69A-68018A6EF092@delong.com> > On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan wrote: > > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's related to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. How would (2) be different from the previous SMTPS port 465 which was deprecated? > Don't take this in the wrong way. We do have "Implicit TLS" for "SMTP Submission" on port 465. But we don't have a secure port 25 alternative. i.e. The real SMTPS https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587 Seems to agree with my recollection that 465 was never specifically for submission and that it was deprecated shortly after the introduction of STARTTLS. > Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue. However the implementation is not simple. The former requires a HTTPS server and the latter requires DNSSEC to even get started. > > This proposal fixes STARTTLS downgrade issue and propose a new port 26, an "Implicit TLS" alternative for port 25 and recommends the MX server to signal the port via a prefix. As a general rule, I think separate ports for TLS-ified versions of existing protocols isn’t the right solution and simply wastes ports. Thinking this through, I don’t think you actually solve the existing problem, either. A client wanting to use your new port 26 would need to fall back to port 25 by default if the MTA at the other end didn’t support port 26. As I see it, there are the following remote MTA possibilities (ignoring submission on 587 and ignoring any possible legacy implementation on 465 for now): 1. Remote MTA supports port 26 and STARTTLS on port 25. 2. Remote MTA supports only port 25 with STARTTLS 3. Remote MTA supports only port 25 in clear text So long as the client will fall back to port 25, you have an identical vulnerability to man in the middle attack in all 3 cases: 1. If port 26 is attempted, Send back a TCP RST or ICMP port unreachable message in response to the connection attempt on port 26. 2. Conventional STARTTLS Downgrade attack. If you have some way to remove the need for fallback to port 25, then you can in all of those instances simply remove the willingness to communicate with an MTA server that does not offer STARTTLS as part of the negotiable option set in response to the EHLO, thus eliminating the acceptance of a downgrade attack. > > This proposal offers two ways. > > (1) STARTTLS Prefix > > Use this prefix only to deal with STARTTLS downgrade issue. > > e.g. mx1.example.com should be prefixed like starttls-mx1.example.com . > > Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”. > > (2) SMTPS Prefix > > Use this prefix if you wanna support Implicit TLS on port 26 and Opportunistic TLS on port 25. > > e.g. mx1.example.com should be prefixed like smtps-mx1.example.com . > > Where "smtps-" says "We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25. And our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection". > > In "starttls-" prefix port 25 MUST support encryption with valid SSL certificates. > > In "smtps-" prefix, BOTH port 26 and port 25 MUST support encryption with valid SSL certificates. > > Note: You need to enable DNSSEC to prevent MX record spoofing. My proposal highly recommends DNSSEC. Not mandates that. So the naming convention thing might be usable, but I don’t see any advantage to the explicit TLS port vs. just providing naming-based hints about STARTTLS. > What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port.” I’m inclined to agree here… See above. > What I think? - Implicit TLS still fall under the "best practices". So it will send out the positive vibe that IETF still cares about email security. I don’t think so. First, I think the word you actually want is explicit (specified) vs. implicit (implied). Second, I’m not convinced that it is any more explicit. If you have an immutable out-of-band way of communicating STARTTLS support, then I don’t see port-based explicit as being in any way superior to rule-based explicit use of STARTTLS. So I’m not convinced that chewing up a port just to feel good about explicitness offers any tangible benefit. Third, I think rather than conveying the positive vibe you wish to imply that it would, instead, indicate that the IETF: 1. Can’t make up it’s mind about TLS on SMTP (yes, 465; no, use STARTTLS instead; yes, but this time on port 26) 2. Doesn’t care about wasting well-known port numbers (which are in relatively short supply) I’d consider both of these to be a pretty negative vibe. > What the world thinks? - https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f Most of the comments from the world appear not to fully understand the problem and have not thought through the implications I mention above. If your intent is for all upgraded client sides not to ever try port 25 (thus render them unable to connect to servers that don’t support your port 26 hack), then what do you gain vs. the already present option to tell your software to reject any MTA that doesn’t offer STARTTLS as an option or fails to negotiate TLS when you request it? If that’s an option, just turn that on and you’ve got all the same security this solution would offer without wasting a port. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Sun Jan 13 05:08:46 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Sun, 13 Jan 2019 10:38:46 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <71C4C965-5EB1-4ECC-B69A-68018A6EF092@delong.com> References: <71C4C965-5EB1-4ECC-B69A-68018A6EF092@delong.com> Message-ID: Hello Owen, Thanks for the input. This thread is not about my SMTPS proposal anymore. I'm already convinced that's not gonna work since I couldn't find any strong advantages over Opportunistic TLS. But I'm still open for suggestions for my "starttls-" prefix proposal. It's just trying to prevent STARTTLS downgrade issues in a very simple way. However people are against that proposal too because of IDN and A record fallback issues. I tested IDN and couldn't find any issues. As for A record, If this proposal must support it too for MX fallback mechanism, then I don't think this proposal gonna work. To answer your question How would (2) be different from the previous SMTPS port 465 which was > deprecated? Port 465 reintroduced in 2018 as submission port in rfc8314. Port 465 never used for relay as far as I know. My SMTPS proposal is all about relay. I have done some research about the ports. If you want, please take look here . Thanks On Sun, Jan 13, 2019 at 9:45 AM Owen DeLong wrote: > > > On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan > wrote: > > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's related > to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > > How would (2) be different from the previous SMTPS port 465 which was > deprecated? > > Don't take this in the wrong way. We do have "Implicit TLS" for "SMTP > Submission" on port 465. But we don't have a secure port 25 alternative. > i.e. The real SMTPS > > > https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587 > > Seems to agree with my recollection that 465 was never specifically for > submission and that it was deprecated shortly after the introduction of > STARTTLS. > > Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue. > However the implementation is not simple. The former requires a HTTPS > server and the latter requires DNSSEC to even get started. > > This proposal fixes STARTTLS downgrade issue and propose a new port 26, an > "Implicit TLS" alternative for port 25 and recommends the MX server to > signal the port via a prefix. > > > As a general rule, I think separate ports for TLS-ified versions of > existing protocols isn’t the right solution and simply wastes ports. > > Thinking this through, I don’t think you actually solve the existing > problem, either. > > A client wanting to use your new port 26 would need to fall back to port > 25 by default if the MTA at the other end didn’t support port 26. As I see > it, there are the following remote MTA possibilities (ignoring submission > on 587 and ignoring any possible legacy implementation on 465 for now): > > 1. Remote MTA supports port 26 and STARTTLS on port 25. > 2. Remote MTA supports only port 25 with STARTTLS > 3. Remote MTA supports only port 25 in clear text > > So long as the client will fall back to port 25, you have an identical > vulnerability to man in the middle attack in all 3 cases: > > 1. If port 26 is attempted, Send back a TCP RST or ICMP port unreachable > message in response to the connection attempt on port 26. > 2. Conventional STARTTLS Downgrade attack. > > If you have some way to remove the need for fallback to port 25, then you > can in all of those instances simply remove the willingness to communicate > with an MTA server that does not offer STARTTLS as part of the negotiable > option set in response to the EHLO, thus eliminating the acceptance of a > downgrade attack. > > > This proposal offers two ways. > > (1) STARTTLS Prefix > > Use this prefix only to deal with STARTTLS downgrade issue. > > e.g. mx1.example.com should be prefixed like starttls-mx1.example.com. > > Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if > STARTTLS command not found in the EHLO response or certificate is invalid, > then drop the connection”. > > > (2) SMTPS Prefix > > Use this prefix if you wanna support Implicit TLS on port 26 and > Opportunistic TLS on port 25. > > e.g. mx1.example.com should be prefixed like smtps-mx1.example.com. > > Where "smtps-" says "We prefer if you connect to our SMTPS in port 26. But > we also accept mails in port 25. And our port 25 supports Opportunistic > TLS. So if STARTTLS command not found in the EHLO response or certificate > is invalid, then drop the connection". > > In "starttls-" prefix port 25 *MUST* support encryption with *valid SSL* > certificates. > > In "smtps-" prefix, *BOTH* port 26 and port 25 *MUST* support encryption > with *valid SSL* certificates. > > Note: You need to enable DNSSEC to prevent MX record spoofing. My proposal > highly recommends DNSSEC. Not mandates that. > > > So the naming convention thing might be usable, but I don’t see any > advantage to the explicit TLS port vs. just providing naming-based hints > about STARTTLS. > > What IETF Mailing list thinks? - "Implicit TLS doesn't offer any > additional security than a downgrade protected STARTTLS. Let's not waste a > port.” > > > I’m inclined to agree here… See above. > > What I think? - Implicit TLS still fall under the "best practices". So it > will send out the positive vibe that IETF still cares about email security. > > > I don’t think so. First, I think the word you actually want is explicit > (specified) vs. implicit (implied). Second, I’m not convinced that it is > any more explicit. If you have an immutable out-of-band way of > communicating STARTTLS support, then I don’t see port-based explicit as > being in any way superior to rule-based explicit use of STARTTLS. So I’m > not convinced that chewing up a port just to feel good about explicitness > offers any tangible benefit. Third, I think rather than conveying the > positive vibe you wish to imply that it would, instead, indicate that the > IETF: > > 1. Can’t make up it’s mind about TLS on SMTP (yes, 465; no, use STARTTLS > instead; yes, but this time on port 26) > 2. Doesn’t care about wasting well-known port numbers (which are in > relatively short supply) > > I’d consider both of these to be a pretty negative vibe. > > > What the world thinks? - > https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f > > > Most of the comments from the world appear not to fully understand the > problem and have not thought through the implications I mention above. > > If your intent is for all upgraded client sides not to ever try port 25 > (thus render them unable to connect to servers that don’t support your port > 26 hack), then what do you gain vs. the already present option to tell your > software to reject any MTA that doesn’t offer STARTTLS as an option or > fails to negotiate TLS when you request it? > > If that’s an option, just turn that on and you’ve got all the same > security this solution would offer without wasting a port. > > Owen > > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at mork.no Sun Jan 13 11:38:51 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 13 Jan 2019 12:38:51 +0100 Subject: Enough port 26 talk... In-Reply-To: (Richard's message of "Sat, 12 Jan 2019 18:28:02 -0600") References: <20190112204446.CDFE0200C917AA@ary.qy> <1B09A266-AFA3-4F10-9D7D-64F90FE3DDD9@dataix.net> Message-ID: <871s5gpz1w.fsf@miraculix.mork.no> Yes. What is all the fuzz about? Email will be as dead as USENET in a couple of years anyway. Welcome to the age of "feeds". You may cry now. Bjørn From johnl at iecc.com Sun Jan 13 17:08:15 2019 From: johnl at iecc.com (John Levine) Date: 13 Jan 2019 12:08:15 -0500 Subject: Enough port 26 talk... In-Reply-To: <871s5gpz1w.fsf@miraculix.mork.no> Message-ID: <20190113170815.DB47A200C9C7E8@ary.qy> In article <871s5gpz1w.fsf at miraculix.mork.no> you write: >Yes. What is all the fuzz about? Email will be as dead as USENET in a >couple of years anyway. Funny, people have been saying that pretty much every year since the 1990s. What's different this time? From mysidia at gmail.com Sun Jan 13 18:06:20 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 Jan 2019 12:06:20 -0600 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan wrote: > I'm trying to propose two things to the Internet Standard and it's related to SMTP. > (1) STARTTLS downgrade protection in a dead simple way > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. A new Well-Known Port allocation should come from IANA if required, not by random cherrypicking; Port 26 has not been assigned for transport, and might be required for a different application. 465 is already allocated for SMTP over TLS. If you are using DNS Records to prevent downgrades anyways, then there should be no need nor valid justification for using an extra port number; the client SMTP sender can be required to inspect the DNS Record and find in the record a signal that TLS is mandatory, and the smtp client must not proceed past EHLO other than to STARTTLS immediately. > e.g. mx1.example.com should be prefixed like starttls-mx1.example.com. This is a layering violation/improper way of encoding information in the DNS. The RFCs that specify the MX RR data have already been written. Special names in the LABEL portion of a record cannot have special significance for MX records, Because it would be backwards-incompatible with current MX records. For example, I may very well have a host named "starttls-mx1.example.com" today, based on current standards which is not used solely for TLS SMTP, Or it might not even support TLS SMTP --- Significance cannot be added to strings in the DNS that did not exist in the original standard, due to potential conflicts with existing implementations. If you want a DNS format that behaves differently, then you should either get a new RR type, or utilize a TXT record ala DKIM, SPF, DMARC. Also, using a DNS Record prefix, TXT, new RR, or whatever still suffers from the same downgrade attacks you are concerned about (DNS Response Mangling/Stripping), unless DNSSEC is a mandatory requirement in order to use the facility. The DANE Facilities and other IETF drafts address this much more adequately. See RFC8461 -- https://tools.ietf.org/html/rfc8461 RFC 8461 seems to solve the same problem and does a better job. > Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO > response or certificate is invalid, then drop the connection". Wait... what you are suggesting is not Opportunistic TLS, but Strict TLS; or a SMTP equivalent to HTTP's HSTS. You could equally suggest a SMTP Banner Pattern for such a feature; instead of trying to overload the meaning of some DNS label substring. 220 smtp.example.com "Welcome to the example.com SMTP Server" strict-tls=*.example.com; max-age=604800; includeSubDomains > (2) SMTPS Prefix > Use this prefix if you wanna support Implicit TLS on port 26 and Opportunistic TLS on port 25. > e.g. mx1.example.com should be prefixed like smtps-mx1.example.com. Again, this is not useful --- vulnerable to downgrade attacks which are equivalent to Port 25 SMTP TLS stripping. The TLS stripper simply intercepts outgoing TCP Port 26 SYN Packets and responds with TCP RESET. Rewrites the MX response to DNS queries if the record begins with "smtps-XXX" to "-XXX" with the same IP addresses in the additional section and caches the A response for the generated hostnames. -- -JH From christoffer at netravnen.de Sun Jan 13 19:46:08 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Sun, 13 Jan 2019 20:46:08 +0100 Subject: Fwd: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> Message-ID: <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> Sent to NANOG, Anyone from NETFLIX subscribed? Could you please fix the below type notification e-mails to ALSO be available if one ONLY USES PLAIN-TEXT email clients? Currently the notice information is formatted in such a way the PLAIN-TEXT section is completely EMPTY. ONLY the HTML section contains information. (E-mail client on my case is Thunderbird) -- Cheers Christoffer -------- Forwarded Message -------- Subject: (Netflix/***) Scheduled Open Connect Appliance upgrade is starting Resent-From: *** Date: *** Jan 2019 *** From: Netflix Reply-To: no_reply at netflix.com To: *** Netflix Hello ***, The scheduled upgrade of your Open Connect Appliance(s) (OCAs) is beginning now. The list of affected appliances is: IP Address Name Facility *** *** *** From nanog at ics-il.net Sun Jan 13 19:50:58 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 13 Jan 2019 13:50:58 -0600 (CST) Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> Message-ID: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> People use plain-text e-mail on purpose? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Christoffer Hansen" To: nanog at nanog.org Sent: Sunday, January 13, 2019 1:46:08 PM Subject: Fwd: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting Sent to NANOG, Anyone from NETFLIX subscribed? Could you please fix the below type notification e-mails to ALSO be available if one ONLY USES PLAIN-TEXT email clients? Currently the notice information is formatted in such a way the PLAIN-TEXT section is completely EMPTY. ONLY the HTML section contains information. (E-mail client on my case is Thunderbird) -- Cheers Christoffer -------- Forwarded Message -------- Subject: (Netflix/***) Scheduled Open Connect Appliance upgrade is starting Resent-From: *** Date: *** Jan 2019 *** From: Netflix Reply-To: no_reply at netflix.com To: *** Netflix Hello ***, The scheduled upgrade of your Open Connect Appliance(s) (OCAs) is beginning now. The list of affected appliances is: IP Address Name Facility *** *** *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sun Jan 13 19:55:59 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 13 Jan 2019 14:55:59 -0500 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: <2985.1547409359@turing-police.cc.vt.edu> On Sun, 13 Jan 2019 13:50:58 -0600, Mike Hammett said: > People use plain-text e-mail on purpose? Yes. Next question? From christoffer at netravnen.de Sun Jan 13 19:55:54 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Sun, 13 Jan 2019 20:55:54 +0100 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: On 13/01/2019 20:50, Mike Hammett wrote: > People use plain-text e-mail on purpose? I do most of the time. (*it is frustrating when content parity between HTML and PLAINTEXT sections is e-mails is inconsistent. :/ ) -- Christoffer From Brian at ampr.org Sun Jan 13 19:57:24 2019 From: Brian at ampr.org (Brian Kantor) Date: Sun, 13 Jan 2019 11:57:24 -0800 Subject: plaintext email? In-Reply-To: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: <20190113195724.GA18966@meow.BKantor.net> On Sun, Jan 13, 2019 at 01:50:58PM -0600, Mike Hammett wrote: > People use plain-text e-mail on purpose? Are you trying to start another flame war? But to answer your question, yes. - Brian From christoffer at netravnen.de Sun Jan 13 20:01:20 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Sun, 13 Jan 2019 21:01:20 +0100 Subject: plaintext email? In-Reply-To: <20190113195724.GA18966@meow.BKantor.net> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> Message-ID: <77844d50-367e-9df2-f785-e773be75b422@netravnen.de> On 13/01/2019 20:57, Brian Kantor wrote: > Are you trying to start another flame war? I certainly hope to avoid this discussion currently! (back to 1) @NETFLIX: Anybody willing to listen to previous stated comment and take action on it? - Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From nanog at ics-il.net Sun Jan 13 20:04:10 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 13 Jan 2019 14:04:10 -0600 (CST) Subject: plaintext email? In-Reply-To: <77844d50-367e-9df2-f785-e773be75b422@netravnen.de> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> <77844d50-367e-9df2-f785-e773be75b422@netravnen.de> Message-ID: <1219301610.4419.1547409847100.JavaMail.mhammett@ThunderFuck> Check with the contacts listed on their PeeringDB entry. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Christoffer Hansen" To: Brian at ampr.org, nanog at ics-il.net Cc: nanog at nanog.org Sent: Sunday, January 13, 2019 2:01:20 PM Subject: Re: plaintext email? On 13/01/2019 20:57, Brian Kantor wrote: > Are you trying to start another flame war? I certainly hope to avoid this discussion currently! (back to 1) @NETFLIX: Anybody willing to listen to previous stated comment and take action on it? - Christoffer -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Sun Jan 13 20:11:34 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 13 Jan 2019 15:11:34 -0500 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: <3851.1547410294@turing-police.cc.vt.edu> On Sun, 13 Jan 2019 20:55:54 +0100, Christoffer Hansen said: > (*it is frustrating when content parity between HTML and PLAINTEXT > sections is e-mails is inconsistent. :/ ) Back when we were designing MIME, somebody (Vernon Schryver?) stated that multipart/alternative with text/plain and text/html was *always* incorrect. If the two parts are semantically equal, then one is superfluous and doesn't need to be sent. (Remember bandwidth costs in 1992...) If the two parts aren't semantically equal, then one part is deficient at best and actively misleading at worst, and should not be sent. From kmedcalf at dessus.com Sun Jan 13 20:10:11 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 13 Jan 2019 13:10:11 -0700 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: On Sunday, 13 January, 2019 12:51, Mike Hammet wrote: >People use plain-text e-mail on purpose? There is another kind of e-mail? Or are you referring to Web-Pages-over-SMTP? From jhellenthal at dataix.net Sun Jan 13 20:14:37 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 13 Jan 2019 14:14:37 -0600 Subject: plaintext email? In-Reply-To: <77844d50-367e-9df2-f785-e773be75b422@netravnen.de> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> <77844d50-367e-9df2-f785-e773be75b422@netravnen.de> Message-ID: Haha nice troll -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jan 13, 2019, at 14:01, Christoffer Hansen wrote: > > > >> On 13/01/2019 20:57, Brian Kantor wrote: >> Are you trying to start another flame war? > > I certainly hope to avoid this discussion currently! > > (back to 1) @NETFLIX: Anybody willing to listen to previous stated > comment and take action on it? > > - Christoffer > From christoffer at netravnen.de Sun Jan 13 20:21:02 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Sun, 13 Jan 2019 21:21:02 +0100 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <3851.1547410294@turing-police.cc.vt.edu> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <3851.1547410294@turing-police.cc.vt.edu> Message-ID: <12caa1b8-794d-f64d-01a7-915483ceb848@netravnen.de> On 13/01/2019 21:11, valdis.kletnieks at vt.edu wrote: > Back when we were designing MIME, somebody (Vernon Schryver?) stated > that multipart/alternative with text/plain and text/html was *always* incorrect. -_- > If the two parts are semantically equal, then one is superfluous and doesn't > need to be sent. (Remember bandwidth costs in 1992...) I can imagine. > If the two parts aren't semantically equal, then one part is deficient at best > and actively misleading at worst, and should not be sent. In 2019 I would hope this are not the case. Cause Cheap Bandwidth compared to the 90'ies. Still not always the case. Sadly. :/ -Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From giri at dombox.org Sun Jan 13 21:12:04 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 14 Jan 2019 02:42:04 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: > > If you are using DNS Records to prevent downgrades anyways, then there > should be no need nor valid justification for using an extra port number; > the > client SMTP sender can be required to inspect the DNS Record and find in > the record a signal that TLS is mandatory, and the smtp client must not > proceed > past EHLO other than to STARTTLS immediately. Yes that's what I meant in my proposal too. For example, I may very well have a host named > "starttls-mx1.example.com" today, > based on current standards which is not used solely for TLS SMTP, Or > it might not > even support TLS SMTP --- Significance cannot be added to strings in > the DNS that > did not exist in the original standard, due to potential conflicts > with existing implementations. Ok. That makes sense. The DANE Facilities and other IETF drafts address this much more adequately. > See RFC8461 -- https://tools.ietf.org/html/rfc8461 > RFC 8461 seems to solve the same problem and does a better job. This proposal just trying to do the job simpler. Let me copy paste some part I posted in ietf-smtp forum. ---- DNSSEC already protects my DNS records from spoofing. So I believe all my DNS records are secure when I enable DNSSEC. My domain is dombox.org and if I have mx records like mx1.dombox.org mx2.dombox.org mx3.dombox.org mx4.dombox.org mx5.dombox.org then those MX records are already protected from forgery since I have now enabled DNSSEC. Now I need to add DANE TLSA record to let the world know that my port 25 supports STARTTLS. So clients can detect downgrade issues. The TLSA records looks like this. 25._tcp.mx1.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx2.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx3.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx4.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx5.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 I think we can can simplify that part via CNAME record. But, let's not go there. Now my first question is, does that "fingerprint" adds any security in a "Third party CA" system? Or it's there just to be compatible with the DANE system since DANE is not a mail specific system? My second question, if my MX records are configured to use google MX servers (e.g. aspmx.l.google.com) whose job is to configure those DANE TLSA records? Google or Me? I believe it's not my job. Because there is no easy way I can have Google MX server certificate fingerprint unless google provides it. Even if they provide it, if google change their certificate for security reasons in the future, then that's gonna break millions of domains that depends on Google mail servers. So that would be a poor design. If I'm not wrong Google is against DNSSEC. So there is no way they are gonna configure DANE records like this. 25._tcp.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt1.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt2.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt3.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt4.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 Hopefully, That is one of the reason why MTA-STS got introduced. Even if I love DNSSEC and support it in my domain, Google sets the rules here since I'm relying on their mail hosting. I have no other way, other than supporting MTA-STS since google is against DNSSEC. ------ You could equally suggest a SMTP Banner Pattern for such a feature; > instead of trying to overload > the meaning of some DNS label substring. > 220 smtp.example.com "Welcome to the example.com SMTP Server" > strict-tls=*.example.com; max-age=604800; includeSubDomains It's still vulnerable to MiTM attack right? Rewrites the MX response to DNS queries if the record begins with > "smtps-XXX" to "-XXX" > with the same IP addresses in the additional section and caches the A > response for the generated hostnames. My solution is vulnerable to MiTM without DNSSEC. I guess I should update my proposal saying DNSSEC mandatory. But if you believe the prefix solution itself flawed, the what's the point. Thanks for the input. Those are all very helpful comments. On Sun, Jan 13, 2019 at 11:36 PM Jimmy Hess wrote: > On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan > wrote: > > > I'm trying to propose two things to the Internet Standard and it's > related to SMTP. > > (1) STARTTLS downgrade protection in a dead simple way > > (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. > > A new Well-Known Port allocation should come from IANA if required, not > by random cherrypicking; Port 26 has not been assigned for transport, > and > might be required for a different application. 465 is already allocated for > SMTP over TLS. > > If you are using DNS Records to prevent downgrades anyways, then there > should be no need nor valid justification for using an extra port number; > the > client SMTP sender can be required to inspect the DNS Record and find in > the record a signal that TLS is mandatory, and the smtp client must not > proceed > past EHLO other than to STARTTLS immediately. > > > e.g. mx1.example.com should be prefixed like starttls-mx1.example.com. > > This is a layering violation/improper way of encoding information in the > DNS. > The RFCs that specify the MX RR data have already been written. Special > names > in the LABEL portion of a record cannot have special significance for > MX records, > Because it would be backwards-incompatible with current MX records. > > For example, I may very well have a host named > "starttls-mx1.example.com" today, > based on current standards which is not used solely for TLS SMTP, Or > it might not > even support TLS SMTP --- Significance cannot be added to strings in > the DNS that > did not exist in the original standard, due to potential conflicts > with existing implementations. > > If you want a DNS format that behaves differently, then you should > either get a new RR type, or > utilize a TXT record ala DKIM, SPF, DMARC. > > Also, using a DNS Record prefix, TXT, new RR, or whatever still suffers > from > the same downgrade attacks you are concerned about (DNS Response > Mangling/Stripping), > unless DNSSEC is a mandatory requirement in order to use the facility. > > The DANE Facilities and other IETF drafts address this much more > adequately. > See RFC8461 -- https://tools.ietf.org/html/rfc8461 > RFC 8461 seems to solve the same problem and does a better job. > > > Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if > STARTTLS command not found in the EHLO > > response or certificate is invalid, then drop the connection". > > Wait... what you are suggesting is not Opportunistic TLS, but Strict TLS; > or a SMTP equivalent to HTTP's HSTS. > > You could equally suggest a SMTP Banner Pattern for such a feature; > instead of trying to overload > the meaning of some DNS label substring. > > 220 smtp.example.com "Welcome to the example.com SMTP Server" > strict-tls=*.example.com; max-age=604800; includeSubDomains > > > (2) SMTPS Prefix > > Use this prefix if you wanna support Implicit TLS on port 26 and > Opportunistic TLS on port 25. > > e.g. mx1.example.com should be prefixed like smtps-mx1.example.com. > > Again, this is not useful --- vulnerable to downgrade attacks which > are equivalent to Port 25 SMTP TLS stripping. > The TLS stripper simply intercepts outgoing TCP Port 26 SYN Packets > and responds with TCP RESET. > > Rewrites the MX response to DNS queries if the record begins with > "smtps-XXX" to "-XXX" > with the same IP addresses in the additional section and caches the A > response for the generated hostnames. > > -- > -JH > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Sun Jan 13 22:15:17 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sun, 13 Jan 2019 17:15:17 -0500 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> Yes Mike, All of my email clients are set to plain text only. Email is for text. Not HTML. Not incredimail. You know that :) > On Jan 13, 2019, at 14:50, Mike Hammett wrote: > > People use plain-text e-mail on purpose? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Christoffer Hansen" > To: nanog at nanog.org > Sent: Sunday, January 13, 2019 1:46:08 PM > Subject: Fwd: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting > > Sent to NANOG, > > Anyone from NETFLIX subscribed? > > > Could you please fix the below type notification e-mails to ALSO be > available if one ONLY USES PLAIN-TEXT email clients? > > Currently the notice information is formatted in such a way the > PLAIN-TEXT section is completely EMPTY. > ONLY the HTML section contains information. > > (E-mail client on my case is Thunderbird) > > -- > Cheers > > Christoffer > > -------- Forwarded Message -------- > Subject: (Netflix/***) Scheduled Open Connect Appliance > upgrade is starting > Resent-From: *** > Date: *** Jan 2019 *** > From: Netflix > Reply-To: no_reply at netflix.com > To: *** > > > > Netflix > > > Hello ***, > > The scheduled upgrade of your Open Connect Appliance(s) (OCAs) is > beginning now. The list of affected appliances is: > > IP Address Name Facility > *** *** *** > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Sun Jan 13 22:49:31 2019 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Sun, 13 Jan 2019 14:49:31 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> Message-ID: <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> I’m fine with HTML emails to some extent (mainly the inclusion of clickable links) but I am not a fan of formatting. Not to name any names, but there are a few people on this list that for whatever reason use different fonts or sizes. I like having all of my text the same size because I can then use the features built into my email client to change the size as I need for my eyes and the screen I am using. I am also able to change the font when the email does not already specify one. More importantly, what is the need to use a different font in your emails? One of the people that I converse with outside of this list uses a cursive font which is also in a different color. It’s very hard to read and I see no need for it at all. The final reason that I dislike some HTML emails is because my email reader has a dark mode which is much more easy on the eyes. Some formatting, though I am unsure what (it appears to me imbedded images), causes the email to display with a white background instead of the dark gray that normally shows. This is both not nice to look at and out of place with the other emails. While I don’t use a plain text email reader myself, I know that they are still commonly in use and have their place. One example of where I personally use one is on a terminal where I am automatically sending emails to interact with some email based systems. Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933/AS209762 > On Jan 13, 2019, at 2:15 PM, Matt Hoppes wrote: > > Yes Mike, > All of my email clients are set to plain text only. > > Email is for text. Not HTML. Not incredimail. You know that :) > > On Jan 13, 2019, at 14:50, Mike Hammett wrote: > >> People use plain-text e-mail on purpose? >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> From: "Christoffer Hansen" >> To: nanog at nanog.org >> Sent: Sunday, January 13, 2019 1:46:08 PM >> Subject: Fwd: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting >> >> Sent to NANOG, >> >> Anyone from NETFLIX subscribed? >> >> >> Could you please fix the below type notification e-mails to ALSO be >> available if one ONLY USES PLAIN-TEXT email clients? >> >> Currently the notice information is formatted in such a way the >> PLAIN-TEXT section is completely EMPTY. >> ONLY the HTML section contains information. >> >> (E-mail client on my case is Thunderbird) >> >> -- >> Cheers >> >> Christoffer >> >> -------- Forwarded Message -------- >> Subject: (Netflix/***) Scheduled Open Connect Appliance >> upgrade is starting >> Resent-From: *** >> Date: *** Jan 2019 *** >> From: Netflix >> Reply-To: no_reply at netflix.com >> To: *** >> >> >> >> Netflix >> >> >> Hello ***, >> >> The scheduled upgrade of your Open Connect Appliance(s) (OCAs) is >> beginning now. The list of affected appliances is: >> >> IP Address Name Facility >> *** *** *** >> >> >> From sethm at rollernet.us Mon Jan 14 02:01:24 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 13 Jan 2019 18:01:24 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> Message-ID: <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> On 1/13/19 2:49 PM, Bryce Wilson wrote: > Not to name any names, but there are a few people on this list that for whatever reason use different fonts or sizes. I like having all of my text the same size because I can then use the features built into my email client to change the size as I need for my eyes and the screen I am using. I am also able to change the font when the email does not already specify one. More importantly, what is the need to use a different font in your emails? One of the people that I converse with outside of this list uses a cursive font which is also in a different color. It’s very hard to read and I see no need for it at all. That's the primary reason I am plain text only: people that think they're being whimsical by picking fonts and colors that are hard to read. From james.cutler at consultant.com Mon Jan 14 02:11:31 2019 From: james.cutler at consultant.com (James R Cutler) Date: Sun, 13 Jan 2019 21:11:31 -0500 Subject: plaintext email? In-Reply-To: <20190113195724.GA18966@meow.BKantor.net> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> Message-ID: On Sun, Jan 13, 2019 at 01:50:58PM -0600, Mike Hammett wrote: > People use plain-text e-mail on purpose? Yes. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Mon Jan 14 03:20:14 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 13 Jan 2019 21:20:14 -0600 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> Message-ID: HTML gets converted to text here without images unless I want them.... the power of knowledge and ingenuity goes a long way. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jan 13, 2019, at 20:01, Seth Mattinen wrote: > >> On 1/13/19 2:49 PM, Bryce Wilson wrote: >> Not to name any names, but there are a few people on this list that for whatever reason use different fonts or sizes. I like having all of my text the same size because I can then use the features built into my email client to change the size as I need for my eyes and the screen I am using. I am also able to change the font when the email does not already specify one. More importantly, what is the need to use a different font in your emails? One of the people that I converse with outside of this list uses a cursive font which is also in a different color. It’s very hard to read and I see no need for it at all. > > > That's the primary reason I am plain text only: people that think they're being whimsical by picking fonts and colors that are hard to read. From egon at egon.cc Mon Jan 14 03:02:43 2019 From: egon at egon.cc (James Downs) Date: Sun, 13 Jan 2019 19:02:43 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> Message-ID: <20190114030243.GG15832@nemesis.egontech.com> On Sun, Jan 13, 2019 at 06:01:24PM -0800, Seth Mattinen wrote: > That's the primary reason I am plain text only: people that think > they're being whimsical by picking fonts and colors that are hard to read. Now if only we could get everyone to stop top-posting. From jared at puck.nether.net Mon Jan 14 03:53:12 2019 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 13 Jan 2019 22:53:12 -0500 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> Message-ID: <37F0B0AF-6FDD-4B33-8B15-96CCA187A764@puck.nether.net> Yes. It’s still a very effective anti spam technique. Sent from my iCar > On Jan 13, 2019, at 2:50 PM, Mike Hammett wrote: > > People use plain-text e-mail on purpose? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Christoffer Hansen" > To: nanog at nanog.org > Sent: Sunday, January 13, 2019 1:46:08 PM > Subject: Fwd: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting > > Sent to NANOG, > > Anyone from NETFLIX subscribed? > > > Could you please fix the below type notification e-mails to ALSO be > available if one ONLY USES PLAIN-TEXT email clients? > > Currently the notice information is formatted in such a way the > PLAIN-TEXT section is completely EMPTY. > ONLY the HTML section contains information. > > (E-mail client on my case is Thunderbird) > > -- > Cheers > > Christoffer > > -------- Forwarded Message -------- > Subject: (Netflix/***) Scheduled Open Connect Appliance > upgrade is starting > Resent-From: *** > Date: *** Jan 2019 *** > From: Netflix > Reply-To: no_reply at netflix.com > To: *** > > > > Netflix > > > Hello ***, > > The scheduled upgrade of your Open Connect Appliance(s) (OCAs) is > beginning now. The list of affected appliances is: > > IP Address Name Facility > *** *** *** > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Mon Jan 14 04:01:20 2019 From: Brian at ampr.org (Brian Kantor) Date: Sun, 13 Jan 2019 20:01:20 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <20190114030243.GG15832@nemesis.egontech.com> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> <20190114030243.GG15832@nemesis.egontech.com> Message-ID: <20190114040120.GA20813@meow.BKantor.net> On Sun, Jan 13, 2019 at 07:02:43PM -0800, James Downs wrote: > Now if only we could get everyone to stop top-posting. The only way you'll get people to stop top-posting is to get them to stop including every d*mn message in the thread in every posting. With all that cr*p in there, any response at the bottom is lost. Clearly, editing inclusions is a lost art. - Brian From valdis.kletnieks at vt.edu Mon Jan 14 04:24:56 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 13 Jan 2019 23:24:56 -0500 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <20190114040120.GA20813@meow.BKantor.net> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> <20190114030243.GG15832@nemesis.egontech.com> <20190114040120.GA20813@meow.BKantor.net> Message-ID: <27359.1547439896@turing-police.cc.vt.edu> On Sun, 13 Jan 2019 20:01:20 -0800, Brian Kantor said: > Clearly, editing inclusions is a lost art. > - Brian The September That Never Ended was so long ago that pretty much everybody from before that event is now well into "get off my lawn" territory. From Brian at ampr.org Mon Jan 14 05:05:00 2019 From: Brian at ampr.org (Brian Kantor) Date: Sun, 13 Jan 2019 21:05:00 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <27359.1547439896@turing-police.cc.vt.edu> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> <20190114030243.GG15832@nemesis.egontech.com> <20190114040120.GA20813@meow.BKantor.net> <27359.1547439896@turing-police.cc.vt.edu> Message-ID: <20190114050500.GA21007@meow.BKantor.net> On Sun, Jan 13, 2019 at 11:24:56PM -0500, valdis.kletnieks at vt.edu wrote: > The September That Never Ended was so long ago that pretty much > everybody from before that event is now well into "get off my lawn" > territory. Yes, I'm afraid we are. But I think it's more "get off my net". ...!moskvax!kgbvax!kremvax!brian From bortzmeyer at nic.fr Mon Jan 14 08:49:45 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 14 Jan 2019 09:49:45 +0100 Subject: 2019-01-11 ARIN.NET DNSSEC =?utf-8?Q?O?= =?utf-8?B?dXRhZ2Ug4oCT?= Post-Mortem (was: Re: ARIN NS down?) In-Reply-To: References: <2591031A-CB20-4F44-8871-AA3D0BA0BCF5@gmail.com> <20190111143753.6lxcpaxxpg2h2vfe@nic.fr> <3DD245D6-A005-4FC8-A6B9-4B81F6512D85@arin.net> Message-ID: <20190114084945.ql6e7zjoblbqfz7g@nic.fr> On Fri, Jan 11, 2019 at 08:59:10PM +0000, John Curran wrote a message of 125 lines which said: > Our monitoring systems reported being green until the signatures > expired as they presently check that the SOA's match on the internal > and external nameservers. For checking of DNSSEC signatures expiration (something which is as crucial to monitor as the PKIX certificates expiration), I use and I'm happy with it. From list at satchell.net Mon Jan 14 14:15:43 2019 From: list at satchell.net (Stephen Satchell) Date: Mon, 14 Jan 2019 06:15:43 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <20190114040120.GA20813@meow.BKantor.net> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <7944F4B3-97CD-4EAE-B66F-B5E4917DADF9@rivervalleyinternet.net> <2E26A15A-1F47-4BCC-BAF7-376895D0B845@thenetworknerds.ca> <71df96fe-b0b0-a232-d329-4e985f6ccb37@rollernet.us> <20190114030243.GG15832@nemesis.egontech.com> <20190114040120.GA20813@meow.BKantor.net> Message-ID: <075b63be-c038-b84e-7a93-44c0f2afb3f5@satchell.net> On 1/13/19 8:01 PM, Brian Kantor wrote: > Clearly, editing inclusions is a lost art. No, it isn't a lost art. As you can see, there are some of us who know perfectly well how to edit, and have e-mail tools that make this easy. (Using Thunderbird here.) Smartphone mail programs make excerpting a hard task, by the nature of the human interface. Making matters worse, Joe SixPack and Suzie Latchhook are not taught to do it, because of a despicable lack of BOFH personnel. (Time to take my gout meds.) From beecher at beecher.cc Mon Jan 14 14:47:11 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 14 Jan 2019 09:47:11 -0500 Subject: Could Someone From Yahoo Mail Please Contact Me In-Reply-To: References: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> Message-ID: What's the IP of your sending mail server? I can poke some people for you. On Sat, Jan 12, 2019 at 7:37 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Thanks. > > On Jan 12, 2019, at 19:31, Udeme Ukutt wrote: > > Matt, > > Visit https://help.yahoo.com/kb/postmaster/, probably clicking the “new > sender application” option would trigger a ticket to yahoo. Someone there > should be able to help. > > U > > On Sat, Jan 12, 2019 at 4:19 PM Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> Our customers who use yahoo.com e-mail addresses are saying they aren't >> receiving invoices from our billing system. I checked our mail logs and >> I'm getting this: >> >> Jan 12 16:11:34 account postfix/smtp[9802]: 1FA906C0E61: host >> mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages >> temporarily deferred due to user complaints - 4.16.55.1; see >> https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM >> command) >> >> The link suggests several things to do and we've waited over 48 hours >> and still can't get invoices through. >> >> The invoice server is definitely not compromised, and honestly I can't >> imagine there would be enough complaints to trigger a global block of >> that IP address, and we only have a small number of customers using >> @epix.net e-mail addresses. >> >> Thanks! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglasroyer at gmail.com Sat Jan 12 02:31:42 2019 From: douglasroyer at gmail.com (Doug Royer) Date: Fri, 11 Jan 2019 19:31:42 -0700 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <77cf9bda-e36f-7b7b-3978-d3495aedb859@gmail.com> On 1/11/19 10:38 AM, Viruthagiri Thirumavalavan wrote: > Hello NANOG, Belated new year wishes. > > I would like to gather some feedback from you all. > > I'm trying to propose two things to the Internet Standard and it's > related to SMTP. Your post to this list was (according to the headers): 11 Jan 2019 23:08:21 +0530 Yet on the IETF-smtp mailing list at: Wed, 9 Jan 2019 12:29:43 +0530 *You* wrote (in part): I'm the guy who proposed SMTP Over TLS on Port 26. Looks like that was dead end. So, now coming with another proposal. Question: Why did you post something on NANOG that you already declared to the IETF yourself as a "dead end" 2 days earlier? I read all of the IETF emails on this idea. They explained why it is currently a no-starter as proposed. -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer at gmail.com 714-989-6135 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4000 bytes Desc: S/MIME Cryptographic Signature URL: From udeme at ukutt.com Sun Jan 13 00:31:40 2019 From: udeme at ukutt.com (Udeme Ukutt) Date: Sat, 12 Jan 2019 19:31:40 -0500 Subject: Could Someone From Yahoo Mail Please Contact Me In-Reply-To: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> References: <20761b6c-25a1-f724-8e62-8abde548d223@rivervalleyinternet.net> Message-ID: Matt, Visit https://help.yahoo.com/kb/postmaster/, probably clicking the “new sender application” option would trigger a ticket to yahoo. Someone there should be able to help. U On Sat, Jan 12, 2019 at 4:19 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Our customers who use yahoo.com e-mail addresses are saying they aren't > receiving invoices from our billing system. I checked our mail logs and > I'm getting this: > > Jan 12 16:11:34 account postfix/smtp[9802]: 1FA906C0E61: host > mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages > temporarily deferred due to user complaints - 4.16.55.1; see > https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM > command) > > The link suggests several things to do and we've waited over 48 hours > and still can't get invoices through. > > The invoice server is definitely not compromised, and honestly I can't > imagine there would be enough complaints to trigger a global block of > that IP address, and we only have a small number of customers using > @epix.net e-mail addresses. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benlogan at myriverstreet.net Sun Jan 13 18:48:09 2019 From: benlogan at myriverstreet.net (Ben Logan) Date: Sun, 13 Jan 2019 13:48:09 -0500 Subject: Tools for streaming analysis Message-ID: Hey folks, Just wondered what others are using for traffic analysis, particularly for identifying the amount of streaming (audio/video) traffic on your networks. I prefer open source, whether free or commercial, but am open to any good suggestions. Looked at ntopng and like it ok, but think it could be more flexible. Like the idea of pmacctd and friends, but not sure how I'd break down the streaming traffic with it. I'm ok with raw data...I can generate the graphs I want. I don't like anything with Solarwinds in the title! Btw, the data will be from a mix of Brocade, Cisco and Juniper routers, so sflow, netflow and IPFIX may all be used. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From stacy at acm.org Sun Jan 13 20:42:36 2019 From: stacy at acm.org (Stacy W. Smith) Date: Sun, 13 Jan 2019 13:42:36 -0700 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> Message-ID: <2FAB8AC1-146C-4AA9-AD08-42688FE7137C@acm.org> On Jan 13, 2019, at 12:46 PM, Christoffer Hansen wrote: > Could you please fix the below type notification e-mails to ALSO be > available if one ONLY USES PLAIN-TEXT email clients? Thanks for the feedback. I will make sure this gets forwarded to the correct group within Netflix. --Stacy (aka stacys at netflix.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ycompanys at gmail.com Sun Jan 13 23:29:27 2019 From: ycompanys at gmail.com (Yosem Companys) Date: Sun, 13 Jan 2019 15:29:27 -0800 Subject: Cable/Wireless-Tower Map for the San Francisco Bay Coastside? Message-ID: Hey All, Does anyone know whether there's a map that shows the cable/wireless-tower map for the San Francisco Bay Coastside (i.e., from Montara to Half Moon Bay)? A few days ago, a truck hit a PG&E post on Highway 92, which traverses from San Mateo to Half Moon Bay. The accident caused the post to fall to the ground. The Coastside has one Comcast-owned, fiber-optic cable that crosses the mountains from Silicon Valley to the Coastside. I guess the cable must run on PG&E posts because not only did the accident cause a blackout in some areas of the Coastside but also the entire Coastside was left without almost any Cable TV, Internet, or mobile phone connectivity for practically 24 hours. I only have anecdotal evidence, but it seems that there was no Comcast or Verizon service whatsoever because Verizon leases the fiber-optic line from Comcast. It also seems that DirecTV and AT&T were not affected, and the theories vary as to why. Perhaps AT&T uses a combination of copper wire and wireless to service the area. DirecTV allegedly leases connectivity from AT&T. I've also heard that Sprint PCS paid the owner of a building near the El Granada post office to use it to relay a mobile signal from there. But when I asked on Nextdoor about the incident no one mentioned Sprint. In prior discussions, Coastside residents say they avoid Sprint and AT&T due to their spotty service. And I know nothing about T-Mobile. The reason I ask is because this is not the first time that Coastside residents have been left without mobile service, cable TV, and Internet connectivity. In fact, it seems to be a frequent phenomenon, making me wonder that if the infrastructure here is so fragile what would happen in the case of the "Big One" or, God forbid, a Tsunami or major storm surge. I understand that there's a plan for emergency responders to maintain Internet and mobile connectivity that includes microwave connectivity, but I have yet to obtain the details. So I'm trying to get as much data as I can to help local decision-makers figure out how to make the Coastside more resilient before the next disaster strikes. Thanks, Yosem -------------- next part -------------- An HTML attachment was scrubbed... URL: From neuro at well.com Mon Jan 14 01:02:18 2019 From: neuro at well.com (William Anderson) Date: Mon, 14 Jan 2019 01:02:18 +0000 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: On Sun, 13 Jan 2019 at 21:19, Viruthagiri Thirumavalavan wrote: > Let me copy paste some part I posted in ietf-smtp forum. > Please, stop. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Mon Jan 14 15:31:29 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 14 Jan 2019 21:01:29 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <77cf9bda-e36f-7b7b-3978-d3495aedb859@gmail.com> References: <77cf9bda-e36f-7b7b-3978-d3495aedb859@gmail.com> Message-ID: Because I saw support from people like Alessandro Vesely for my proposal. https://mailarchive.ietf.org/arch/msg/ietf-smtp/pSb216OGLuTe31yUzAXtqD2haAo Then it hit me. Maybe more people like him interested in SMTPS too. So I have done some research and posted this comment. https://mailarchive.ietf.org/arch/msg/ietf-smtp/apZ8nBnGpv1aXlFUtbcTjGipA8Q When I open this thread, I just wanted to make sure we are all on the same page. I think I even mentioned what IETF thinks when I created this thread. And asked "I would love to know where you stand on this proposal." So I opened this thread, just to collect some feedback. On Mon, Jan 14, 2019 at 8:45 PM Doug Royer wrote: > On 1/11/19 10:38 AM, Viruthagiri Thirumavalavan wrote: > > Hello NANOG, Belated new year wishes. > > > > I would like to gather some feedback from you all. > > > > I'm trying to propose two things to the Internet Standard and it's > > related to SMTP. > > Your post to this list was (according to the headers): > 11 Jan 2019 23:08:21 +0530 > > Yet on the IETF-smtp mailing list at: > Wed, 9 Jan 2019 12:29:43 +0530 > > *You* wrote (in part): > I'm the guy who proposed SMTP Over TLS on Port 26. Looks like that was > dead end. So, now coming with another proposal. > > Question: Why did you post something on NANOG that you already declared > to the IETF yourself as a "dead end" 2 days earlier? I read all of the > IETF emails on this idea. They explained why it is currently a > no-starter as proposed. > > -- > > Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) > DouglasRoyer at gmail.com > 714-989-6135 > > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giri at dombox.org Mon Jan 14 15:49:28 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 14 Jan 2019 21:19:28 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <77cf9bda-e36f-7b7b-3978-d3495aedb859@gmail.com> Message-ID: For the record, I dropped both proposals. I'm working on my personal projects now. Let's not annoy others by discussing about this anymore. I wanted to bring Implicit TLS to SMTP. So I had a good intention when I opened this thread. But things went little crazy due to my another thread. Many of you gave me your valuable feedback. So I'm convinced now. I really thank you all for the time. Have a nice day. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Mon Jan 14 15:54:05 2019 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 14 Jan 2019 10:54:05 -0500 (EST) Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: <77cf9bda-e36f-7b7b-3978-d3495aedb859@gmail.com> Message-ID: On Mon, 14 Jan 2019, Viruthagiri Thirumavalavan wrote: > Because I saw support from people like Alessandro Vesely for my proposal.  > > https://mailarchive.ietf.org/arch/msg/ietf-smtp/pSb216OGLuTe31yUzAXtqD2haAo > > Then it hit me. Maybe more people like him interested in SMTPS too. So I have done some research and posted this comment.  > > https://mailarchive.ietf.org/arch/msg/ietf-smtp/apZ8nBnGpv1aXlFUtbcTjGipA8Q  > > When I open this thread, I just wanted to make sure we are all on the same page. I think I even mentioned what IETF thinks when I created this thread. And asked "I would > love to know where you stand on this proposal."  This is a mailing list for network operations. When SMTP on another alternate port is something we have to configure our routers for (i.e. an ACL update), then it might have some small relevance here. Until then, talk about it is just noise. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rblayzor.bulk at inoc.net Mon Jan 14 15:58:11 2019 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Mon, 14 Jan 2019 10:58:11 -0500 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: <41c5c1c3-8b6c-79b8-6ddd-00175d7219b8@inoc.net> On 1/11/19 11:15 PM, Viruthagiri Thirumavalavan wrote: > e.g. 220 mail.ashleymadison.com > AshleyMadison ESMTP Service Ready > > Those text will always be transferred in plain text. So I thought > Implicit TLS would prevent leaking that info. I'm not really sure how that really matters when anyone on the open internet could connect to that service port and get the information anyway. If I'm in the middle and I really want to know who you're talking to, what prevents me to just connect to that host and get the same information? -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ From giri at dombox.org Mon Jan 14 16:02:55 2019 From: giri at dombox.org (Viruthagiri Thirumavalavan) Date: Mon, 14 Jan 2019 21:32:55 +0530 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: <41c5c1c3-8b6c-79b8-6ddd-00175d7219b8@inoc.net> References: <41c5c1c3-8b6c-79b8-6ddd-00175d7219b8@inoc.net> Message-ID: Hello Robert, Yes that was pointed out to me in the IETF. That's why I mentioned this part in this thread. "But guys in the IETF mailing list actually showed me a way to get that info. You just get the IP address from 3 way handshake and do reverse lookup / Connect to port 26 to fill the rest of the info. So a new port doesn't offer much security. And I totally I agree with them on that from my understanding of it." On Mon, Jan 14, 2019 at 9:28 PM Robert Blayzor wrote: > On 1/11/19 11:15 PM, Viruthagiri Thirumavalavan wrote: > > e.g. 220 mail.ashleymadison.com > > AshleyMadison ESMTP Service Ready > > > > Those text will always be transferred in plain text. So I thought > > Implicit TLS would prevent leaking that info. > > > I'm not really sure how that really matters when anyone on the open > internet could connect to that service port and get the information anyway. > > If I'm in the middle and I really want to know who you're talking to, > what prevents me to just connect to that host and get the same information? > > -- > inoc.net!rblayzor > XMPP: rblayzor.AT.inoc.net > PGP: https://inoc.net/~rblayzor/ > > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon Jan 14 16:30:27 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 14 Jan 2019 11:30:27 -0500 Subject: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] In-Reply-To: References: Message-ID: Your sarcasm detector might need a bit of a tweak. :) On Fri, Jan 11, 2019 at 9:18 PM Viruthagiri Thirumavalavan wrote: > While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed > > > Come on Mr. Herrin. > > Blocking a port is much easier than deprecating a heavily used protocol. > Google stats show ~75% use IPv4. > > On Sat, Jan 12, 2019 at 7:30 AM William Herrin wrote: > >> On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan >> wrote: >> >> In addition, it bypasses all the security folks have built around the >> >> idea of blocking port 25 traffic from sources which should not be >> >> operating as mail servers. Let's not make the network less secure in >> >> the name of making it more so. >> > >> > I already addressed this issue in the "security considerations" section. >> > >> > "Port 26 will be a secure alternative for Port 25. So Internet Service >> Providers are adviced to take precautions to prevent email spam abuse. They >> are advised to block port 26, if necessary." >> >> While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed. >> >> -Bill >> >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > > > -- > Best Regards, > > Viruthagiri Thirumavalavan > Dombox, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Jan 14 16:57:40 2019 From: randy at psg.com (Randy Bush) Date: Mon, 14 Jan 2019 08:57:40 -0800 Subject: plaintext email? In-Reply-To: References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> Message-ID: >> People use plain-text e-mail on purpose? > Yes. only if you want other people to be able to read it From morrowc.lists at gmail.com Mon Jan 14 17:12:34 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Jan 2019 12:12:34 -0500 Subject: plaintext email? In-Reply-To: References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> Message-ID: On Mon, Jan 14, 2019 at 11:58 AM Randy Bush wrote: > >> People use plain-text e-mail on purpose? > > Yes. > > only if you want other people to be able to read it > Isn't the underlying assumption with non-plaintext that: "I know what will work better for you than you do" (comic-sans, colors, contrasting...) Don't email users configure their client to display such that it helps them process mail more easily? why would you force your ideas of contrast/color-blindness/etc on other folks? :( There are several folk I refuse mail from at this point because they just don't get "I can't see your html email". oh well... I suppose procmail does exist for a reason. -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Jan 14 17:21:54 2019 From: randy at psg.com (Randy Bush) Date: Mon, 14 Jan 2019 09:21:54 -0800 Subject: plaintext email? In-Reply-To: References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> Message-ID: > Isn't the underlying assumption with non-plaintext that: "I know what > will work better for you than you do" as i said in the '90s, mime, a syntax for encoding incompatibility. > (comic-sans, colors, contrasting...) hey! if it will do magenta comic sans, i may have to recant! :) randy From Brian at ampr.org Mon Jan 14 17:24:43 2019 From: Brian at ampr.org (Brian Kantor) Date: Mon, 14 Jan 2019 09:24:43 -0800 Subject: plaintext email? In-Reply-To: References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> Message-ID: <20190114172443.GC25119@meow.BKantor.net> On Mon, Jan 14, 2019 at 12:12:34PM -0500, Christopher Morrow wrote: > Isn't the underlying assumption with non-plaintext that: "I know what will > work better for you than you do" I suspect that the increasing use of very long lines in the expectation that the recipient's mail client will wrap them "appropriately" leads to mail clients reformatting and wrapping lines in complete disregard for the formatting that the sender used. For example, the previous paragraph was sent consisting of four lines. If it didn't display that way for you, your mail client may have reformatted it. Had I wanted to use the formatting to convey some information, that would have been lost. A quote from many years ago that I feel is still relevant: "Good spelling, punctuation, and formatting are essentially the on-line equivalent of bathing." -- Elf Sternberg - Brian From steve at blighty.com Mon Jan 14 17:51:57 2019 From: steve at blighty.com (Steve Atkins) Date: Mon, 14 Jan 2019 17:51:57 +0000 Subject: plaintext email? In-Reply-To: <20190114172443.GC25119@meow.BKantor.net> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <20190113195724.GA18966@meow.BKantor.net> <20190114172443.GC25119@meow.BKantor.net> Message-ID: /me gestures at this thread If you needed more reason that NANOG might not be the place to discuss email issues at any higher level than port numbers, this is it. (I especially liked the "I use plain text everywhere!" message sent as HTML). mailop lives at the perpetually-TLS-challenged https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ietf-smtp lives at https://www.ietf.org/mailman/listinfo/ietf-smtp Cheers, Steve From rgolodner at infratection.com Mon Jan 14 18:12:32 2019 From: rgolodner at infratection.com (Richard) Date: Mon, 14 Jan 2019 12:12:32 -0600 Subject: CAT-TP Protocol? Message-ID: <07101e64-3275-07e5-d8cf-35c720578ee9@infratection.com>     If anyone can confirm my suspicion of what CAT-TP is I would be grateful. It is the first time I have seen it on a customer's network. I think it is for manipulating SIM cards, but I have been mistaken before. Off list replies are fine.     Thanks, Richard Golodner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lathama at gmail.com Mon Jan 14 18:18:49 2019 From: lathama at gmail.com (Andrew Latham) Date: Mon, 14 Jan 2019 12:18:49 -0600 Subject: CAT-TP Protocol? In-Reply-To: <07101e64-3275-07e5-d8cf-35c720578ee9@infratection.com> References: <07101e64-3275-07e5-d8cf-35c720578ee9@infratection.com> Message-ID: On Mon, Jan 14, 2019 at 12:14 PM Richard wrote: > > If anyone can confirm my suspicion of what CAT-TP is I would be grateful. It is the first time I have seen it on a customer's network. I think it is for manipulating SIM cards, but I have been mistaken before. Off list replies are fine. > > Thanks, Richard Golodner Card Application Toolkit Transport Protocol -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Mon Jan 14 18:49:06 2019 From: johnl at iecc.com (John R. Levine) Date: 14 Jan 2019 13:49:06 -0500 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: <23611.60004.800271.326638@gargle.gargle.HOWL> References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> Message-ID: > And you won't really have a choice because unless you're willing to go > full Ted Kaczynski one in a hundred of those emails will be very, very > important to you ... Yeah. E-mail remains the only scheme where the two parties don't have to be introduced first, don't have to be online at the same time, and you can check for it in one place (if you want to, or you can sort and file to your heart's content.) I've stopped being surprised that enthusiasts who tell me that the IM or online conferencing silver bullet du jour will kill e-mail never understand this. R's, John From johnl at iecc.com Mon Jan 14 20:52:18 2019 From: johnl at iecc.com (John Levine) Date: 14 Jan 2019 15:52:18 -0500 Subject: plaintext email? In-Reply-To: Message-ID: <20190114205218.B0192200CA2E8C@ary.qy> In article you write: > >Isn't the underlying assumption with non-plaintext that: "I know what will >work better for you than you do" ... No, it's that every MUA in the world has handled html mail for a decade and it's a waste of time to piss into the wind. I send most of my mail as unformatted text, but my MUA (alpine) renders incoming HTML just fine. Time to get over it and waste time arguing about something else pointless, like when to capitalize internet. R's, John From morrowc.lists at gmail.com Mon Jan 14 21:28:39 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Jan 2019 16:28:39 -0500 Subject: plaintext email? In-Reply-To: <20190114205218.B0192200CA2E8C@ary.qy> References: <20190114205218.B0192200CA2E8C@ary.qy> Message-ID: On Mon, Jan 14, 2019 at 3:52 PM John Levine wrote: > In article FA0eO8zNihUtA1M9AcTLQ at mail.gmail.com> you write: > > > >Isn't the underlying assumption with non-plaintext that: "I know what will > >work better for you than you do" ... > > No, it's that every MUA in the world has handled html mail for a decade > and it's a waste of time to piss into the wind. > the breeze is so nice though. > I send most of my mail as unformatted text, but my MUA (alpine) > renders incoming HTML just fine. Time to get over it and waste time > arguing about something else pointless, like when to capitalize internet. > > well we COULD argue about 'inline comment' or 'top posting' ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman at meetinghouse.net Mon Jan 14 21:38:45 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Jan 2019 16:38:45 -0500 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> Message-ID: <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> On 1/14/19 1:49 PM, John R. Levine wrote: >> And you won't really have a choice because unless you're willing to go >> full Ted Kaczynski one in a hundred of those emails will be very, very >> important to you ... > > Yeah.  E-mail remains the only scheme where the two parties don't have > to be introduced first, don't have to be online at the same time, and > you can check for it in one place (if you want to, or you can sort and > file to your heart's content.) > > I've stopped being surprised that enthusiasts who tell me that the IM > or online conferencing silver bullet du jour will kill e-mail never > understand this. Tell me about it. Originally, the Internet was built specifically to foster collaboration - open, interoperable protocols that work just fine across organizational boundaries. Ever since the net went commercial, we've been seeing more and more walled gardens - driven by folks with an economic advantage to segmenting & capturing audiences.  Whenever someone talks about how great some new technology is, I'm always reminded to "follow the money."  (And ain't it ironic that Microsoft supports calendaring protocols, while Google breaks them.) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From owen at delong.com Mon Jan 14 22:21:44 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Jan 2019 14:21:44 -0800 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <3851.1547410294@turing-police.cc.vt.edu> References: <010001683a6c700f-bab75fe0-e2d0-42a9-9503-b26e777b101e-000000@email.amazonses.com> <11a4b2a6-88fd-4772-4c83-f243d02f4cda@netravnen.de> <1594743574.4402.1547409054361.JavaMail.mhammett@ThunderFuck> <3851.1547410294@turing-police.cc.vt.edu> Message-ID: <40124137-E23C-447E-AE01-5677166C7668@delong.com> > On Jan 13, 2019, at 12:11 PM, valdis.kletnieks at vt.edu wrote: > > On Sun, 13 Jan 2019 20:55:54 +0100, Christoffer Hansen said: > >> (*it is frustrating when content parity between HTML and PLAINTEXT >> sections is e-mails is inconsistent. :/ ) > > Back when we were designing MIME, somebody (Vernon Schryver?) stated > that multipart/alternative with text/plain and text/html was *always* incorrect. > > If the two parts are semantically equal, then one is superfluous and doesn't > need to be sent. (Remember bandwidth costs in 1992...) > > If the two parts aren't semantically equal, then one part is deficient at best > and actively misleading at worst, and should not be sent. This involves a number of erroneous assumptions, IMHO… 1. All recipients have the ability to consume either form. 2. HTML cannot offer a better experience to some recipients while remaining semantically equivalent to the plain text content. 3. The improved recipient experience afforded by HTML has no value beyond what can be done in plain text. 4. The cost of bandwidth will remain fixed at 1992 levels. While I’m not a huge fan of the various forms of rich text for most emails, I do acknowledge that they do sometimes have merit and that in those cases, having a plain-text alternative included in the message for backwards compatibility with less capable or automated email consumers is, IMHO, preferable to not having it and consumes very little bandwidth by today’s standards. Owen From nanog at ics-il.net Tue Jan 15 02:58:16 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 14 Jan 2019 20:58:16 -0600 (CST) Subject: Cable/Wireless-Tower Map for the San Francisco Bay Coastside? In-Reply-To: References: Message-ID: <1214264247.5308.1547521091709.JavaMail.mhammett@ThunderFuck> https://www.cellmapper.net/map has crowd-sourced tower maps. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Yosem Companys" To: nanog at nanog.org Sent: Sunday, January 13, 2019 5:29:27 PM Subject: Cable/Wireless-Tower Map for the San Francisco Bay Coastside? Hey All, Does anyone know whether there's a map that shows the cable/wireless-tower map for the San Francisco Bay Coastside (i.e., from Montara to Half Moon Bay)? A few days ago, a truck hit a PG&E post on Highway 92, which traverses from San Mateo to Half Moon Bay. The accident caused the post to fall to the ground. The Coastside has one Comcast-owned, fiber-optic cable that crosses the mountains from Silicon Valley to the Coastside. I guess the cable must run on PG&E posts because not only did the accident cause a blackout in some areas of the Coastside but also the entire Coastside was left without almost any Cable TV, Internet, or mobile phone connectivity for practically 24 hours. I only have anecdotal evidence, but it seems that there was no Comcast or Verizon service whatsoever because Verizon leases the fiber-optic line from Comcast. It also seems that DirecTV and AT&T were not affected, and the theories vary as to why. Perhaps AT&T uses a combination of copper wire and wireless to service the area. DirecTV allegedly leases connectivity from AT&T. I've also heard that Sprint PCS paid the owner of a building near the El Granada post office to use it to relay a mobile signal from there. But when I asked on Nextdoor about the incident no one mentioned Sprint. In prior discussions, Coastside residents say they avoid Sprint and AT&T due to their spotty service. And I know nothing about T-Mobile. The reason I ask is because this is not the first time that Coastside residents have been left without mobile service, cable TV, and Internet connectivity. In fact, it seems to be a frequent phenomenon, making me wonder that if the infrastructure here is so fragile what would happen in the case of the "Big One" or, God forbid, a Tsunami or major storm surge. I understand that there's a plan for emergency responders to maintain Internet and mobile connectivity that includes microwave connectivity, but I have yet to obtain the details. So I'm trying to get as much data as I can to help local decision-makers figure out how to make the Coastside more resilient before the next disaster strikes. Thanks, Yosem -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Tue Jan 15 03:14:31 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 14 Jan 2019 20:14:31 -0700 Subject: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <40124137-E23C-447E-AE01-5677166C7668@delong.com> Message-ID: <8b7c17f0bbb84e47ae4dc3cc536d4ed6@mail.dessus.com> Whenever someone has a "experience" while reading an e-mail message or viewing a web page, one has to wonder what sort of drugs they are on ... It is the LSD that provides the "experience", not whether you are viewing an e-mail message or a web-page-over-SMTP ... Please experience the wonders of the top-quote. See your local psychedelic distributor if you are somehow not "experiencing" anything ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong >Sent: Monday, 14 January, 2019 15:22 >To: Valdis Kletnieks >Cc: nanog at nanog.org >Subject: Re: (Netflix/GlobalConnect a/s) Scheduled Open Connect >Appliance upgrade is starting > > > >> On Jan 13, 2019, at 12:11 PM, valdis.kletnieks at vt.edu wrote: >> >> On Sun, 13 Jan 2019 20:55:54 +0100, Christoffer Hansen said: >> >>> (*it is frustrating when content parity between HTML and PLAINTEXT >>> sections is e-mails is inconsistent. :/ ) >> >> Back when we were designing MIME, somebody (Vernon Schryver?) >stated >> that multipart/alternative with text/plain and text/html was >*always* incorrect. >> >> If the two parts are semantically equal, then one is superfluous >and doesn't >> need to be sent. (Remember bandwidth costs in 1992...) >> >> If the two parts aren't semantically equal, then one part is >deficient at best >> and actively misleading at worst, and should not be sent. > >This involves a number of erroneous assumptions, IMHO… > >1. All recipients have the ability to consume either form. >2. HTML cannot offer a better experience to some recipients while >remaining semantically > equivalent to the plain text content. >3. The improved recipient experience afforded by HTML has no value >beyond what can be > done in plain text. >4. The cost of bandwidth will remain fixed at 1992 levels. > >While I’m not a huge fan of the various forms of rich text for most >emails, I do acknowledge that they do sometimes have merit and that >in those cases, having a plain-text alternative included in the >message for backwards compatibility with less capable or automated >email consumers is, IMHO, preferable to not having it and consumes >very little bandwidth by today’s standards. > >Owen From list at satchell.net Tue Jan 15 03:37:45 2019 From: list at satchell.net (Stephen Satchell) Date: Mon, 14 Jan 2019 19:37:45 -0800 Subject: Top-quoting Was: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: <8b7c17f0bbb84e47ae4dc3cc536d4ed6@mail.dessus.com> References: <8b7c17f0bbb84e47ae4dc3cc536d4ed6@mail.dessus.com> Message-ID: On 1/14/19 7:14 PM, Keith Medcalf wrote: > Please experience the wonders of the top-quote. See your local psychedelic distributor if you are somehow not "experiencing" anything ... I experience a savings in time with non-edited top quoting. If I don't see meaningful new content within the first 20 lines, I ignore it as worthless...unless it's a topic I'm following closely. And, yes, I use a text-only mail reader. I don't like HTML mail, because it's an attack vector for ne'er-do-wells. As long as the mail reader allows "self-clicking" URLs, just NO. From pozar at lns.com Tue Jan 15 04:12:07 2019 From: pozar at lns.com (Tim Pozar) Date: Mon, 14 Jan 2019 20:12:07 -0800 Subject: Cable/Wireless-Tower Map for the San Francisco Bay Coastside? In-Reply-To: References: Message-ID: <35d9b171-62e6-d1dc-a965-c44d087e817e@lns.com> Sizable towers need to be registered with the FAA. You can go to: http://wireless2.fcc.gov/UlsApp/AsrSearch/asrAdvancedSearch.jsp Type in Half Moon Bay and CA for the state for a listing. Or better yet the lat lon and radius. Tim On 1/13/19 3:29 PM, Yosem Companys wrote: > Hey All, > > Does anyone know whether there's a map that shows the > cable/wireless-tower map for the San Francisco Bay Coastside (i.e., from > Montara to Half Moon Bay)? > > A few days ago, a truck hit a PG&E post on Highway 92, which traverses > from San Mateo to Half Moon Bay. The accident caused the post to fall to > the ground.  > > The Coastside has one Comcast-owned, fiber-optic cable that crosses the > mountains from Silicon Valley to the Coastside. I guess the cable must > run on PG&E posts because not only did the accident cause a blackout in > some areas of the Coastside but also the entire Coastside was left > without almost any Cable TV, Internet, or mobile phone connectivity for > practically 24 hours. > > I only have anecdotal evidence, but it seems that there was no Comcast > or Verizon service whatsoever because Verizon leases the fiber-optic > line from Comcast. It also seems that DirecTV and AT&T were not > affected, and the theories vary as to why. Perhaps AT&T uses a > combination of copper wire and wireless to service the area. DirecTV > allegedly leases connectivity from AT&T. > > I've also heard that Sprint PCS paid the owner of a building near the El > Granada post office to use it to relay a mobile signal from there. But > when I asked on Nextdoor about the incident no one mentioned Sprint. In > prior discussions, Coastside residents say they avoid Sprint and AT&T > due to their spotty service. And I know nothing about T-Mobile. > > The reason I ask is because this is not the first time that Coastside > residents have been left without mobile service, cable TV, and Internet > connectivity. In fact, it seems to be a frequent phenomenon, making me > wonder that if the infrastructure here is so fragile what would happen > in the case of the "Big One" or, God forbid, a Tsunami or major storm > surge.  > > I understand that there's a plan for emergency responders to maintain > Internet and mobile connectivity that includes microwave connectivity, > but I have yet to obtain the details. So I'm trying to get as much data > as I can to help local decision-makers figure out how to make the > Coastside more resilient before the next disaster strikes. > > Thanks, > Yosem From bzs at theworld.com Tue Jan 15 05:24:30 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 15 Jan 2019 00:24:30 -0500 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> Message-ID: <23613.28302.372008.410882@gargle.gargle.HOWL> I'd like to go on record as saying that I PREFER top-posting. Why dig through what you've already read to see the new comments? Actually in an ideal world previous included bits would be links which could optionally be expanded via one shared remote copy but lo I wander. You should try some of the internet governance (I know, oxymoron) lists where people will inline a megabyte of discussion to add just "+1!" or "I agree!" or "congrats!" in the middle or bottom. It's like Alice's Restaurant. "The purpose of time is to prevent everything from happening at once" Somehow that seems to apply to this. On January 14, 2019 at 16:28 morrowc.lists at gmail.com (Christopher Morrow) wrote: > well we COULD argue about 'inline comment' or 'top posting' ...  -- -Barry Shein Software Tool & Die | bzs at 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* From valdis.kletnieks at vt.edu Tue Jan 15 05:40:28 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 15 Jan 2019 00:40:28 -0500 Subject: plaintext email? In-Reply-To: <23613.28302.372008.410882@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: <21276.1547530828@turing-police.cc.vt.edu> A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? And now you're sitting here wondering what possible relevance that might have to some line or other - the only context you have at this point is that it's a reply to something you wrote. Actually, at this point you don't even have that. So you may have read this entire thing and now you're still wondering what possible relevance it may have to the thread. On Tue, 15 Jan 2019 00:24:30 -0500, bzs at theworld.com said: > Why dig through what you've already read to see the new comments? Or you can put the comment after, so everybody who reads text top to bottom has the context. I'm not away of any languages or writing systems that work from bottom to top, so that's pretty much everybody. And if people trimmed the quoted material so only the parts being replied to are left, there's not much digging involved. From rgolodner at infratection.com Tue Jan 15 05:52:17 2019 From: rgolodner at infratection.com (Richard) Date: Mon, 14 Jan 2019 23:52:17 -0600 Subject: plaintext email? In-Reply-To: <21276.1547530828@turing-police.cc.vt.edu> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: <30f30018-7693-4d42-11a4-29755d639d41@infratection.com> On 1/14/19 11:40 PM, valdis.kletnieks at vt.edu wrote: > And if people trimmed the > quoted material so only the parts being replied to are left, there's not much > digging involved.     That would really be nice, but people are inherintly lazy and will not invest the few seconds to make reading easier.     I know if I see a bunch of quotes I am more inclined to delete the email than read it. Port 26... From royce at techsolvency.com Tue Jan 15 05:56:42 2019 From: royce at techsolvency.com (Royce Williams) Date: Mon, 14 Jan 2019 20:56:42 -0900 Subject: plaintext email? In-Reply-To: <21276.1547530828@turing-police.cc.vt.edu> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: And just imagine what email threading might be like today ... ... if early email clients had defaulted to displaying the *bottom* of the thread (as if you'd scrolled there). Thoughtful UX design matters. -- Royce Williams Tech Solvency On Mon, Jan 14, 2019 at 8:39 PM wrote: > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > > And now you're sitting here wondering what possible relevance that might > have > to some line or other - the only context you have at this point is that > it's a > reply to something you wrote. Actually, at this point you don't even have > that. > > So you may have read this entire thing and now you're still wondering what > possible relevance it may have to the thread. > > On Tue, 15 Jan 2019 00:24:30 -0500, bzs at theworld.com said: > > Why dig through what you've already read to see the new comments? > > Or you can put the comment after, so everybody who reads text top to > bottom has > the context. I'm not away of any languages or writing systems that work > from > bottom to top, so that's pretty much everybody. And if people trimmed the > quoted material so only the parts being replied to are left, there's not > much > digging involved. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at mork.no Tue Jan 15 08:19:41 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 15 Jan 2019 09:19:41 +0100 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> (Miles Fidelman's message of "Mon, 14 Jan 2019 16:38:45 -0500") References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> Message-ID: <874laanxia.fsf@miraculix.mork.no> Miles Fidelman writes: > Ever since the net went commercial, we've been seeing more and more > walled gardens - driven by folks with an economic advantage to > segmenting & capturing audiences.  Whenever someone talks about how > great some new technology is, I'm always reminded to "follow the > money."  (And ain't it ironic that Microsoft supports calendaring > protocols, while Google breaks them.) And this is happening to email too. It's not IM or online conferencing that will kill email, but fragmentation into multiple closed email environments. We accept SPF and DMARC, abusing DNS to deliberately break SMTP. All in the name of spam protection, Mailing lists barely work anymore and have to resort to hacks to be able to forward messages to their recipients. Traditional forwarding to another account hasn't worked in years. Smaller providers are regularily blocked causing service disruption to their users. It's just a matter of time before the big players, well known for their disregard of open protocols, just shut off SMTP completely. They'll probably "invent" something much better as an excuse... And the masses will love them for that, because it finally removed the spam "problem". And everyone has a gmail account anyway, so why bother with outside email? Bjørn From james.cutler at consultant.com Tue Jan 15 13:43:57 2019 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 15 Jan 2019 08:43:57 -0500 Subject: Top Posting Was: Re: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: <35D88832-1031-4979-BD93-47983E18DCCC@consultant.com> Why must there be a hard rule about top posting? If the replied to message(s) comprise a long logical sequence, the OCD among us experience cognitive dissonance if the order is “un-natural”. Thus bottom posting continues the “natural” sequence and makes life easier for many of us who otherwise would have difficulty maintaining context. If a quoted message is concise, either by origin or by quoting only a salient point, top posting is not inappropriate. Context is nearby. If the quoted message asks a series of questions, interspersed answers provide bottom posting on a per question basis which clearly indicates the relation of each reply segment to the appropriate segment. Again, this assists many of us in maintaining context. If the reply is done from a tiny-screen as on an iPhone, context of long messages is impossible to maintain and, anyway, top posting is the default. This whole argument is analogous to rigorously not aligning braces in C code because Ritchie did it. Or rigorously aligning braces in C code to make comprehending easier. This reply is deliberately top posted with the reference material as a short appendix. It is in plain text so rendering has no browser dependancies and the archived version remains readable. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net On Mon, Jan 14, 2019 at 8:39 PM > wrote: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? And now you're sitting here wondering what possible relevance that might have to some line or other - the only context you have at this point is that it's a reply to something you wrote. Actually, at this point you don't even have that. So you may have read this entire thing and now you're still wondering what possible relevance it may have to the thread. On Tue, 15 Jan 2019 00:24:30 -0500, bzs at theworld.com said: > Why dig through what you've already read to see the new comments? Or you can put the comment after, so everybody who reads text top to bottom has the context. I'm not away of any languages or writing systems that work from bottom to top, so that's pretty much everybody. And if people trimmed the quoted material so only the parts being replied to are left, there's not much digging involved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Tue Jan 15 15:55:53 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Jan 2019 08:55:53 -0700 Subject: plaintext email? In-Reply-To: <23613.28302.372008.410882@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: <2185788b-6fe5-bda7-b1fb-a84a75d92451@spamtrap.tnetconsulting.net> On 01/14/2019 10:24 PM, bzs at theworld.com wrote: > I'd like to go on record as saying that I PREFER top-posting. To each his / her own preference. > Why dig through what you've already read to see the new comments? So that the comments are in context (item followed by comment about item) of what they are about. > Actually in an ideal world previous included bits would be links which > could optionally be expanded… Well formatted text can be expanded and collapsed with proper MUA plugins. This means that a long inline message can be viewed as one (collapsed) line of quoted text followed by multiple lines of reply. Lather, rinse, repeat as necessary. > …via one shared remote copy but lo I wander. That's a nice idea. But you start to get into even more complications. Many of which are related to security and capability to access central shared copy. Such isn't possible with email accessed via UUCP sneaker net, where as quoted text is. ;-) > You should try some of the internet governance (I know, oxymoron) > lists where people will inline a megabyte of discussion to add just > "+1!" or "I agree!" or "congrats!" in the middle or bottom. Arguably the fact that they have done that is in and of itself an abuse, specifically around the quote to new content ratio. If you use quote collapsing, then it would appear as one line followed by the reactionary response with the possibility of one line below. A couple of analogies: How well do you think a teacher would respond if a student stapled a sheet of paper with their answers to all the questions without numbers to the top of the quiz with room to answer the questions in line? How would you like to receive edits / comments / suggestions to a paper that you wrote as one lump at the top or bottom without any reference to page / paragraph / sentence / word that the comment is about? Both of these methods do technically provide the answer to the questions. But they impart much more load on the recipient to identify and / or locate the relevant section that they are in response to. Conversely, if Question and Answer documents are in multiple sets of that order, Question followed by Answer, it's quite easy to find associated items. Finally, set the example that you want others to follow. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From oscar.vives at gmail.com Tue Jan 15 15:56:30 2019 From: oscar.vives at gmail.com (Tei) Date: Tue, 15 Jan 2019 16:56:30 +0100 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: Email for personal use is turning rare. And people need to use *bold* in text more than not. So most clients are configured to send html by default, and people have no reasons to change that. I think LISTSERV software used to require plain text to send commands like subscribe, but I think they made their parser accept html mails and still find the commands. On 2019, nobody cares if you uses plain text or html in emails. If somebody write a bot that accept commands through email (like a GETWEB gateway) is very easy to make it accept html and flat it to text. -- -- ℱin del ℳensaje. From beecher at beecher.cc Tue Jan 15 16:03:53 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 15 Jan 2019 11:03:53 -0500 Subject: Top Posting Was: Re: plaintext email? In-Reply-To: <35D88832-1031-4979-BD93-47983E18DCCC@consultant.com> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> <35D88832-1031-4979-BD93-47983E18DCCC@consultant.com> Message-ID: Everyone processes information differently. There is no universal 'best way' to format a message 'properly'. Everyone will have different preferences based on their own experience and cognition. No disrespect intended to anyone at all, but the pissing and moaning about it is a massive waste of time and energy. On Tue, Jan 15, 2019 at 8:46 AM James R Cutler wrote: > Why must there be a hard rule about top posting? > > If the replied to message(s) comprise a long logical sequence, the OCD > among us experience cognitive dissonance if the order is “un-natural”. Thus > bottom posting continues the “natural” sequence and makes life easier for > many of us who otherwise would have difficulty maintaining context. > > If a quoted message is concise, either by origin or by quoting only a > salient point, top posting is not inappropriate. Context is nearby. > > If the quoted message asks a series of questions, interspersed answers > provide bottom posting on a per question basis which clearly indicates the > relation of each reply segment to the appropriate segment. Again, this > assists many of us in maintaining context. > > If the reply is done from a tiny-screen as on an iPhone, context of long > messages is impossible to maintain and, anyway, top posting is the default. > > This whole argument is analogous to rigorously not aligning braces in C > code because Ritchie did it. Or rigorously aligning braces in C code to > make comprehending easier. > > This reply is deliberately top posted with the reference material as a > short appendix. It is in plain text so rendering has no browser > dependancies and the archived version remains readable. > > James R. Cutler > James.cutler at consultant.com > GPG keys: hkps://hkps.pool.sks-keyservers.net > > > On Mon, Jan 14, 2019 at 8:39 PM wrote: > >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> A: Top-posting. >> Q: What is the most annoying thing on usenet and in e-mail? >> >> And now you're sitting here wondering what possible relevance that might >> have >> to some line or other - the only context you have at this point is that >> it's a >> reply to something you wrote. Actually, at this point you don't even have >> that. >> >> So you may have read this entire thing and now you're still wondering what >> possible relevance it may have to the thread. >> >> On Tue, 15 Jan 2019 00:24:30 -0500, bzs at theworld.com said: >> > Why dig through what you've already read to see the new comments? >> >> Or you can put the comment after, so everybody who reads text top to >> bottom has >> the context. I'm not away of any languages or writing systems that work >> from >> bottom to top, so that's pretty much everybody. And if people trimmed the >> quoted material so only the parts being replied to are left, there's not >> much >> digging involved. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Tue Jan 15 16:06:34 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 15 Jan 2019 08:06:34 -0800 Subject: plaintext email? In-Reply-To: <21276.1547530828@turing-police.cc.vt.edu> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: <5f6ba742-d59e-a72c-52e6-2b6273ab8bd5@satchell.net> On 1/14/19 9:40 PM, valdis.kletnieks at vt.edu wrote: > I'm not away of any languages or writing systems that work from > bottom to top, so that's pretty much everybody. Typography for at least one pictograph-based language allows for, um, interesting stunts one can pull to spice up gray matter. Starting in the middle of the paragraph and spiraling around, for example. Nothing which applies to e-mail, but now you know. From list at satchell.net Tue Jan 15 16:22:39 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 15 Jan 2019 08:22:39 -0800 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: <874laanxia.fsf@miraculix.mork.no> References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> <874laanxia.fsf@miraculix.mork.no> Message-ID: <98f96483-8997-24b6-6669-384144024b9b@satchell.net> On 1/15/19 12:19 AM, Bjørn Mork wrote: > And everyone has a gmail account anyway, so why bother with outside > email? Two words: "search warrants." I'm a US citizen, and I do NOT like the idea of power-hungry people being able to paw through my mail. Having my own mail server, residing in my home, with medium security in place, gives me peace of mind. Even innocent people have things they want to hide from casual spying. THOSE people don't have a need to know. Period. Not to mention that I can obey the rule common in Business 101 regarding mail. It goes like this: QUESTION: You are a medium-sized company. How do you set up your mail room to be efficient, and needing only a small staff? ANSWER: You take out a number of post office boxes, and have each department use its post office box to receive mail for that department. You task one person to stop at the post office to pick up the contents of the post office box, properly banded. In short, you let the postal system sort your mail for you. They are very good at it, and can even bring automation (that you can't afford) to speed up the process. For me, I have a mail server with several dozen inboxes (Postfix/Dovecot). Only a couple of those e-mail addresses have been exposed to the world via mailing lists and USENET. Thunderbird does a nice job of presenting this gaggle of inboxes. And I keep adding mailboxes as the need arises. I can see which inboxes has incoming mail, and selectively look at each one as time permits. Yes, I see all the incoming spam that makes it through the DNSBLs, but I can ignore the spam-catchers when I have better things to do. From Brian at ampr.org Tue Jan 15 16:23:49 2019 From: Brian at ampr.org (Brian Kantor) Date: Tue, 15 Jan 2019 08:23:49 -0800 Subject: Top Posting Was: Re: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> <35D88832-1031-4979-BD93-47983E18DCCC@consultant.com> Message-ID: <20190115162349.GA31267@meow.BKantor.net> > > Why must there be a hard rule about top posting? It is my belief that whether to 'top post' or 'bottom post' may largely depend on the characteristics of the medium. In USENET, bottom posting was preferred because messages often arrived out of order, and occasionally did not arrive at all, thus supplying the context of the reply before the reply itself would argueably increase the chance that a reply would be fully understood. Conversations might span days with only a very few contributions each day, and the context could be helpful. In modern Internet email, messages rarely are delayed very much, and rarely are lost in transit. In that environment, top posting allows someone who has been following the discussion closely may continue to follow it without the distraction of having to page past repeated text which he or she has already read and digested. But against simply omitting that context, at the bottom, it is there for those who would like to refresh their memory of previously-discussed points or for whom the mail did not arrive, or arrived late or out of order. Interleaved posting, such as might be used in a question-and-answer message, has a number of advantages over strict adherence to 'top' or 'bottom' exclusively. Conclusion: it pays to be versatile. - Brian From list at satchell.net Tue Jan 15 16:26:47 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 15 Jan 2019 08:26:47 -0800 Subject: Top Posting Was: Re: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> <35D88832-1031-4979-BD93-47983E18DCCC@consultant.com> Message-ID: On 1/15/19 8:03 AM, Tom Beecher wrote: > No disrespect intended to anyone at all, but the pissing and moaning about > it is a massive waste of time and energy. But, but, but...most water-cooler conversation is about sports, the opposite sex, and pissing and moaning about what you don't like. Sure, it's a massive waste of time and energy -- but that's what "being social" is all about. (Not that I claim to be THAT house-broken.) From wpolhamus at gmail.com Tue Jan 15 03:49:29 2019 From: wpolhamus at gmail.com (Winston Polhamus) Date: Mon, 14 Jan 2019 22:49:29 -0500 Subject: Top-quoting Was: (Netflix/GlobalConnect a/s) Scheduled Open Connect Appliance upgrade is starting In-Reply-To: References: <8b7c17f0bbb84e47ae4dc3cc536d4ed6@mail.dessus.com> Message-ID: <2CB671D4-D4A9-48DF-9523-66406116AA3A@gmail.com> +1 Sent from my iPhone > On Jan 14, 2019, at 10:37 PM, Stephen Satchell wrote: > >> On 1/14/19 7:14 PM, Keith Medcalf wrote: >> Please experience the wonders of the top-quote. See your local psychedelic distributor if you are somehow not "experiencing" anything ... > > I experience a savings in time with non-edited top quoting. If I don't > see meaningful new content within the first 20 lines, I ignore it as > worthless...unless it's a topic I'm following closely. > > And, yes, I use a text-only mail reader. I don't like HTML mail, > because it's an attack vector for ne'er-do-wells. As long as the mail > reader allows "self-clicking" URLs, just NO. > From cfillekes at gmail.com Tue Jan 15 15:34:16 2019 From: cfillekes at gmail.com (C. A. Fillekes) Date: Tue, 15 Jan 2019 10:34:16 -0500 Subject: ASNs decimation in ZW this morning Message-ID: So @meileaben on twitter this morning notes: Many #*Zimbabwe* Internet routes withdrawn around 9:30 UTC amidst civil unrest in the country. near-realtime on #*RIPEstat* here: https://stat.ripe.net/ZW # *OpenNetworkIntelligence* # *ZimbabweShutdown* https://twitter.com/meileaben/status/1085118237157851136 wondering if anyone here has additional info on that. Looing at stat.ripe.net/ZW now it looks as though one (out of an original 18, current 9) ASN has recovered, but kind of curious as to what exactly happened there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfillekes at gmail.com Tue Jan 15 15:42:53 2019 From: cfillekes at gmail.com (C. A. Fillekes) Date: Tue, 15 Jan 2019 10:42:53 -0500 Subject: ASNs decimation in ZW this morning In-Reply-To: References: Message-ID: On Tue, Jan 15, 2019 at 10:34 AM C. A. Fillekes wrote: > > So @meileaben on twitter this morning notes: > > Many #*Zimbabwe* Internet > routes withdrawn around 9:30 UTC amidst civil unrest in the country. > near-realtime on #*RIPEstat* > here: https:// > stat.ripe.net/ZW #*OpenNetworkIntelligence* > # > *ZimbabweShutdown* > > https://twitter.com/meileaben/status/1085118237157851136 > > wondering if anyone here has additional info on that. Looing at > stat.ripe.net/ZW now it looks as though one (out of an original 18, > current 9) ASN has recovered, but kind of curious as to what exactly > happened there. > So Bloomberg notes that a number of ISPs were shut down to quell online protest https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-zimbabwe-kills-commerce-and-the-lights but are there no work-arounds available, if implemented? -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at gt86car.org.uk Tue Jan 15 16:50:08 2019 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 15 Jan 2019 16:50:08 +0000 Subject: ASNs decimation in ZW this morning In-Reply-To: References: Message-ID: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> sorry top posting, yup whatsup doesnt work in harare. phone circuits land ok though and checked ok col Sent from my iPod > On 15 Jan 2019, at 15:42, C. A. Fillekes wrote: > > > >> On Tue, Jan 15, 2019 at 10:34 AM C. A. Fillekes wrote: >> >> So @meileaben on twitter this morning notes: >> >> Many #Zimbabwe Internet routes withdrawn around 9:30 UTC amidst civil unrest in the country. near-realtime on #RIPEstat here: https://stat.ripe.net/ZW #OpenNetworkIntelligence #ZimbabweShutdown >> >> https://twitter.com/meileaben/status/1085118237157851136 >> >> wondering if anyone here has additional info on that. Looing at stat.ripe.net/ZW now it looks as though one (out of an original 18, current 9) ASN has recovered, but kind of curious as to what exactly happened there. > > So Bloomberg notes that a number of ISPs were shut down to quell online protest > https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-zimbabwe-kills-commerce-and-the-lights but are there no work-arounds available, if implemented? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscar.vives at gmail.com Tue Jan 15 17:46:07 2019 From: oscar.vives at gmail.com (Tei) Date: Tue, 15 Jan 2019 18:46:07 +0100 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: <874laanxia.fsf@miraculix.mork.no> References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> <874laanxia.fsf@miraculix.mork.no> Message-ID: On Tue, 15 Jan 2019 at 09:21, Bjørn Mork wrote: .. > open protocols, just shut off SMTP completely. They'll > probably "invent" something much better as an excuse... And the masses > will love them for that, because it finally removed the spam "problem". > > And everyone has a gmail account anyway, so why bother with outside > email? I think the newsgroups died because was expensive for ISPs and filled with nasty stuff (warez and porn). Gopher died because HTML was a improvement in every possible way. IRC still exist, because it don't need to be hosted by a ISP. Forums still exist. Mail list still exist (we are on one) Homesites where replaced by blogs. Gmail? G Suite accounts are expensive. I believe you have to pay by email address and get quite pricey. "Free" alternatives have a place because can be cheaper than that. Gmail have not added the "Foo has read your message" or "Foo is replying to your email". Two things that would be easy for them to do in Gmail to Gmail communication, and would be must-have features for a mail user. So maybe they don't aim to world domination? Is very hard to replace a open protocol, wrapping may work if the protocol is mostly abandoned (IRC) but thats not the case for email. I don't think email is going to be replaced soon. -- -- ℱin del ℳensaje. From johnl at iecc.com Tue Jan 15 18:06:42 2019 From: johnl at iecc.com (John Levine) Date: 15 Jan 2019 13:06:42 -0500 Subject: Top Posting Was: Re: plaintext email? In-Reply-To: <35D88832-1031-4979-BD93-47983E18DCCC@consultant.com> Message-ID: <20190115180642.EFD37200CA8498@ary.qy> In article <35D88832-1031-4979-BD93-47983E18DCCC at consultant.com> you write: >-=-=-=-=-=- > >Why must there be a hard rule about top posting? Because we're nerds and whatever made sense in 1983 still make sense today, because nothing has changed. By the way, have you changed and memorized all your passwords for this month yet? R's, John From bzs at theworld.com Tue Jan 15 18:36:38 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 15 Jan 2019 13:36:38 -0500 Subject: plaintext email? In-Reply-To: <21276.1547530828@turing-police.cc.vt.edu> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: <23614.10294.120062.950231@gargle.gargle.HOWL> Re: Top Posting To me it depends on whether there's any chance the reader won't know what precisely you're responding to in which case in-line is warranted. I don't have any quoted text in this msg (is that top posting?), is anyone lost? THE REAL REASON for my responding at all is because there are people who lurk and sometimes manage lists who will react angrily, often in private email (cowards! :-) ), to a top-post as if you violated some inarguable rule and you maybe should be banned or at the very least are very rude, similar in tone to if you'd spammed the list or whatever. I just thought I'd point out it's just a formatting opinion, a judgement call by whoever is responding, and nothing more, it's not some rule everyone accepts so lose the self-righteous tone. If anything I suspect it might have to do with the MUA one uses. Maybe, at the very least, accept that the person who top-posted is looking at a very different layout than you are, one where that top-post looks just fine? I use Emacs/VM for email. It's quite good at, for example, splitting the screen so I can look ahead (or behind) in the message if I've lost track of some context, or even opening multiple related msgs (even if already filed) simultaneously to go back and review what's been said already, or forward even to see if one is about to say something which has already been adequately addressed. It's probably quite a bit different than the one-way upside-down (date-wise) scrolling on some vendor-supplied smartphone app. I've used them when I've had nothing else and I haven't a clue how one can do much else than essentially "more" thru the latest, silo'd, 10^9 spams interspersed with the occasional bit of ham 20 lines at a time so I guess I can understand why some become desperate and angry to get others to format their email for their convenience. Maybe your problem isn't the top-posting but your lousy MUA? -- -Barry Shein Software Tool & Die | bzs at 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* From bzs at theworld.com Tue Jan 15 18:37:27 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 15 Jan 2019 13:37:27 -0500 Subject: plaintext email? In-Reply-To: <21276.1547530828@turing-police.cc.vt.edu> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> Message-ID: <23614.10343.373510.313099@gargle.gargle.HOWL> On January 15, 2019 at 00:40 valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) wrote: > A: Because it messes up the order in which people normally read text. P.S. No, you already read the quoted text, that's how it got to be quoted text. -- -Barry Shein Software Tool & Die | bzs at 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* From bill at herrin.us Tue Jan 15 18:47:17 2019 From: bill at herrin.us (William Herrin) Date: Tue, 15 Jan 2019 10:47:17 -0800 Subject: plaintext email? In-Reply-To: <23614.10294.120062.950231@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> <23614.10294.120062.950231@gargle.gargle.HOWL> Message-ID: On Tue, Jan 15, 2019 at 10:37 AM wrote: > To me it depends on whether there's any chance the reader won't know > what precisely you're responding to in which case in-line is > warranted. In a one-to-one private email you can reasonably assume that either the recipient is familiar with the chain of discussion or is sufficiently invested to scroll down for any missing context. In a mailing list or multiple-recipient message, that's not a fair assumption. A more reasonable assumption is that the recipient has not been monitoring the thread until something specific you wrote caught their eye. In that situation, asking them to hunt through a long chain for the little bits of relevant context is, well, rude. And if you run folks around in circles responding to the same questions because the context that answered those questions was hard to find, that's even worse. Which is why top posting to a mailing list is considered rude. At least IMHO. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lvanbever at ethz.ch Tue Jan 15 18:59:57 2019 From: lvanbever at ethz.ch (Vanbever Laurent) Date: Tue, 15 Jan 2019 18:59:57 +0000 Subject: Your opinion on network analysis in the presence of uncertain events Message-ID: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> Hi NANOG, Networks evolve in uncertain environments. Links and devices randomly fail; external BGP announcements unpredictably appear/disappear leading to unforeseen traffic shifts; traffic demands vary, etc. Reasoning about network behaviors under such uncertainties is hard and yet essential to ensure Service Level Agreements. We're reaching out to the NANOG community as we (researchers) are trying to better understand the practical requirements behind "probabilistic" network reasoning. Some of our questions include: Are uncertain behaviors problematic? Do you care about such things at all? Are you already using tools to ensure the compliance of your network design under uncertainty? Are there any good? We designed a short anonymous survey to collect operators answers. It is composed of 14 optional questions, most of which (13/14) are closed-ended. It should take less than 10 minutes to complete. We expect the findings to help the research community in designing more powerful network analysis tools. Among others, we intend to present the aggregate results in a scientific article later this year. It would be *terrific* if you could help us out! Survey URL: https://goo.gl/forms/HdYNp3DkKkeEcexs2 Thanks much! Laurent Vanbever, ETH Zürich PS: It goes without saying that we would also be extremely grateful if you could forward this email to any operator you know and who may not read NANOG. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egon at egon.cc Tue Jan 15 19:10:07 2019 From: egon at egon.cc (James Downs) Date: Tue, 15 Jan 2019 11:10:07 -0800 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> <874laanxia.fsf@miraculix.mork.no> Message-ID: <20190115191007.GH15832@nemesis.egontech.com> On Tue, Jan 15, 2019 at 06:46:07PM +0100, Tei wrote: > Is very hard to replace a open protocol, wrapping may work if the > protocol is mostly abandoned (IRC) but thats not the case for email. IRC is far from abandonded. There are lots of very active networks, 2 of which I use continously. But, it's been a week of non-NANOG talk, so.... Cheers, -j From valdis.kletnieks at vt.edu Tue Jan 15 19:23:48 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 15 Jan 2019 14:23:48 -0500 Subject: plaintext email? Message-ID: <24873.1547580228@turing-police.cc.vt.edu> Without reading further... which of your recent postings is this a reply to? Obviously you already know, because you said you don't need to see the text to know the context... Nope, it wasn't the one about how things became quoted text. On Tue, 15 Jan 2019 13:36:38 -0500, bzs at theworld.com said: > I use Emacs/VM for email. It's quite good at, for example, splitting > the screen so I can look ahead (or behind) in the message if I've lost > track of some context, or even opening multiple related msgs (even if > already filed) simultaneously to go back and review what's been said > already, or forward even to see if one is about to say something which > has already been adequately addressed. And how many times did you have to hit control-alt-meta-cokebottle to trace out which one this was really a reply to? From brian at interlinx.bc.ca Tue Jan 15 19:24:20 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Tue, 15 Jan 2019 14:24:20 -0500 Subject: plaintext email? In-Reply-To: <23613.28302.372008.410882@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: <7cf34987283270d9cb9f08323277bc8cf2847abc.camel@interlinx.bc.ca> On Tue, 2019-01-15 at 00:24 -0500, bzs at theworld.com wrote: > I'd like to go on record as saying that I PREFER top-posting. > > Why dig through what you've already read to see the new comments? Because in long discussion threads, you lose the context to exactly what a particular person is replying to/about. When they answer inline (or bottom posting if there is just one thing to say) you get the context as to what they are talking about. > Actually in an ideal world previous included bits would be links > which > could optionally be expanded via one shared remote copy but lo I > wander. Right. So you are actually advocating for inline/bottom-posting with appropriate trimming and the added benefit of being able to collapse the trimmed quote. That could very well and easily be an MUA feature. But you started your message by saying you prefer top posting. > You should try some of the internet governance (I know, oxymoron) > lists where people will inline a megabyte of discussion to add just > "+1!" or "I agree!" or "congrats!" in the middle or bottom. It's like > Alice's Restaurant. That's a different problem that IMHO, top posting actually perpetuates: lack of trimming. Top posting makes it too easy to send along the entire copies of all of the messages that previous top-posters posted and didn't trim. When you encourage inline replying or bottom posting, it seems to point out, only if slightly more, than one could trim the useless content as one goes by it to inline/bottom post. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From Brian at ampr.org Tue Jan 15 19:26:49 2019 From: Brian at ampr.org (Brian Kantor) Date: Tue, 15 Jan 2019 11:26:49 -0800 Subject: plaintext email? In-Reply-To: <24873.1547580228@turing-police.cc.vt.edu> References: <24873.1547580228@turing-police.cc.vt.edu> Message-ID: <20190115192649.GA32592@meow.BKantor.net> On Tue, Jan 15, 2019 at 02:23:48PM -0500, valdis.kletnieks at vt.edu wrote: > Without reading further... which of your recent postings is this a reply to? > Obviously you already know, because you said you don't need to see the > text to know the context... Gentlemen, this is getting petty. Perhaps it's time to drop the subject? Or at least take it to private email? - Brian From mel at beckman.org Tue Jan 15 19:27:28 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 15 Jan 2019 19:27:28 +0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> Message-ID: <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org> I took the survey. It’s short and sweet — well done! I do have a question. You ask "Are there any good?” Any good what? -mel On Jan 15, 2019, at 10:59 AM, Vanbever Laurent > wrote: Hi NANOG, Networks evolve in uncertain environments. Links and devices randomly fail; external BGP announcements unpredictably appear/disappear leading to unforeseen traffic shifts; traffic demands vary, etc. Reasoning about network behaviors under such uncertainties is hard and yet essential to ensure Service Level Agreements. We're reaching out to the NANOG community as we (researchers) are trying to better understand the practical requirements behind "probabilistic" network reasoning. Some of our questions include: Are uncertain behaviors problematic? Do you care about such things at all? Are you already using tools to ensure the compliance of your network design under uncertainty? Are there any good? We designed a short anonymous survey to collect operators answers. It is composed of 14 optional questions, most of which (13/14) are closed-ended. It should take less than 10 minutes to complete. We expect the findings to help the research community in designing more powerful network analysis tools. Among others, we intend to present the aggregate results in a scientific article later this year. It would be *terrific* if you could help us out! Survey URL: https://goo.gl/forms/HdYNp3DkKkeEcexs2 Thanks much! Laurent Vanbever, ETH Zürich PS: It goes without saying that we would also be extremely grateful if you could forward this email to any operator you know and who may not read NANOG. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Tue Jan 15 19:43:21 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Jan 2019 12:43:21 -0700 Subject: plaintext email? In-Reply-To: <23614.10343.373510.313099@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> <23614.10343.373510.313099@gargle.gargle.HOWL> Message-ID: <9269492d-f026-4354-af90-c19438630738@spamtrap.tnetconsulting.net> On 01/15/2019 11:37 AM, bzs at theworld.com wrote: > P.S. No, you already read the quoted text, that's how it got to be > quoted text. Are you making reference to having read the quoted text in a different email? An email that someone might not have received, much less read yet? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Tue Jan 15 19:52:06 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 15 Jan 2019 12:52:06 -0700 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: References: <871s5gpz1w.fsf@miraculix.mork.no> <20190113170815.DB47A200C9C7E8@ary.qy> <23611.60004.800271.326638@gargle.gargle.HOWL> <90cff09a-9e97-bde5-f310-c40f637cf1be@meetinghouse.net> <874laanxia.fsf@miraculix.mork.no> Message-ID: On 01/15/2019 10:46 AM, Tei wrote: > I think the newsgroups died because was expensive for ISPs and filled > with nasty stuff (warez and porn). I believe newsgroups are still very much so alive and quite active. I see 15k ~ 20k messages / 50 ~ 75 MB of /text/ newsgroups daily on my server. My ~15 (I don't remember the exact number and can't be bothered to loo) peers will likely agree with me. I see content on Usenet that is not available elsewhere. There's also the binary news servers that are used to trade warz and pr0n and other untold things. > Gopher died because HTML was a improvement in every possible way. I still see references to people using Gopher multiple times a year. > IRC still exist, Yep. I use it daily. > because it don't need to be hosted by a ISP. I don't think an ISP is required to host any of the things being discussed in this email. > Forums still exist. Yep. Some of them even gateway into other communication mediums. > Mail list still exist (we are on one) Homesites where replaced by blogs. Based on what I /personally/ see, mailing lists and usenet are roughly comparable. > Gmail? Meh. > G Suite accounts are expensive. I believe you have to pay by email > address and get quite pricey. "Free" alternatives have a place because > can be cheaper than that. > > Gmail have not added the "Foo has read your message" or "Foo is replying > to your email". Two things that would be easy for them to do in Gmail > to Gmail communication, and would be must-have features for a mail user. > So maybe they don't aim to world domination? I've said it before, and I'll say it again. Email is not instant messaging. > Is very hard to replace a open protocol, wrapping may work if the > protocol is mostly abandoned (IRC) but thats not the case for email. > I don't think email is going to be replaced soon. There are people who say it yearly. But I never believe them. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From lvanbever at ethz.ch Tue Jan 15 19:58:22 2019 From: lvanbever at ethz.ch (Vanbever Laurent) Date: Tue, 15 Jan 2019 19:58:22 +0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org> References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org> Message-ID: > I took the survey. It’s short and sweet — well done! Thanks a lot, Mel! Highly appreciated! > I do have a question. You ask "Are there any good?” Any good what? I just meant whether existing network analysis tools were any good (or good enough) at reasoning about probabilistic behaviors that people care about (if any). All the best, Laurent From james.cutler at consultant.com Tue Jan 15 20:10:10 2019 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 15 Jan 2019 15:10:10 -0500 Subject: Top Posting Was: Re: plaintext email? In-Reply-To: <20190115180642.EFD37200CA8498@ary.qy> References: <20190115180642.EFD37200CA8498@ary.qy> Message-ID: <418E2327-636D-48AA-8C26-B4554B38875C@consultant.com> On Jan 15, 2019, at 1:06 PM, John Levine wrote: > > By the way, have you changed and memorized all your passwords for this > month yet? No, I do not follow a predictable rhythm in changing passwords. Some change frequently, some change infrequently. I only remember my login password, my iDevice PINs, and my 1Password password. 1Password generates and remembers all the rest. Changing passwords frequently is not effective if passwords are re-used between multiple sites. This continues to be the number one rule the I try to inculcate in my clients. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.cutler at consultant.com Tue Jan 15 20:42:30 2019 From: james.cutler at consultant.com (James R Cutler) Date: Tue, 15 Jan 2019 15:42:30 -0500 Subject: plaintext email? In-Reply-To: <23614.10294.120062.950231@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> <21276.1547530828@turing-police.cc.vt.edu> <23614.10294.120062.950231@gargle.gargle.HOWL> Message-ID: Warning —top posting also with interspersed comments. 👍🏻 <— that’s a thumbs up > On Jan 15, 2019, at 1:36 PM, bzs at theworld.com wrote: > > > Re: Top Posting > > To me it depends on whether there's any chance the reader won't know > what precisely you're responding to in which case in-line is > warranted. > > I don't have any quoted text in this msg (is that top posting?), is > anyone lost? > > THE REAL REASON for my responding at all is because there are people > who lurk and sometimes manage lists who will react angrily, often in > private email (cowards! :-) ), to a top-post as if you violated some > inarguable rule and you maybe should be banned or at the very least > are very rude, similar in tone to if you'd spammed the list or > whatever. I am appalled at the nastiness regarding posting prejudices. "But, but, if your cognitive processes do not match mine, you are an idiot.” “Why should I love my neighbor as myself? I am so much better" > > I just thought I'd point out it's just a formatting opinion, a > judgement call by whoever is responding, and nothing more, it's not > some rule everyone accepts so lose the self-righteous tone. > > If anything I suspect it might have to do with the MUA one uses. > > Maybe, at the very least, accept that the person who top-posted is > looking at a very different layout than you are, one where that > top-post looks just fine? And the viewer/replier may have significantly different cognitive skills. > > I use Emacs/VM for email. It's quite good at, for example, splitting > the screen so I can look ahead (or behind) in the message if I've lost > track of some context, or even opening multiple related msgs (even if > already filed) simultaneously to go back and review what's been said > already, or forward even to see if one is about to say something which > has already been adequately addressed. > > It's probably quite a bit different than the one-way upside-down > (date-wise) scrolling on some vendor-supplied smartphone app. > > I've used them when I've had nothing else and I haven't a clue how one > can do much else than essentially "more" thru the latest, silo'd, 10^9 > spams interspersed with the occasional bit of ham 20 lines at a time > so I guess I can understand why some become desperate and angry to get > others to format their email for their convenience. > > Maybe your problem isn't the top-posting but your lousy MUA? Or, perhaps, attitude? > > -- > -Barry Shein > > Software Tool & Die | bzs at 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* James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Tue Jan 15 21:04:28 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 15 Jan 2019 16:04:28 -0500 Subject: plaintext email? In-Reply-To: <23613.28302.372008.410882@gargle.gargle.HOWL> References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: On 1/15/19 12:24 AM, bzs at theworld.com wrote: > I'd like to go on record as saying that I PREFER top-posting. It's like having an @aol.com address. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From clinton.mielke at gmail.com Tue Jan 15 21:58:53 2019 From: clinton.mielke at gmail.com (cosmo) Date: Tue, 15 Jan 2019 13:58:53 -0800 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: Sudden plot-twist! A small elite group of NANOG participants have been using stenographic forms of encryption in the messages all along! On Tue, Jan 15, 2019 at 1:06 PM Bryan Fields wrote: > On 1/15/19 12:24 AM, bzs at theworld.com wrote: > > I'd like to go on record as saying that I PREFER top-posting. > > It's like having an @aol.com address. > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Jan 15 22:03:42 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 15 Jan 2019 14:03:42 -0800 Subject: dyn internet intelligence Message-ID: can someone from dyn reach out to me offline? https://dyn.com/dyn-internet-intelligence/ i have been trying to subscribe and pay for this service and i am getting sales people ping me and not follow up with price information (which is weird...) thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Tue Jan 15 22:05:54 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Tue, 15 Jan 2019 22:05:54 +0000 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: You can hide your secret message by writing: dash dash space return Followed by your message. It’ll be hidden from all but the Internet illuminati Aled On Tue, 15 Jan 2019 at 22:00, cosmo wrote: > Sudden plot-twist! > > A small elite group of NANOG participants have been using stenographic > forms of encryption in the messages all along! > > On Tue, Jan 15, 2019 at 1:06 PM Bryan Fields > wrote: > >> On 1/15/19 12:24 AM, bzs at theworld.com wrote: >> > I'd like to go on record as saying that I PREFER top-posting. >> >> It's like having an @aol.com address. > > >> >> -- >> Bryan Fields >> >> 727-409-1194 - Voice >> http://bryanfields.net >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Tue Jan 15 22:16:02 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 15 Jan 2019 17:16:02 -0500 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: On Tue, Jan 15, 2019 at 5:07 PM Aled Morris via NANOG wrote: > You can hide your secret message by writing: > > dash dash space return > > Followed by your message. > > It’ll be hidden from all but the Internet illuminati > > -- is that true? > Aled > > > On Tue, 15 Jan 2019 at 22:00, cosmo wrote: > >> Sudden plot-twist! >> >> A small elite group of NANOG participants have been using stenographic >> forms of encryption in the messages all along! >> >> On Tue, Jan 15, 2019 at 1:06 PM Bryan Fields >> wrote: >> >>> On 1/15/19 12:24 AM, bzs at theworld.com wrote: >>> > I'd like to go on record as saying that I PREFER top-posting. >>> >>> It's like having an @aol.com address. >> >> >>> >>> -- >>> Bryan Fields >>> >>> 727-409-1194 - Voice >>> http://bryanfields.net >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Tue Jan 15 22:30:39 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 15 Jan 2019 17:30:39 -0500 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: On 1/15/19 5:16 PM, Christopher Morrow wrote: > On Tue, Jan 15, 2019 at 5:07 PM Aled Morris via NANOG > wrote: Please don't post empty messages to the NANOG list. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From mel at beckman.org Tue Jan 15 22:40:19 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 15 Jan 2019 22:40:19 +0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org>, Message-ID: I know of none that take probabilities as inputs. Traditional network simulators, such as GNS3, let you model various failure modes, but probability seems squishy enough that I don’t see how it can be accurate, and thus helpful. It’s like that Dilbert cartoon where the pointy haired boss asks for a schedule of all future unplanned outages :) https://dilbert.com/strip/1997-01-29 -mel On Jan 15, 2019, at 11:59 AM, Vanbever Laurent > wrote: I took the survey. It’s short and sweet — well done! Thanks a lot, Mel! Highly appreciated! I do have a question. You ask "Are there any good?” Any good what? I just meant whether existing network analysis tools were any good (or good enough) at reasoning about probabilistic behaviors that people care about (if any). All the best, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Wed Jan 16 01:25:43 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 15 Jan 2019 18:25:43 -0700 Subject: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk... In-Reply-To: <20190115191007.GH15832@nemesis.egontech.com> Message-ID: On Tuesday, 15 January, 2019 12:10, James Downs wrote: >On Tue, Jan 15, 2019 at 06:46:07PM +0100, Tei wrote: >> Is very hard to replace a open protocol, wrapping may work if the >> protocol is mostly abandoned (IRC) but thats not the case for >> email. > IRC is far from abandonded. There are lots of very active networks, > 2 of which I use continously. > > But, it's been a week of non-NANOG talk, so.... Plus there is IRC by web pages -- you know where all the Twit's hang out .. Twittering amongst themselves. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From bzs at theworld.com Wed Jan 16 03:57:09 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 15 Jan 2019 22:57:09 -0500 Subject: plaintext email? In-Reply-To: References: <20190114205218.B0192200CA2E8C@ary.qy> <23613.28302.372008.410882@gargle.gargle.HOWL> Message-ID: <23614.43925.919938.752260@gargle.gargle.HOWL> On January 15, 2019 at 13:58 clinton.mielke at gmail.com (cosmo) wrote: > Sudden plot-twist! > > A small elite group of NANOG participants have been using stenographic forms of > encryption in the messages all along!  Did you mean steganographic? I only ask because someone might learn something if they have the right term, it's an interesting topic for those who are interested: https://en.wikipedia.org/wiki/Steganography -- -Barry Shein Software Tool & Die | bzs at 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* From johnl at iecc.com Wed Jan 16 05:04:44 2019 From: johnl at iecc.com (John Levine) Date: 16 Jan 2019 00:04:44 -0500 Subject: plaintext email? In-Reply-To: <23614.43925.919938.752260@gargle.gargle.HOWL> Message-ID: <20190116050445.51C91200CADFD1@ary.qy> > > Sudden plot-twist! > > > > A small elite group of NANOG participants have been using stenographic forms of > > encryption in the messages all along!� > >Did you mean steganographic? No, stenographic, like, you know, double rot13. R's, John From clinton.mielke at gmail.com Wed Jan 16 05:10:12 2019 From: clinton.mielke at gmail.com (cosmo) Date: Tue, 15 Jan 2019 21:10:12 -0800 Subject: plaintext email? In-Reply-To: <20190116050445.51C91200CADFD1@ary.qy> References: <23614.43925.919938.752260@gargle.gargle.HOWL> <20190116050445.51C91200CADFD1@ary.qy> Message-ID: You're way too close to the truth. The steganographic code is based on typos..... (bit rate is rather shit) Now you must be .... Elluminated On Tue, Jan 15, 2019 at 9:06 PM John Levine wrote: > > > Sudden plot-twist! > > > > > > A small elite group of NANOG participants have been using stenographic > forms of > > > encryption in the messages all along! > > > >Did you mean steganographic? > > No, stenographic, like, you know, double rot13. > > R's, > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Wed Jan 16 06:20:46 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 16 Jan 2019 01:20:46 -0500 Subject: plaintext email? In-Reply-To: <20190116050445.51C91200CADFD1@ary.qy> References: <23614.43925.919938.752260@gargle.gargle.HOWL> <20190116050445.51C91200CADFD1@ary.qy> Message-ID: <23614.52542.21279.136210@gargle.gargle.HOWL> On January 16, 2019 at 00:04 johnl at iecc.com (John Levine) wrote: > > > Sudden plot-twist! > > > > > > A small elite group of NANOG participants have been using stenographic forms of > > > encryption in the messages all along!� > > > >Did you mean steganographic? > > No, stenographic, like, you know, double rot13. Well slap my butt and call me Gregg! -- -Barry Shein Software Tool & Die | bzs at 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* From mark.tinka at seacom.mu Wed Jan 16 07:50:27 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 16 Jan 2019 09:50:27 +0200 Subject: Service Provider NetFlow Collectors In-Reply-To: <0C6662D2-2116-4CC2-B57E-7E01332A5045@etc1.net> References: <2066108599.2244.1546274442993.JavaMail.mhammett@ThunderFuck> <0C6662D2-2116-4CC2-B57E-7E01332A5045@etc1.net> Message-ID: <3e4f74b4-0e52-03be-87fa-c27d0e27fb29@seacom.mu> We were on Arbor for quite some time, but are now moving to Kentik. Mark. On 3/Jan/19 05:37, Nick Peelman wrote: > We rolled a large(ish) ElasticSearch cluster last year out of SuperMicro Microclouds (3U, 8 nodes per chassis, Xeon-D based processors), mostly 32GB of RAM per node, and M.2 PCIe SSDs as well as HDD storage. ES is a finicky beast to maintain. It can handle a node completely dying or disappearing from the network, but not when one runs out of space (at least not gracefully). Maintaining retention and rotation is tedious at best (yay curator). We’re dumping a boatload of log data there, as well as Flow data using Elastiflow, which provides the necessary collector bits as well as all the pretty Kibana graphs and stuff. Probably overbuilt, but I can pretty much keep whatever logs we want in perpetuity, we have plenty of headroom, and searching is incredibly fast. > > ELK is an awesome set of tools, but be warned, there be dragons. Admin’ing even a small cluster can be time consuming and frustrating, and requires a pretty stout linux and server background, or at least some really good troubleshooting skills and an ability to turn to the code when the docs fall short. Doing a larger cluster could easily be a full time job. Still, all in all, I’m happy with the cost of ours, including my time building it and continued time maintaining it, compared to what the yearly outlay was going to be for Kentik. > > -nick > > On 31 Dec 2018, at 11:40, Mike Hammett > wrote: > > I just recently rolled out Elastiflow. Lots of great information. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ________________________________ > From: "Michel 'ic' Luczak" > > To: "Erik Sundberg" > > Cc: nanog at nanog.org > Sent: Monday, December 31, 2018 3:40:40 AM > Subject: Re: Service Provider NetFlow Collectors > > Don’t underestimate good old ELK > https://www.elastic.co/guide/en/logstash/current/netflow-module.html > + https://github.com/robcowart/elastiflow > > BR, ic > > On 31 Dec 2018, at 04:29, Erik Sundberg > wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. > > We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer – Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance… > > Erik > > > ________________________________ > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jan 16 07:56:00 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 16 Jan 2019 09:56:00 +0200 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> Message-ID: <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> On 3/Jan/19 22:08, Andy Davidson wrote: > There are no stupid questions! It is a good idea to not BGP announce and perhaps also to drop traffic toward peering LAN prefixes at customer-borders, this was already well discussed in the thread. But there wasn’t a discussion on how we got to this point. Until the Cloudflare 2013 BGP speaker attack, that sought to flood Cloudflare’s transfer networks and exchange connectivity (and with it saturating IXP inter-switch links and IXP participant ports), it was common for IXP IPv4/6 peering LANs to be internet reachable and BGP transited. That's interesting to learn. Running a few exchange points in Africa since 2002, the news was that the exchange point LAN should not be visible anywhere on the Internet. It would be interesting to know that this wasn't the case in other parts of the world. Mark. From job at instituut.net Wed Jan 16 08:06:06 2019 From: job at instituut.net (Job Snijders) Date: Wed, 16 Jan 2019 11:06:06 +0300 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> Message-ID: On Wed, Jan 16, 2019 at 10:56 Mark Tinka wrote: > On 3/Jan/19 22:08, Andy Davidson wrote: > > > There are no stupid questions! It is a good idea to not BGP announce > and perhaps also to drop traffic toward peering LAN prefixes at > customer-borders, this was already well discussed in the thread. But there > wasn’t a discussion on how we got to this point. Until the Cloudflare 2013 > BGP speaker attack, that sought to flood Cloudflare’s transfer networks and > exchange connectivity (and with it saturating IXP inter-switch links and > IXP participant ports), it was common for IXP IPv4/6 peering LANs to be > internet reachable and BGP transited. > > That's interesting to learn. > > Running a few exchange points in Africa since 2002, the news was that > the exchange point LAN should not be visible anywhere on the Internet. > It would be interesting to know that this wasn't the case in other parts > of the world. Some IX’s use a globally reachable peering lan prefix as a convenience for their participants as “poor man’s out-of-band”, or can’t designate a separate /24 for the IXP’s website / public services. I can see some use cases, but in today’s internet landscape the practice just increases the attack surface, so it’s not the Best Current Practise. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer at netravnen.de Wed Jan 16 09:38:31 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Wed, 16 Jan 2019 10:38:31 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> Message-ID: <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> On 16/01/2019 08:56, Mark Tinka wrote: > Running a few exchange points in Africa since 2002, the news was that > the exchange point LAN should not be visible anywhere on the Internet. Do you use AS0 as origin on the RPKI objects for said exchange point LAN(s) to prevent route propagation? -Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From job at ntt.net Wed Jan 16 09:42:32 2019 From: job at ntt.net (Job Snijders) Date: Wed, 16 Jan 2019 12:42:32 +0300 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: On Wed, Jan 16, 2019 at 12:39 Christoffer Hansen wrote: > > On 16/01/2019 08:56, Mark Tinka wrote: > > Running a few exchange points in Africa since 2002, the news was that > > the exchange point LAN should not be visible anywhere on the Internet. > > Do you use AS0 as origin on the RPKI objects for said exchange point > LAN(s) to prevent route propagation? Either AS 0, or the ASN of the IXP’s service network are valid options. Whatever ASN is listed in the RPKI ROA, should simply never announce the prefix. IXPs should make sure to not set MaxLength to allow anything more-l specific, it should be equal to the prefix length. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jan 16 11:46:02 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 16 Jan 2019 13:46:02 +0200 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> Message-ID: <844ab37b-5f1b-a440-0ffa-47bb4dcf0a3b@seacom.mu> On 16/Jan/19 10:06, Job Snijders wrote: > > > I can see some use cases, but in today’s internet landscape the > practice just increases the attack surface, so it’s not the Best > Current Practise. I would say... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jan 16 11:46:50 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 16 Jan 2019 13:46:50 +0200 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: On 16/Jan/19 11:38, Christoffer Hansen wrote: > Do you use AS0 as origin on the RPKI objects for said exchange point > LAN(s) to prevent route propagation? I don't operate any exchange points anymore, but I am not aware of any such operation of AS0 this side of the globe. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From job at ntt.net Wed Jan 16 11:54:20 2019 From: job at ntt.net (Job Snijders) Date: Wed, 16 Jan 2019 14:54:20 +0300 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: On Wed, Jan 16, 2019 at 14:49 Mark Tinka wrote: > On 16/Jan/19 11:38, Christoffer Hansen wrote: > > > Do you use AS0 as origin on the RPKI objects for said exchange point > > LAN(s) to prevent route propagation? > > I don't operate any exchange points anymore, but I am not aware of any > such operation of AS0 this side of the globe. Perhaps that is because for a while you couldn’t set AS 0 in AFRINIC ROAs as Origin ASN. I think that’s fixed now. Kind regards, Job > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Jan 16 12:20:39 2019 From: randy at psg.com (Randy Bush) Date: Wed, 16 Jan 2019 04:20:39 -0800 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> Message-ID: > Running a few exchange points in Africa since 2002, the news was that > the exchange point LAN should not be visible anywhere on the Internet. > It would be interesting to know that this wasn't the case in other parts > of the world. slide 8 of http://archive.psg.com/970210.nanog.pdf From randy at psg.com Wed Jan 16 12:22:50 2019 From: randy at psg.com (Randy Bush) Date: Wed, 16 Jan 2019 04:22:50 -0800 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: > Do you use AS0 as origin on the RPKI objects for said exchange point > LAN(s) to prevent route propagation? but as0 does not exactly do that as it can be overridden by a different roa for the same prefix. as0 is pretty useless. randy From job at instituut.net Wed Jan 16 12:25:41 2019 From: job at instituut.net (Job Snijders) Date: Wed, 16 Jan 2019 15:25:41 +0300 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: On Wed, Jan 16, 2019 at 15:24 Randy Bush wrote: > > Do you use AS0 as origin on the RPKI objects for said exchange point > > LAN(s) to prevent route propagation? > > but as0 does not exactly do that as it can be overridden by a different > roa for the same prefix. as0 is pretty useless. Why would the IXP create such a second ROA? Do you mean to say “a tool can be useless when applied incorrectly”? -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at gt86car.org.uk Wed Jan 16 13:54:39 2019 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 16 Jan 2019 13:54:39 +0000 Subject: ASNs decimation in ZW this morning In-Reply-To: References: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> Message-ID: <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> > On 15 Jan 2019, at 17:03, C. A. Fillekes wrote: > > > Whole countries falling off the net? BUT TEH TOP POSTINGS!!! > > I'm a little frustrated with the very existence of that thread. > > Trying to constructively change the topic to something more interesting lol. > > I guess the concerning thing to me is that the whole point of packet switched networks was to provide resilience in the face of e.g. civil disorder. > > On Tue, Jan 15, 2019 at 11:50 AM Colin Johnston > wrote: > sorry top posting, > yup whatsup doesnt work in harare. > phone circuits land ok though and checked ok > > col > > Sent from my iPod > > On 15 Jan 2019, at 15:42, C. A. Fillekes > wrote: > >> >> >> On Tue, Jan 15, 2019 at 10:34 AM C. A. Fillekes > wrote: >> >> So @meileaben on twitter this morning notes: >> >> Many #Zimbabwe Internet routes withdrawn around 9:30 UTC amidst civil unrest in the country. near-realtime on #RIPEstat here: https://stat.ripe.net/ZW  #OpenNetworkIntelligence #ZimbabweShutdown >> >> https://twitter.com/meileaben/status/1085118237157851136 >> >> wondering if anyone here has additional info on that. Looing at stat.ripe.net/ZW now it looks as though one (out of an original 18, current 9) ASN has recovered, but kind of curious as to what exactly happened there. >> >> So Bloomberg notes that a number of ISPs were shut down to quell online protest >> https://www.bloomberg.com/news/articles/2019-01-15/by-killing-the-internet-zimbabwe-kills-commerce-and-the-lights but are there no work-arounds available, if implemented? zimbabwe situation link below re telecom problems https://www.zimbabwesituation.com/news/zimbabwe-telecoms-jammed-after-violent-protests-report/ I was back in Zim myself last month as well to see family children, internet was working well then inc whats up, mobile and adsl. I wonder how they block social media sites/whats up, is it null routing on peering cores or filtering since did not see filtering in place from ZIM<>UK last month... Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jan 16 14:06:15 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 16 Jan 2019 16:06:15 +0200 Subject: ASNs decimation in ZW this morning In-Reply-To: <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> References: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> Message-ID: On 16/Jan/19 15:54, Colin Johnston wrote: > > > I wonder how they block social media sites/whats up, is it null > routing on peering cores or filtering since did not see filtering in > place from ZIM<>UK last month... In Africa, the majority of connectivity happens over mobile networks. So it's easy to "fix" it, since mobile networks have some of the most advanced DPI's in any network. For those not aware, Emmerson Mnangagwa, the Zimbabwean president, increased fuel prices from US$1.24/litre to US$3.11/litre for diesel, and US$1.31/litre to US$3.31/litre for petrol. This is what led to (violent) protests, and as such, networks being asked to shutdown services. Mark. From deleskie at gmail.com Wed Jan 16 14:30:30 2019 From: deleskie at gmail.com (jim deleskie) Date: Wed, 16 Jan 2019 10:30:30 -0400 Subject: Service Provider NetFlow Collectors In-Reply-To: References: Message-ID: Erik, Feel free to ping me, I own Mimir Networks, we have a full-service flow collection/DDoS detection and mitigation system that I'd love to show you. We built it having been a long time user of other commercial and open source tools, for very large deployments. Would be happy to give you a free trial of the system. -jim www.mimirnetworks.com On Sun, Dec 30, 2018 at 11:30 PM Erik Sundberg wrote: > Hi Nanog…. > > > > We are looking at replacing our Netflow collector. I am wonder what other > service providers are using to collect netflow data off their Core and Edge > Routers. Pros/Cons… What to watch out for any info would help. > > > > We are mainly looking to analyze the netflow data. Bonus if it does ddos > detection and mitigation. > > > > We are looking at > > ManageEngine Netflow Analyzer > > PRTG > > Plixer – Scrutinizer > > PeakFlow > > Kentik > > Solarwinds NTA > > > > > > Thanks in advance… > > > > Erik > > > > ------------------------------ > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtk at depaul.edu Wed Jan 16 14:55:29 2019 From: jtk at depaul.edu (John Kristoff) Date: Wed, 16 Jan 2019 08:55:29 -0600 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> Message-ID: <20190116085529.73e2b7c8@p50.localdomain> On Wed, 16 Jan 2019 12:20:39 +0000 Randy Bush wrote: > slide 8 of http://archive.psg.com/970210.nanog.pdf In Randy's presentation there is the suggestion to develop an IX filter list. Nearly 20 years later that actually happened. This wasn't a popular service when I left Team Cymru, but it seems to still be available if anyone wants to consider using that. For more on the historical record, about 10 years after Randy, and from my own experience, this was briefly touched on this in a lightning talk at NANOG 41, "Explorations in the Public Peering Address Space". As part of a project looking at peering discovery, in the Q&A Louie Lee as I recall provided a partial answer to the announcement question raised. It might be worth watching the video for those interesting in this. Scroll to the bottom to see the deck and video here: John From Jacques.Latour at cira.ca Wed Jan 16 15:11:52 2019 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 16 Jan 2019 15:11:52 +0000 Subject: Call for Participation -- ICANN DNSSEC Workshop at ICANN64 Kobe, Japan Message-ID: <34e97b6f4e594605b95b4dfd548729b9@cira.ca> Call for Participation -- ICANN DNSSEC Workshop at ICANN64 Kobe, Japan 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 ICANN64 meeting held from 09-14 March 2019 in Kobe, Japan. 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 Annual General Meeting in Barcelona, Spain, on 24 October 2018. The presentations and transcripts are available at: https://63.schedule.icann.org/meetings/901549, and https://63.schedule.icann.org/meetings/901554, and https://63.schedule.icann.org/meetings/901555. At ICANN64 we are particularly interested in live demonstrations of uses of DNSSEC, DS automation or DANE. Examples might include: * DNSSEC automation and deployment using CDS, CDNSKEY, and CSYNC * DNSSEC/DANE validation in browsers and in applications * Secure email / email encryption using DNSSEC, OPENPGPKEY, or S/MIME * DNSSEC signing solutions and innovation (monitoring, managing, validation) * Tools for automating the generation of DNSSEC/DANE records * Extending DNSSEC/DANE with authentication, SSH, XMPP, SMTP, S/MIME or PGP/GPG and other protocols Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC 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. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. DS Automation We are looking at innovative ways to automate the parent child synchronization CDS / CDNSKEY and methods to bootstrap new or existing domains. We are also interested in development or plans related to CSYNC, which are aimed at keeping the glue up to date. We would like to hear from DNS Operators what their current thoughts on CDS/CDNSKEY automation are. 3. DNSSEC/DANE Support in the browsers We would be interested in hearing from browser develop what their plans are in terms of supporting DNSSEC/DANE validation. 4. DANE Automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-kobe at isoc.org' before ** 07 February 2019 ** We hope that you can join us. Thank you, Jacques Latour On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Wed Jan 16 09:54:42 2019 From: aveline at misaka.io (Siyuan Miao) Date: Wed, 16 Jan 2019 17:54:42 +0800 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: (Perhaps off-topic) KINX are using 192.145.251.0/24 as their Peering IPv4 space. However, I couldn't find any valid SWIP or IRR record created by IP owner Hiawatha Broadband Communications, Inc. Some ISP like Hurricane Electric will route this prefix to KINX but I'm not sure if it's authorized by IP owner. Regards, Siyuan On Wed, Jan 16, 2019 at 5:44 PM Job Snijders wrote: > On Wed, Jan 16, 2019 at 12:39 Christoffer Hansen > wrote: > >> >> On 16/01/2019 08:56, Mark Tinka wrote: >> > Running a few exchange points in Africa since 2002, the news was that >> > the exchange point LAN should not be visible anywhere on the Internet. >> >> Do you use AS0 as origin on the RPKI objects for said exchange point >> LAN(s) to prevent route propagation? > > > > Either AS 0, or the ASN of the IXP’s service network are valid options. > Whatever ASN is listed in the RPKI ROA, should simply never announce the > prefix. > > IXPs should make sure to not set MaxLength to allow anything more-l > specific, it should be equal to the prefix length. > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amreesh.phokeer at gmail.com Wed Jan 16 13:07:31 2019 From: amreesh.phokeer at gmail.com (Amreesh Phokeer) Date: Wed, 16 Jan 2019 17:07:31 +0400 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: On Wed, Jan 16, 2019 at 3:55 PM Job Snijders wrote: > Perhaps that is because for a while you couldn’t set AS 0 in AFRINIC ROAs > as Origin ASN. I think that’s fixed now. > You absolutely can. But not sure if anyone ever created one. -- Amreesh Phokeer -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.waehlisch at fu-berlin.de Wed Jan 16 16:27:48 2019 From: m.waehlisch at fu-berlin.de (Matthias Waehlisch) Date: Wed, 16 Jan 2019 17:27:48 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <6faa44dc-ccf9-75b4-11e3-8b1c9d6dd8ea@netravnen.de> Message-ID: On Wed, 16 Jan 2019, Amreesh Phokeer wrote: > > > On Wed, Jan 16, 2019 at 3:55 PM Job Snijders wrote: > Perhaps that is because for a while you couldn’t set AS 0 in AFRINIC > ROAs as Origin ASN. I think that’s fixed now. > > > You absolutely can. But not sure if anyone ever created one. >   not for AFRINIC, see http://rpki-browser.realmv6.org/ (select AFRINIC, filter for Resource AS0) Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From christoffer at netravnen.de Wed Jan 16 16:39:32 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Wed, 16 Jan 2019 17:39:32 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <20190116085529.73e2b7c8@p50.localdomain> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <20190116085529.73e2b7c8@p50.localdomain> Message-ID: <640546b7-771b-e6f3-dfd9-d4e1ca9fa3d9@netravnen.de> On 16/01/2019 15:55, John Kristoff wrote: > In Randy's presentation there is the suggestion to develop an IX filter > list. Nearly 20 years later that actually happened. > > > > This wasn't a popular service when I left Team Cymru, but it seems to > still be available if anyone wants to consider using that. You could do the same trick. But with data fetched from PeeringDB via the public API. Works well. -Christoffer From jtk at depaul.edu Wed Jan 16 16:46:08 2019 From: jtk at depaul.edu (John Kristoff) Date: Wed, 16 Jan 2019 10:46:08 -0600 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <10ea57a057ef4cb1ad7d17a5f26f2935@XCASPRD02-DFT.dpu.depaul.edu> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <20190116085529.73e2b7c8@p50.localdomain> <10ea57a057ef4cb1ad7d17a5f26f2935@XCASPRD02-DFT.dpu.depaul.edu> Message-ID: <20190116104608.5ca6372f@p50.localdomain> On Wed, 16 Jan 2019 16:39:32 +0000 Christoffer Hansen wrote: > You could do the same trick. But with data fetched from PeeringDB via > the public API. Works well. I think that is essentially what the service does, but in a BGP feed and maintained for you, kind of like the bogons service. John From job at instituut.net Wed Jan 16 16:48:38 2019 From: job at instituut.net (Job Snijders) Date: Wed, 16 Jan 2019 19:48:38 +0300 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <640546b7-771b-e6f3-dfd9-d4e1ca9fa3d9@netravnen.de> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <20190116085529.73e2b7c8@p50.localdomain> <640546b7-771b-e6f3-dfd9-d4e1ca9fa3d9@netravnen.de> Message-ID: On Wed, Jan 16, 2019 at 19:40 Christoffer Hansen wrote: > On 16/01/2019 15:55, John Kristoff wrote: > > In Randy's presentation there is the suggestion to develop an IX filter > > list. Nearly 20 years later that actually happened. > > > > > > > > This wasn't a popular service when I left Team Cymru, but it seems to > > still be available if anyone wants to consider using that. > > You could do the same trick. But with data fetched from PeeringDB via > the public API. Works well. Small note: I strongly recommend to *only* block IXP peering lan prefixes for IXPs you are actually connected to yourself. This way the communication lines are short in case there should be an exception. Don’t block prefixes unrelated to your operation. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Wed Jan 16 16:52:58 2019 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 16 Jan 2019 10:52:58 -0600 Subject: Network Speed Testing and Monitoring Platform Message-ID: As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Wed Jan 16 16:55:51 2019 From: david at xtom.com (David Guo) Date: Wed, 16 Jan 2019 16:55:51 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: We ask our customers use iperf3 to test speed. Get Outlook for iOS ________________________________ From: NANOG on behalf of Colton Conor Sent: Thursday, January 17, 2019 00:54 To: NANOG Subject: Network Speed Testing and Monitoring Platform As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jan 16 16:57:51 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 16 Jan 2019 10:57:51 -0600 (CST) Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <1773806972.7029.1547657866839.JavaMail.mhammett@ThunderFuck> Good luck with that if their only devices are tablets, phones, and Rokus? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "David Guo via NANOG" To: "Colton Conor" , "NANOG" Sent: Wednesday, January 16, 2019 10:55:51 AM Subject: Re: Network Speed Testing and Monitoring Platform We ask our customers use iperf3 to test speed. Get Outlook for iOS From: NANOG on behalf of Colton Conor Sent: Thursday, January 17, 2019 00:54 To: NANOG Subject: Network Speed Testing and Monitoring Platform As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net , or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Jan 16 17:02:23 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 16 Jan 2019 09:02:23 -0800 Subject: dyn internet intelligence In-Reply-To: References: Message-ID: someone offline followed up with me. I am truly impressed how hard they made it to acquire such interesting service (which was easy and awesome under renesys..) On Tue, Jan 15, 2019 at 2:03 PM Mehmet Akcin wrote: > can someone from dyn reach out to me offline? > > https://dyn.com/dyn-internet-intelligence/ > > i have been trying to subscribe and pay for this service and i am getting > sales people ping me and not follow up with price information (which is > weird...) > > thank you > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at nipper.de Wed Jan 16 17:05:22 2019 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 16 Jan 2019 18:05:22 +0100 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <640546b7-771b-e6f3-dfd9-d4e1ca9fa3d9@netravnen.de> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <20190116085529.73e2b7c8@p50.localdomain> <640546b7-771b-e6f3-dfd9-d4e1ca9fa3d9@netravnen.de> Message-ID: <1ec85e2b-8525-1340-79b0-9692d8ec1e0b@nipper.de> On 16.01.2019 17:39, Christoffer Hansen wrote: > On 16/01/2019 15:55, John Kristoff wrote: >> In Randy's presentation there is the suggestion to develop an IX filter >> list. Nearly 20 years later that actually happened. >> >> >> >> This wasn't a popular service when I left Team Cymru, but it seems to >> still be available if anyone wants to consider using that. > > You could do the same trick. But with data fetched from PeeringDB via > the public API. Works well. > There is also a feature request [0] to tag those prefixes whether they should be blocked or not. Once implemented it should be easy to build a filter. Arnold [0] https://github.com/peeringdb/peeringdb/issues/352 -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From christoffer at netravnen.de Wed Jan 16 17:07:15 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Wed, 16 Jan 2019 18:07:15 +0100 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: On 16/01/2019 17:52, Colton Conor wrote: > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? You could optionally run tools such as iperf[123] on the CPE device directly. If you can install it on the CPE, that is. Alternative is the classic of doing a L2 loop with dedicated VLANs on the CPE. E.g. Server1 -> VlanX -> CPE -> VlanY -> Server2 in your own network. -Christoffer From jhellenthal at dataix.net Wed Jan 16 17:32:59 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Wed, 16 Jan 2019 11:32:59 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <20190116173300.1DE9539DA5A9@DataIX.net> Might be worth while to get some graphing on customers max transmission speeds over the period of three days, a week, two weeks, month to better predict what they may be seeing so you can better predict the area’s that could be effected due to whatever causes. A lot of times I find this comes down to name resolution as where to the customer it looks slow but is more likely being drowned out by other traffic or slow responses from the name servers them self that traverse . But those are just common causes. Prioritizing traffic will greatly depend on the information you are seeing and a root cause will greatly evade you just doing speed tests. MRTG, rrdtool and some others can accomplish this for you. Good luck > On Jan 16, 2019, at 10:52, Colton Conor wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? > — J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. From john at essenz.com Wed Jan 16 17:49:23 2019 From: john at essenz.com (John Von Essen) Date: Wed, 16 Jan 2019 12:49:23 -0500 Subject: ASNs decimation in ZW this morning In-Reply-To: References: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> Message-ID: Im confused as to what exactly happened and how it was implemented. I assume the government wanted to restrict access to sites like whatsapp, facebook, twitter, etc.,. So did they tell national ISPs/Mobile (strong-arm) to simply block access to those sites, or they did they tell them to completely shutdown and go dark until the protests were over. Im just curious as to how an ISP/Mobile would selectively block access under government influence, reason being... understanding how can help us think of ways to get around it. For example, lets say the mobile networks null routed all traffic destined to twitter and facebook networks... not a complete IP shutdown. So a local citizen is using email from a local provider (non-gmail, etc.,.) and still has access to email, Twitter knows they are blocked in ZW, but they still try to email updates to this example citizen. If their networks are being null routed, they can simply deliver the email via an alternate network/platform. The whole thing is very disturbing, I mean this is 2019 right? Not 1984... -John On 1/16/19 9:06 AM, Mark Tinka wrote: > > On 16/Jan/19 15:54, Colin Johnston wrote: > >> >> I wonder how they block social media sites/whats up, is it null >> routing on peering cores or filtering since did not see filtering in >> place from ZIM<>UK last month... > In Africa, the majority of connectivity happens over mobile networks. So > it's easy to "fix" it, since mobile networks have some of the most > advanced DPI's in any network. > > For those not aware, Emmerson Mnangagwa, the Zimbabwean president, > increased fuel prices from US$1.24/litre to US$3.11/litre for diesel, > and US$1.31/litre to US$3.31/litre for petrol. This is what led to > (violent) protests, and as such, networks being asked to shutdown services. > > Mark. > > > > From James at arenalgroup.co Wed Jan 16 18:37:46 2019 From: James at arenalgroup.co (James Breeden) Date: Wed, 16 Jan 2019 18:37:46 +0000 Subject: Service Provider NetFlow Collectors In-Reply-To: References: , Message-ID: Jim, please send me additional information on your solution as well, we're in the market for a flow analytics solution. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG on behalf of jim deleskie Sent: Wednesday, January 16, 2019 8:30:30 AM To: Erik Sundberg Cc: nanog at nanog.org Subject: Re: Service Provider NetFlow Collectors Erik, Feel free to ping me, I own Mimir Networks, we have a full-service flow collection/DDoS detection and mitigation system that I'd love to show you. We built it having been a long time user of other commercial and open source tools, for very large deployments. Would be happy to give you a free trial of the system. -jim www.mimirnetworks.com On Sun, Dec 30, 2018 at 11:30 PM Erik Sundberg > wrote: Hi Nanog…. We are looking at replacing our Netflow collector. I am wonder what other service providers are using to collect netflow data off their Core and Edge Routers. Pros/Cons… What to watch out for any info would help. We are mainly looking to analyze the netflow data. Bonus if it does ddos detection and mitigation. We are looking at ManageEngine Netflow Analyzer PRTG Plixer – Scrutinizer PeakFlow Kentik Solarwinds NTA Thanks in advance… Erik ________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Wed Jan 16 19:16:06 2019 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 16 Jan 2019 13:16:06 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Last time I setup Iperf3 it was semi difficult, and would be impossible trying to coach a soccer mom on how to setup over the phone. I am leaning towards a CPE that has speed test built in, or a low cost, sub $100 device we could ship to the customer to install. Anyone know of something like that? On Wed, Jan 16, 2019 at 10:55 AM David Guo wrote: > We ask our customers use iperf3 to test speed. > > Get Outlook for iOS > > ------------------------------ > *From:* NANOG on behalf of Colton Conor < > colton.conor at gmail.com> > *Sent:* Thursday, January 17, 2019 00:54 > *To:* NANOG > *Subject:* Network Speed Testing and Monitoring Platform > > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells > us up-time and if data is flowing across the interface. We can of course > see the link speed, but customer call in saying the are not getting that > speed. > > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CKimball at misalliance.com Wed Jan 16 19:26:41 2019 From: CKimball at misalliance.com (Chris Kimball) Date: Wed, 16 Jan 2019 19:26:41 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Would a raspberry pi work for this? Could 3D print a nice case with your logo for it. From: NANOG On Behalf Of Colton Conor Sent: Wednesday, January 16, 2019 2:16 PM To: David Guo Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform Last time I setup Iperf3 it was semi difficult, and would be impossible trying to coach a soccer mom on how to setup over the phone. I am leaning towards a CPE that has speed test built in, or a low cost, sub $100 device we could ship to the customer to install. Anyone know of something like that? On Wed, Jan 16, 2019 at 10:55 AM David Guo > wrote: We ask our customers use iperf3 to test speed. Get Outlook for iOS ________________________________ From: NANOG > on behalf of Colton Conor > Sent: Thursday, January 17, 2019 00:54 To: NANOG Subject: Network Speed Testing and Monitoring Platform As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crussell at kanren.net Wed Jan 16 19:45:56 2019 From: crussell at kanren.net (Casey Russell) Date: Wed, 16 Jan 2019 13:45:56 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: I don't think a raspberry pi will reliably fill a full Gig and keep it full (maybe that's not required in this scenario), but I've installed a Linux based OS with the PerfSONAR tools (including iperf) on a couple of different mini PCs in the "few hundred dollars" price range. The last one was the Liva X from ECS. It was more than capable of filling 1G circuits with traffic and keeping them full without loss or wonky results due to things like CPU overrun or other processes causing bus contention. I'm pretty sure the Liva X is retired now, but their current gen should suffice as should a number of comparable competitors. Sincerely, Casey Russell Network Engineer [image: KanREN] [image: phone]785-856-9809 2029 Becker Drive, Suite 282 Lawrence, Kansas 66047 [image: linkedin] [image: twitter] [image: twitter] need support? On Wed, Jan 16, 2019 at 1:27 PM Chris Kimball wrote: > Would a raspberry pi work for this? > > > > Could 3D print a nice case with your logo for it. > > > > *From:* NANOG *On Behalf Of *Colton Conor > *Sent:* Wednesday, January 16, 2019 2:16 PM > *To:* David Guo > *Cc:* NANOG > *Subject:* Re: Network Speed Testing and Monitoring Platform > > > > Last time I setup Iperf3 it was semi difficult, and would be impossible > trying to coach a soccer mom on how to setup over the phone. > > > > I am leaning towards a CPE that has speed test built in, or a low cost, > sub $100 device we could ship to the customer to install. Anyone know of > something like that? > > > > On Wed, Jan 16, 2019 at 10:55 AM David Guo wrote: > > We ask our customers use iperf3 to test speed. > > > > Get Outlook for iOS > > > ------------------------------ > > *From:* NANOG on behalf of Colton Conor < > colton.conor at gmail.com> > *Sent:* Thursday, January 17, 2019 00:54 > *To:* NANOG > *Subject:* Network Speed Testing and Monitoring Platform > > > > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. > > > > We have a SNMP and ping monitoring platform today, but that mainly tells > us up-time and if data is flowing across the interface. We can of course > see the link speed, but customer call in saying the are not getting that > speed. > > > > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > > > What opensource and commercial options are out there? > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - > > The information contained in this electronic message may be confidential, > and the message is for the use of intended recipients only. If you are not > the intended recipient, do not disseminate, copy, or disclose this > communication or its contents. If you have received this communication in > error, please immediately notify me by replying to the email or call MIS > Alliance at 617-500-1700 and permanently delete this communication. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at deadfrog.net Wed Jan 16 19:57:32 2019 From: ryan at deadfrog.net (Ryan Wilkins) Date: Wed, 16 Jan 2019 14:57:32 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <14E8A285-3D0A-4720-8153-1F158192579A@deadfrog.net> A Raspberry Pi uses USB 2 for Ethernet interconnection to the CPU so it most definitely will not keep even half a gig full. It’ll do a bit over 300 Mbps. Ryan Wilkins > On Jan 16, 2019, at 2:45 PM, Casey Russell wrote: > > I don't think a raspberry pi will reliably fill a full Gig and keep it full (maybe that's not required in this scenario), but I've installed a Linux based OS with the PerfSONAR tools (including iperf) on a couple of different mini PCs in the "few hundred dollars" price range. > > The last one was the Liva X from ECS. It was more than capable of filling 1G circuits with traffic and keeping them full without loss or wonky results due to things like CPU overrun or other processes causing bus contention. I'm pretty sure the Liva X is retired now, but their current gen should suffice as should a number of comparable competitors. > > Sincerely, > Casey Russell > Network Engineer > > 785-856-9809 > 2029 Becker Drive, Suite 282 > Lawrence, Kansas 66047 > need support? > > > > On Wed, Jan 16, 2019 at 1:27 PM Chris Kimball > wrote: > Would a raspberry pi work for this? > > > > Could 3D print a nice case with your logo for it. > > > > From: NANOG > On Behalf Of Colton Conor > Sent: Wednesday, January 16, 2019 2:16 PM > To: David Guo > > Cc: NANOG > > Subject: Re: Network Speed Testing and Monitoring Platform > > > > Last time I setup Iperf3 it was semi difficult, and would be impossible trying to coach a soccer mom on how to setup over the phone. > > > > I am leaning towards a CPE that has speed test built in, or a low cost, sub $100 device we could ship to the customer to install. Anyone know of something like that? > > > > On Wed, Jan 16, 2019 at 10:55 AM David Guo > wrote: > > We ask our customers use iperf3 to test speed. > > > > Get Outlook for iOS > > > From: NANOG > on behalf of Colton Conor > > Sent: Thursday, January 17, 2019 00:54 > To: NANOG > Subject: Network Speed Testing and Monitoring Platform > > > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net , or worse sending a tech out with a laptop to do the same thing. > > > > What opensource and commercial options are out there? > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccummings at coeur.com Wed Jan 16 20:06:11 2019 From: ccummings at coeur.com (Cummings, Chris) Date: Wed, 16 Jan 2019 20:06:11 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Depending on the Bandwidth needed, yes, but the Pi is limited at the NIC level because it is on a shared USB 2.0 Bus. [cid:image001.jpg at 01D42B24.779DE300] Chris Cummings | Network Engineer Coeur Mining, Inc.| 104 S. Michigan Ave. Suite 900 | Chicago, IL 60603 t: 312.489.5852 | m: 773.294.6496 | ccummings at coeur.com NYSE: CDE | www.coeur.com Notice of Confidentiality: The contents of this e-mail message and any attachments are confidential and are intended solely for addressee. This transmission is sent in trust, for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or phone, and delete this message and its attachments, if any. P Please consider the environment before printing this e-mail. From: NANOG On Behalf Of Chris Kimball Sent: Wednesday, January 16, 2019 11:27 AM To: Colton Conor ; David Guo Cc: NANOG Subject: RE: Network Speed Testing and Monitoring Platform Would a raspberry pi work for this? Could 3D print a nice case with your logo for it. From: NANOG > On Behalf Of Colton Conor Sent: Wednesday, January 16, 2019 2:16 PM To: David Guo > Cc: NANOG > Subject: Re: Network Speed Testing and Monitoring Platform Last time I setup Iperf3 it was semi difficult, and would be impossible trying to coach a soccer mom on how to setup over the phone. I am leaning towards a CPE that has speed test built in, or a low cost, sub $100 device we could ship to the customer to install. Anyone know of something like that? On Wed, Jan 16, 2019 at 10:55 AM David Guo > wrote: We ask our customers use iperf3 to test speed. Get Outlook for iOS ________________________________ From: NANOG > on behalf of Colton Conor > Sent: Thursday, January 17, 2019 00:54 To: NANOG Subject: Network Speed Testing and Monitoring Platform As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Wed Jan 16 20:07:18 2019 From: blake at ispn.net (Blake Hudson) Date: Wed, 16 Jan 2019 14:07:18 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: I investigated building a product that could reliably speedtest up to a gig and found the same thing. A raspberry Pi 3B or 3B+ can reliably test up to ~100Mbps. The 3B only has a 10/100 NIC; The 3B+, while having a gigabit NIC, tops out at ~300Mbps internally. Both models of the Pi are available as a kit that retails under $100. For testing up to 1Gbps, an x86 mini PC like those sold for firewall appliances (http://a.co/d/02UQFow) are available and retail for $200-$300 at the low end. My conclusion was that doing testing within the CPE was the most cost effective way to go. One should keep in mind that even gigabit CPEs may not be able to reliably test > 100Mbps due to CPU or other software limitations. Public speedtest servers may also not reliably test > 100Mbps, so for reliable gigabit testing you'll need to run your own. Casey Russell wrote on 1/16/2019 1:45 PM: > I don't think a raspberry pi will reliably fill a full Gig and keep it > full (maybe that's not required in this scenario), but I've installed > a Linux based OS with the PerfSONAR tools (including iperf) on a > couple of different mini PCs in the "few hundred dollars" price range. > > The last one was the Liva X from ECS.  It was more than capable of > filling 1G circuits with traffic and keeping them full without loss or > wonky results due to things like CPU overrun or other processes > causing bus contention.  I'm pretty sure the Liva X is retired now, > but their current gen should suffice as should a number of comparable > competitors. > > Sincerely, > Casey Russell > Network Engineer > > phone785-856-9809 > 2029 Becker Drive, Suite 282 > Lawrence, Kansas 66047 > linkedin > > twitter twitter > need support? > > > > On Wed, Jan 16, 2019 at 1:27 PM Chris Kimball > > wrote: > > Would a raspberry pi work for this? > > Could 3D print a nice case with your logo for it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Wed Jan 16 20:43:36 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Wed, 16 Jan 2019 20:43:36 -0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org>, Message-ID: <000601d4addc$289598d0$79c0ca70$@netconsultings.com> My understanding was that the tool will combine historic data with the MTBF datapoints form all components involved in a given link in order to try and estimate a likelihood of a link failure. Heck I imagine if one would stream a heap load of data at a ML algorithm it might draw some very interesting conclusions indeed -i.e. draw unforeseen patterns across huge datasets while trying to understand the overall system (network) behaviour. Such a tool might teach us something new about our networks. Next level would be recommendations on how to best address some of the potential pitfalls it found. Maybe in closed systems like IP networks, with use of streaming telemetry from SFPs/NPUs/LC-CPUs/Protocols/etc.., we’ll be able to feed the analytics tool with enough data to allow it to make fairly accurate predictions (i.e. unlike in weather or markets prediction tools where the datasets (or search space -as not all attributes are equally relevant) is virtually endless). adam From: NANOG On Behalf Of Mel Beckman Sent: Tuesday, January 15, 2019 10:40 PM To: Vanbever Laurent Cc: nanog at nanog.org Subject: Re: Your opinion on network analysis in the presence of uncertain events I know of none that take probabilities as inputs. Traditional network simulators, such as GNS3, let you model various failure modes, but probability seems squishy enough that I don’t see how it can be accurate, and thus helpful. It’s like that Dilbert cartoon where the pointy haired boss asks for a schedule of all future unplanned outages :) https://dilbert.com/strip/1997-01-29 -mel On Jan 15, 2019, at 11:59 AM, Vanbever Laurent > wrote: I took the survey. It’s short and sweet — well done! Thanks a lot, Mel! Highly appreciated! I do have a question. You ask "Are there any good?” Any good what? I just meant whether existing network analysis tools were any good (or good enough) at reasoning about probabilistic behaviors that people care about (if any). All the best, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Jan 16 20:47:55 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 16 Jan 2019 15:47:55 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <25453.1547671675@turing-police.cc.vt.edu> On Wed, 16 Jan 2019 19:26:41 +0000, Chris Kimball said: > Would a raspberry pi work for this? > > Could 3D print a nice case with your logo for it. The Pi has a bandwidth limit at 300mbits/sec due to a USB port being used. I wonder if something like the RIPE Atlas probes could be flashed with suitable code. They're smaller than a Pi, and easy to set up - connect a USB power cord and an RJ45 on some cat-5 and away you go. Mine showed up with the two cords needed and everything. https://www-static.ripe.net/static/rnd-ui/atlas/static/docs/probe-images/v1.jpg From randy at psg.com Wed Jan 16 20:55:56 2019 From: randy at psg.com (Randy Bush) Date: Wed, 16 Jan 2019 12:55:56 -0800 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: <20190116085529.73e2b7c8@p50.localdomain> References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> <34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org> <3d1112aa-66ba-ae85-1c68-7dd9e634b4a5@seacom.mu> <20190116085529.73e2b7c8@p50.localdomain> Message-ID: >> slide 8 of http://archive.psg.com/970210.nanog.pdf > In Randy's presentation from the credit where due department: this was not my bright idea. the presentation was from a get together of some large isp operators a few weeks prior. randy From valdis.kletnieks at vt.edu Wed Jan 16 21:01:48 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 16 Jan 2019 16:01:48 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <26379.1547672508@turing-police.cc.vt.edu> On Wed, 16 Jan 2019 10:52:58 -0600, Colton Conor said: > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. So out of curiosity - does anybody have info on what percentage of residential internet connections are on CPE that's been suitably de-bufferbloated? From surfer at mauigateway.com Wed Jan 16 21:05:53 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 16 Jan 2019 13:05:53 -0800 Subject: ASNs decimation in ZW this morning Message-ID: <20190116130553.547FE605@m0117565.ppops.net> --- colinj at gt86car.org.uk wrote: From: Colin Johnston I wonder how they block social media sites/whats up, is it null routing on peering cores or filtering since did not see filtering in place from ZIM<>UK last month... ------------------------------------- Regarding the shutdown: https://allafrica.com/stories/201901160010.html "As it was a written directive issued in terms of the law, non-compliance would result in immediate imprisonment of management on the ground." It's back on. https://www.newzimbabwe.com/internet-back-on-mnangagwa-says-understands-pain-and-frustration/ Side effects: https://www.newzimbabwe.com/by-killing-the-internet-zimbabwe-kills-commerce-and-lights/ Folks are just trying to survive. Fuel is over $13 USD per gallon (out of reach for ordinary folks), prices are crazy high and folks are just trying to survive: https://www.newzimbabwe.com/civilians-beaten-and-abducted-in-major-zimbabwe-crackdown/ But the gov't still has enough for weapons! https://www.newzimbabwe.com/moscow-mnangagwa-says-zimbabwe-to-buy-state-of-the-art-russian-arms/ scott From james.cutler at consultant.com Wed Jan 16 21:09:35 2019 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 16 Jan 2019 16:09:35 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <26379.1547672508@turing-police.cc.vt.edu> References: <26379.1547672508@turing-police.cc.vt.edu> Message-ID: <63479FD7-17DF-4E64-8722-CD3770567405@consultant.com> On Jan 16, 2019, at 4:01 PM, valdis.kletnieks at vt.edu wrote: > > So out of curiosity - does anybody have info on what percentage of residential > internet connections are on CPE that's been suitably de-bufferbloated? I have not read anything suggesting that de-bufferbloating has happened. It would be nice to see something. I participated in bufferbloat testing on Comcast Business Internet some years ago and have never seen any results published. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Wed Jan 16 21:21:23 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 16 Jan 2019 21:21:23 +0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: <000601d4addc$289598d0$79c0ca70$@netconsultings.com> References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org>, , <000601d4addc$289598d0$79c0ca70$@netconsultings.com> Message-ID: <900E9450-E9F3-48C7-B1C5-6FE48CD176AC@beckman.org> MTBF can’t be used alone to predict failure probability, because product mortality follows the infamous “bathtub curve”. Products are as likely to fail early in their lives as later in their lives. MTBF as a scalar value is just an average. -mel via cell On Jan 16, 2019, at 12:43 PM, "adamv0025 at netconsultings.com" > wrote: My understanding was that the tool will combine historic data with the MTBF datapoints form all components involved in a given link in order to try and estimate a likelihood of a link failure. Heck I imagine if one would stream a heap load of data at a ML algorithm it might draw some very interesting conclusions indeed -i.e. draw unforeseen patterns across huge datasets while trying to understand the overall system (network) behaviour. Such a tool might teach us something new about our networks. Next level would be recommendations on how to best address some of the potential pitfalls it found. Maybe in closed systems like IP networks, with use of streaming telemetry from SFPs/NPUs/LC-CPUs/Protocols/etc.., we’ll be able to feed the analytics tool with enough data to allow it to make fairly accurate predictions (i.e. unlike in weather or markets prediction tools where the datasets (or search space -as not all attributes are equally relevant) is virtually endless). adam From: NANOG > On Behalf Of Mel Beckman Sent: Tuesday, January 15, 2019 10:40 PM To: Vanbever Laurent > Cc: nanog at nanog.org Subject: Re: Your opinion on network analysis in the presence of uncertain events I know of none that take probabilities as inputs. Traditional network simulators, such as GNS3, let you model various failure modes, but probability seems squishy enough that I don’t see how it can be accurate, and thus helpful. It’s like that Dilbert cartoon where the pointy haired boss asks for a schedule of all future unplanned outages :) https://dilbert.com/strip/1997-01-29 -mel On Jan 15, 2019, at 11:59 AM, Vanbever Laurent > wrote: I took the survey. It’s short and sweet — well done! Thanks a lot, Mel! Highly appreciated! I do have a question. You ask "Are there any good?” Any good what? I just meant whether existing network analysis tools were any good (or good enough) at reasoning about probabilistic behaviors that people care about (if any). All the best, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Jan 17 00:19:20 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 16 Jan 2019 16:19:20 -0800 Subject: Fiber owners Message-ID: Hello I am trying to get a hold of people who have ownership rights to fiber ( location is not important ) I have few business and technical questions about monitoring, repairs, etc. Thank you Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvanbever at ethz.ch Thu Jan 17 08:06:54 2019 From: lvanbever at ethz.ch (Vanbever Laurent) Date: Thu, 17 Jan 2019 08:06:54 +0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: <000601d4addc$289598d0$79c0ca70$@netconsultings.com> References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org> <000601d4addc$289598d0$79c0ca70$@netconsultings.com> Message-ID: Hi Adam/Mel, Thanks for chiming in! My understanding was that the tool will combine historic data with the MTBF datapoints form all components involved in a given link in order to try and estimate a likelihood of a link failure. Yep. This could be one way indeed. This likelihood could also be taking the form of intervals in which you expect the true value to lies (again, based on historical data). This could be done both for link/devices failures but also for external inputs such as BGP announcements (to consider the likelihood that you receive a route for X in, say, NEWY). The tool would then to run the deterministic routing protocols (not accounting for ‘features’ such as prefer-oldest-route for a sec.) on these probabilistic inputs so as to infer the different possible forwarding outcomes and their relative probabilities. For now we had something like this in mind. One can of course make the model more and more complex by e.g. also taking into account data plane status (to model gray failures). Intuitively though, the more complex the model, the more complex the inference process is. Heck I imagine if one would stream a heap load of data at a ML algorithm it might draw some very interesting conclusions indeed -i.e. draw unforeseen patterns across huge datasets while trying to understand the overall system (network) behaviour. Such a tool might teach us something new about our networks. Next level would be recommendations on how to best address some of the potential pitfalls it found. Yes. I believe some variants of this exist already. I’m not sure how much they are used in practice though. AFAICT, false positives/negatives is still a big problem. Non-trivial recommendation system will require a model of the network behavior that can somehow be inverted easily which is probably something academics should spend some time on :-) Maybe in closed systems like IP networks, with use of streaming telemetry from SFPs/NPUs/LC-CPUs/Protocols/etc.., we’ll be able to feed the analytics tool with enough data to allow it to make fairly accurate predictions (i.e. unlike in weather or markets prediction tools where the datasets (or search space -as not all attributes are equally relevant) is virtually endless). I’m with you. I also believe that better (even programmable) telemetry will unlock powerful analysis tools. Best, Laurent PS: Thanks a lot to those who have already answered our survey! For those who haven’t yet: https://goo.gl/forms/HdYNp3DkKkeEcexs2 (it only takes a couple of minutes). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Thu Jan 17 08:59:30 2019 From: jwbensley at gmail.com (James Bensley) Date: Thu, 17 Jan 2019 08:59:30 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: On Wed, 16 Jan 2019 at 16:54, Colton Conor wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? Hi Colton, In the past I have used CPEs which support remote loopback. When the customer complains we enable remote loopback, send the traffic to that customers connection (rather than requiring a CPE that can generate the traffic or having an on site device) and measuring what comes back. Cheers, James. From mark.tinka at seacom.mu Thu Jan 17 09:07:49 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 17 Jan 2019 11:07:49 +0200 Subject: ASNs decimation in ZW this morning In-Reply-To: References: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> Message-ID: <8b776274-f242-8583-559d-ae86d3bbd20f@seacom.mu> On 16/Jan/19 19:49, John Von Essen wrote: > Im confused as to what exactly happened and how it was implemented. I > assume the government wanted to restrict access to sites like > whatsapp, facebook, twitter, etc.,. So did they tell national > ISPs/Mobile (strong-arm) to simply block access to those sites, or > they did they tell them to completely shutdown and go dark until the > protests were over. Im just curious as to how an ISP/Mobile would > selectively block access under government influence, reason being... > understanding how can help us think of ways to get around it. > > For example, lets say the mobile networks null routed all traffic > destined to twitter and facebook networks... not a complete IP > shutdown. So a local citizen is using email from a local provider > (non-gmail, etc.,.) and still has access to email, Twitter knows they > are blocked in ZW, but they still try to email updates to this example > citizen. If their networks are being null routed, they can simply > deliver the email via an alternate network/platform. > > The whole thing is very disturbing, I mean this is 2019 right? Not > 1984... It's not unusual for networks to be shutdown, particularly during riots and/or elections. I'm not saying it's right or wrong, I'm just saying it's not unusual. This happened during the recent elections in Uganda and Kenya, for example. Typically, the operating licenses issued by the gubbermints to operators provide for legal avenues by the gubbermint to shutdown services. It is not the gubbermint's responsibility as to how this is implemented by the operators, just that it be done. In recent years, social media resources have been targets, so Facebook, WhatsApp, Twitter et al. However, if the gubbermint takes a broader approach, it's up to the operator to figure out how to do it. Failure to comply can result in arrests, fines, jail or even revocation of the license. All mobile operators have terribly advanced DPI infrastructure, so it's not difficult to shut services down at a very granular level. Operators that deliver services via terrestrial means also employ DPI infrastructure, because selling bandwidth access by the Gig-loads is big business :-\. So they, too, can implement shutdowns with a reasonable degree of granularity. Mark. From colinj at gt86car.org.uk Thu Jan 17 09:29:19 2019 From: colinj at gt86car.org.uk (Colin Johnston) Date: Thu, 17 Jan 2019 09:29:19 +0000 Subject: ASNs decimation in ZW this morning In-Reply-To: <8b776274-f242-8583-559d-ae86d3bbd20f@seacom.mu> References: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> <8b776274-f242-8583-559d-ae86d3bbd20f@seacom.mu> Message-ID: > On 17 Jan 2019, at 09:07, Mark Tinka wrote: > > > > On 16/Jan/19 19:49, John Von Essen wrote: > >> Im confused as to what exactly happened and how it was implemented. I >> assume the government wanted to restrict access to sites like >> whatsapp, facebook, twitter, etc.,. So did they tell national >> ISPs/Mobile (strong-arm) to simply block access to those sites, or >> they did they tell them to completely shutdown and go dark until the >> protests were over. Im just curious as to how an ISP/Mobile would >> selectively block access under government influence, reason being... >> understanding how can help us think of ways to get around it. >> >> For example, lets say the mobile networks null routed all traffic >> destined to twitter and facebook networks... not a complete IP >> shutdown. So a local citizen is using email from a local provider >> (non-gmail, etc.,.) and still has access to email, Twitter knows they >> are blocked in ZW, but they still try to email updates to this example >> citizen. If their networks are being null routed, they can simply >> deliver the email via an alternate network/platform. >> >> The whole thing is very disturbing, I mean this is 2019 right? Not >> 1984... > > It's not unusual for networks to be shutdown, particularly during riots > and/or elections. I'm not saying it's right or wrong, I'm just saying > it's not unusual. > > This happened during the recent elections in Uganda and Kenya, for example. > > Typically, the operating licenses issued by the gubbermints to operators > provide for legal avenues by the gubbermint to shutdown services. It is > not the gubbermint's responsibility as to how this is implemented by the > operators, just that it be done. > Would a service be viewed as the same as (layer2 connectivity to a out of country layer3/layer4 endpoint). ie ip source out of country but connectivity layer in country ? satcomms in effect but terrestrial based pvc with leaf router out of country. Colin > In recent years, social media resources have been targets, so Facebook, > WhatsApp, Twitter et al. However, if the gubbermint takes a broader > approach, it's up to the operator to figure out how to do it. Failure to > comply can result in arrests, fines, jail or even revocation of the license. > > All mobile operators have terribly advanced DPI infrastructure, so it's > not difficult to shut services down at a very granular level. > > Operators that deliver services via terrestrial means also employ DPI > infrastructure, because selling bandwidth access by the Gig-loads is big > business :-\. So they, too, can implement shutdowns with a reasonable > degree of granularity. > > Mark. > From mark.tinka at seacom.mu Thu Jan 17 09:47:21 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 17 Jan 2019 11:47:21 +0200 Subject: ASNs decimation in ZW this morning In-Reply-To: References: <456A79C3-251E-48D8-9355-934C3265E195@gt86car.org.uk> <9AEDD375-D4CD-4D31-BEC9-0C0E9A7901B8@gt86car.org.uk> <8b776274-f242-8583-559d-ae86d3bbd20f@seacom.mu> Message-ID: <542c0b15-17a3-b192-0032-4b4a42b5dd16@seacom.mu> On 17/Jan/19 11:29, Colin Johnston wrote: > Would a service be viewed as the same as (layer2 connectivity to a out of country layer3/layer4 endpoint). > ie ip source out of country but connectivity layer in country ? > satcomms in effect but terrestrial based pvc with leaf router out of country. Logically, Layer 2 services would not apply. But this is because gubbermints are clueless about the differences between the various layers. Mark. From jwbensley at gmail.com Thu Jan 17 10:24:34 2019 From: jwbensley at gmail.com (James Bensley) Date: Thu, 17 Jan 2019 10:24:34 +0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> Message-ID: On Tue, 15 Jan 2019 at 19:01, Vanbever Laurent wrote: > > Hi NANOG, > > Networks evolve in uncertain environments. Links and devices randomly fail; external BGP announcements unpredictably appear/disappear leading to unforeseen traffic shifts; traffic demands vary, etc. Reasoning about network behaviors under such uncertainties is hard and yet essential to ensure Service Level Agreements. > > We're reaching out to the NANOG community as we (researchers) are trying to better understand the practical requirements behind "probabilistic" network reasoning. Some of our questions include: Are uncertain behaviors problematic? Do you care about such things at all? Are you already using tools to ensure the compliance of your network design under uncertainty? Are there any good? > > We designed a short anonymous survey to collect operators answers. It is composed of 14 optional questions, most of which (13/14) are closed-ended. It should take less than 10 minutes to complete. We expect the findings to help the research community in designing more powerful network analysis tools. Among others, we intend to present the aggregate results in a scientific article later this year. > > It would be *terrific* if you could help us out! > > Survey URL: https://goo.gl/forms/HdYNp3DkKkeEcexs2 > > Thanks much! > > Laurent Vanbever, ETH Zürich > > > PS: It goes without saying that we would also be extremely grateful if you could forward this email to any operator you know and who may not read NANOG. Hi Laurent, I have filled out the survey however, I would just like to request that in the future you don't use a URL shortner like goo.gl; many people don't like those because we can't see were you're sending us until we click that link. Some people also block them because they are a security issue (our corporate proxy does, I have to drop off the VPN or use a URL expander to retrieve the original URL). Also have you seen Batfish? I looks like you guys want to write a tool that has some overlap with Batfish. Batfish can ingest the configs from my network and answer questions such as "can host A can reach host B?" or "will prefix advertisement P from host A will be filtered/accepted by host B?", "if I ping from this source IP who has a return route and can respond?" etc. Kind regards, James. From liam at fedney.org Thu Jan 17 12:17:59 2019 From: liam at fedney.org (L Sean Kennedy) Date: Thu, 17 Jan 2019 07:17:59 -0500 Subject: Call for Nominees NANOG Program Committee Message-ID: Dear NANOG Community, Nominations are now open for the NANOG Program Committee ! The volunteers on the committee are responsible to develop and select content to program each of the three yearly NANOG conferences and other events. The Program Committee is a highly skilled, dedicated and diverse team of people who strive to improve the NANOG organization and make our industry, as a whole, better. Specific committee member responsibilities are listed here and appointments are to 2 year terms, except when appointed to complete a retiring members term. Committee nominations will close at 9:00 PM ET on Tuesday, February 19, 2019. The NANOG Board of Directors will make appointments on February 20, 2019. Emails detailing the selection results will be sent to candidates shortly thereafter, and a full announcement will be sent to the nanog-announce distribution list during the following week. Volunteer participation by members on NANOG committees is part of the essential fabric of the NANOG organization. PC members have developed new NANOG programs such as the Hackathon, proposed changes such as providing a meeting maker tool and having a forum to discuss the experiences of women in our industry, and meeting after meeting develop unique programs showcasing the state of Network Operations. Please consider running for the Program Committee if you are passionate about NANOG and can commit to participating! If you know someone that you believe would be interested, please nominate them. The nomination form accepts either self or 3rd party nominations. Myself and the other board members are available to discuss this opportunity, so do not hesitate to reach out to us if you are interested and want to learn more. As always, our dedicated professional staff stands ready to answer your questions at operations at nanog.org. Finally, I’d like to extend my best wishes to each of you for a happy and healthy 2019. I look forward to seeing you on February 18 in San Francisco for NANOG 75 . Thanks, L Sean Kennedy (for the NANOG Board of Directors) -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Thu Jan 17 13:17:11 2019 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 17 Jan 2019 07:17:11 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: All, thanks for the recommendations both on and off list. It has been brought to my attention that a Mikrotik has a bandwidth speed test tool built into their operating system. Someone recommended a https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes of the newest version say: !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); *) btest - added multithreading support for both UDP and TCP tests; Do you think this device can push a full 1Gbps connection? It does have a quad core qualcom processor. Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that. Seems like a commercial solution would exist for this. I though CAF providers have to test bandwidth for the FCC randomly to get funding? On Thu, Jan 17, 2019 at 2:59 AM James Bensley wrote: > On Wed, 16 Jan 2019 at 16:54, Colton Conor wrote: > > > > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. > > > > We have a SNMP and ping monitoring platform today, but that mainly tells > us up-time and if data is flowing across the interface. We can of course > see the link speed, but customer call in saying the are not getting that > speed. > > > > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > > > What opensource and commercial options are out there? > > Hi Colton, > > In the past I have used CPEs which support remote loopback. When the > customer complains we enable remote loopback, send the traffic to that > customers connection (rather than requiring a CPE that can generate > the traffic or having an on site device) and measuring what comes > back. > > Cheers, > James. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgrand at tgrand.com Thu Jan 17 14:04:17 2019 From: tgrand at tgrand.com (tgrand) Date: Thu, 17 Jan 2019 08:04:17 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: Message-ID: <5c408b67.1c69fb81.c22e2.e33aSMTPIN_ADDED_MISSING@mx.google.com> Just download the btest.exeIt run on windows PC.Most routerboards not fast enough for TCP test as TCP packet assembly is intensive. Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Colton Conor Date: 2019-01-17 7:17 AM (GMT-06:00) To: James Bensley Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform All, thanks for the recommendations both on and off list. It has been brought to my attention that a Mikrotik has a bandwidth speed test tool built into their operating system. Someone recommended a https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes of the newest version say: !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); *) btest - added multithreading support for both UDP and TCP tests;  Do you think this device can push a full 1Gbps connection? It does have a quad core qualcom processor.  Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that.  Seems like a commercial solution would exist for this.  I though CAF providers have to test bandwidth for the FCC randomly to get funding?  On Thu, Jan 17, 2019 at 2:59 AM James Bensley wrote: On Wed, 16 Jan 2019 at 16:54, Colton Conor wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? Hi Colton, In the past I have used CPEs which support remote loopback. When the customer complains we enable remote loopback, send the traffic to that customers connection (rather than requiring a CPE that can generate the traffic or having an on site device) and measuring what comes back. Cheers, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Thu Jan 17 14:30:10 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Thu, 17 Jan 2019 09:30:10 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <5c408b67.1c69fb81.c22e2.e33aSMTPIN_ADDED_MISSING@mx.google.com> References: <5c408b67.1c69fb81.c22e2.e33aSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: There's a Montreal startup called Obkio who are doing network probes (VM and hardware). I've tested the product in its early phase (i.e. it was lacking features that are now implemented or are going to be implemented soon). They recently launched the speed test feature: https://medium.com/obkio/app-new-release-v1-6-0-public-agents-support-chat-and-speed-tests-c84651f7008a and launched a beefier probe called X5001 which can supposedly do 940Mbps: https://medium.com/obkio/new-hardware-agent-x5001-the-10x-agent-b278e435c458 I think it's worth a look. Disclaimer: the CEO is an acquaintance of mine Eric On Thu, Jan 17, 2019 at 9:04 AM tgrand via NANOG wrote: > Just download the btest.exe > It run on windows PC. > Most routerboards not fast enough for TCP test as TCP packet assembly is > intensive. > > > Sent from my Samsung Galaxy smartphone. > > -------- Original message -------- > From: Colton Conor > Date: 2019-01-17 7:17 AM (GMT-06:00) > To: James Bensley > Cc: NANOG > Subject: Re: Network Speed Testing and Monitoring Platform > > All, thanks for the recommendations both on and off list. > > It has been brought to my attention that a Mikrotik has a bandwidth speed > test tool built into their operating system. Someone recommended a > https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes > of the newest version say: > > !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and > TCP and UDP download, upload speed measurements (CLI only); > *) btest - added multithreading support for both UDP and TCP tests; > > Do you think this device can push a full 1Gbps connection? It does have a > quad core qualcom processor. > > Besides mikrotik, I haven't found anything that doesn't require me to > build a solution. Like OpenWRT with ipef3, or something like that. > > Seems like a commercial solution would exist for this. I though CAF > providers have to test bandwidth for the FCC randomly to get funding? > > On Thu, Jan 17, 2019 at 2:59 AM James Bensley wrote: > >> On Wed, 16 Jan 2019 at 16:54, Colton Conor >> wrote: >> > >> > As an internet service provider with many small business and >> residential customers, our most common tech support calls are speed >> related. Customers complaining on slow speeds, slowdowns, etc. >> > >> > We have a SNMP and ping monitoring platform today, but that mainly >> tells us up-time and if data is flowing across the interface. We can of >> course see the link speed, but customer call in saying the are not getting >> that speed. >> > >> > We are looking for a way to remotely test customers internet >> connections besides telling the customer to go to speedtest.net, or >> worse sending a tech out with a laptop to do the same thing. >> > >> > What opensource and commercial options are out there? >> >> Hi Colton, >> >> In the past I have used CPEs which support remote loopback. When the >> customer complains we enable remote loopback, send the traffic to that >> customers connection (rather than requiring a CPE that can generate >> the traffic or having an on site device) and measuring what comes >> back. >> >> Cheers, >> James. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahebert at pubnix.net Thu Jan 17 14:51:58 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 17 Jan 2019 09:51:58 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <333fdb54-7e35-fea7-fe50-8aaace779828@pubnix.net>     Yeah,     There is not enough capacity, interrupt wise, to achieve it.     OpenSpeedTest works for us. ----- Alain Hebert ahebert at 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 On 1/16/19 2:45 PM, Casey Russell wrote: > I don't think a raspberry pi will reliably fill a full Gig and keep it > full (maybe that's not required in this scenario), but I've installed > a Linux based OS with the PerfSONAR tools (including iperf) on a > couple of different mini PCs in the "few hundred dollars" price range. > > The last one was the Liva X from ECS.  It was more than capable of > filling 1G circuits with traffic and keeping them full without loss or > wonky results due to things like CPU overrun or other processes > causing bus contention.  I'm pretty sure the Liva X is retired now, > but their current gen should suffice as should a number of comparable > competitors. > > Sincerely, > Casey Russell > Network Engineer > KanREN > phone785-856-9809 > 2029 Becker Drive, Suite 282 > Lawrence, Kansas 66047 > linkedin > > twitter twitter > need support? > > > > On Wed, Jan 16, 2019 at 1:27 PM Chris Kimball > > wrote: > > Would a raspberry pi work for this? > > Could 3D print a nice case with your logo for it. > > *From:* NANOG > *On Behalf Of *Colton Conor > *Sent:* Wednesday, January 16, 2019 2:16 PM > *To:* David Guo > > *Cc:* NANOG > > *Subject:* Re: Network Speed Testing and Monitoring Platform > > Last time I setup Iperf3 it was semi difficult, and would be > impossible trying to coach a soccer mom on how to setup over the > phone. > > I am leaning towards a CPE that has speed test built in, or a low > cost, sub $100 device we could ship to the customer to install. > Anyone know of something like that? > > On Wed, Jan 16, 2019 at 10:55 AM David Guo > wrote: > > We ask our customers use iperf3 to test speed. > > Get Outlook for iOS > > ------------------------------------------------------------------------ > > *From:*NANOG > on behalf of Colton Conor > > > *Sent:* Thursday, January 17, 2019 00:54 > *To:* NANOG > *Subject:* Network Speed Testing and Monitoring Platform > > As an internet service provider with many small business and > residential customers, our most common tech support calls are > speed related. Customers complaining on slow speeds, > slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that > mainly tells us up-time and if data is flowing across the > interface. We can of course see the link speed, but customer > call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet > connections besides telling the customer to go to > speedtest.net , or worse sending a tech > out with a laptop to do the same thing. > > What opensource and commercial options are out there? > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - > > The information contained in this electronic message may be > confidential, and the message is for the use of intended > recipients only. If you are not the intended recipient, do not > disseminate, copy, or disclose this communication or its contents. > If you have received this communication in error, please > immediately notify me by replying to the email or call MIS > Alliance at 617-500-1700 and permanently delete this communication. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Jan 17 14:57:35 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 17 Jan 2019 07:57:35 -0700 Subject: ASNs decimation in ZW this morning In-Reply-To: <542c0b15-17a3-b192-0032-4b4a42b5dd16@seacom.mu> Message-ID: <92aacd6740d4a04f9807ad6a1683a8ba@mail.dessus.com> However, like the Internet Off switch installed in the Pentagon after 911 (which shutdown the DNS Severs), you may find that you have to reboot the Internet so you can upload your Save the World video to Twitter ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Tinka >Sent: Thursday, 17 January, 2019 02:47 >To: Colin Johnston >Cc: nanog at nanog.org >Subject: Re: ASNs decimation in ZW this morning > > > >On 17/Jan/19 11:29, Colin Johnston wrote: > >> Would a service be viewed as the same as (layer2 connectivity to a >out of country layer3/layer4 endpoint). >> ie ip source out of country but connectivity layer in country ? >> satcomms in effect but terrestrial based pvc with leaf router out >of country. > >Logically, Layer 2 services would not apply. But this is because >gubbermints are clueless about the differences between the various >layers. > >Mark. From aled.w.morris at googlemail.com Thu Jan 17 15:24:43 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 17 Jan 2019 15:24:43 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <25453.1547671675@turing-police.cc.vt.edu> References: <25453.1547671675@turing-police.cc.vt.edu> Message-ID: On Wed, 16 Jan 2019 at 20:49, wrote: > On Wed, 16 Jan 2019 19:26:41 +0000, Chris Kimball said: > > Would a raspberry pi work for this? > > > > Could 3D print a nice case with your logo for it. > > The Pi has a bandwidth limit at 300mbits/sec due to a USB port being used. > I've been using Hardkernel Odroid C2 for this reason. It looks a bit like a Pi but its Gigabit Ethernet can achieve near line rate, 930+ Mbps on iperf, see below for two Odroids connected across a gigabit ethernet switch. Aled # iperf3 -c 172.16.0.139 Connecting to host 172.16.0.139, port 5201 [ 4] local 172.16.0.142 port 49203 connected to 172.16.0.139 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 110 MBytes 921 Mbits/sec 45 788 KBytes [ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 0 878 KBytes [ 4] 2.00-3.00 sec 112 MBytes 939 Mbits/sec 45 672 KBytes [ 4] 3.00-4.00 sec 112 MBytes 938 Mbits/sec 0 717 KBytes [ 4] 4.00-5.00 sec 112 MBytes 938 Mbits/sec 0 748 KBytes [ 4] 5.00-6.00 sec 112 MBytes 939 Mbits/sec 0 765 KBytes [ 4] 6.00-7.00 sec 112 MBytes 939 Mbits/sec 0 773 KBytes [ 4] 7.00-8.00 sec 112 MBytes 939 Mbits/sec 0 775 KBytes [ 4] 8.00-9.00 sec 112 MBytes 938 Mbits/sec 0 778 KBytes [ 4] 9.00-10.00 sec 112 MBytes 938 Mbits/sec 0 779 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 90 sender [ 4] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver iperf Done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jason_Livingood at comcast.com Thu Jan 17 16:24:18 2019 From: Jason_Livingood at comcast.com (Livingood, Jason) Date: Thu, 17 Jan 2019 16:24:18 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <25453.1547671675@turing-police.cc.vt.edu> References: <25453.1547671675@turing-police.cc.vt.edu> Message-ID: <0773239C-3CAA-4A45-AC67-33AD634A1651@cable.comcast.com> We ran into an issue with RPi and Banana Pi hitting multi-hundred meg and 1 - 2 gig speeds reliably, and ended up using ODROID - https://www.hardkernel.com/. Also, Ookla (speedtest.net) have a software client that can be embedded in CPE gateway devices as does SamKnows. JL On 1/16/19, 3:49 PM, "NANOG on behalf of valdis.kletnieks at vt.edu" wrote: On Wed, 16 Jan 2019 19:26:41 +0000, Chris Kimball said: > Would a raspberry pi work for this? > > Could 3D print a nice case with your logo for it. The Pi has a bandwidth limit at 300mbits/sec due to a USB port being used. I wonder if something like the RIPE Atlas probes could be flashed with suitable code. They're smaller than a Pi, and easy to set up - connect a USB power cord and an RJ45 on some cat-5 and away you go. Mine showed up with the two cords needed and everything. https://www-static.ripe.net/static/rnd-ui/atlas/static/docs/probe-images/v1.jpg From aaron1 at gvtc.com Thu Jan 17 16:27:20 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 17 Jan 2019 10:27:20 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> https://github.com/adolfintel/speedtest - one drawback we’ve seen is upload test has issues on some iphones (maybe other mobile devices) in safari, but I think chrome might work, unsure https://account.speedtestcustom.com/login - ookla customer speedtest – we have this running *internally* in our network on VM and also bare-metal, this is where our customers test locally Iperf - us engineers used it wifiperf – us engineers used it -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboyd at gizmopartners.com Thu Jan 17 16:29:28 2019 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 17 Jan 2019 10:29:28 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: > On Jan 17, 2019, at 7:17 AM, Colton Conor wrote: > > Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that. > > Seems like a commercial solution would exist for this. I though CAF providers have to test bandwidth for the FCC randomly to get funding? Bias note—I know the founders. The product is voice focused, but it does include the capability to run a speed test, and has all the cloud based reporting features that you’d expect today. https://www.replycloud.io —Chris From zpuls at ksfiber.net Wed Jan 16 19:53:30 2019 From: zpuls at ksfiber.net (Zach Puls) Date: Wed, 16 Jan 2019 19:53:30 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Maybe try setting up an Ookla on-site speedtest server? I believe the product is called Speedtest Custom. Setup is pretty simple, and is relatively inexpensive. That gives you the ease-of-use of speedtest.net, with the accuracy similar to having a local iperf server. Zach Puls Network Engineer MEF-CECP [Title: KsFiberNet - Description: Macintosh HD:Users:chunt:Documents:Logos_Brand Guide_KFN:WEB_logos:KFN_logo-WEB.png] Direct: +1 (316) 221-2094 Email: zpuls at ksfiber.net Technical Support: 855-KFN-HELP (536-4357) This e-mail, including any attachments, is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of this information, directly or indirectly, by persons or entities other than the intended recipient is prohibited and may subject you to legal liability. If you received this in error, please contact the sender and delete the material from all computers in which it resides. This email, including any attachments, is not intended to constitute the formation of a contract binding KsFiberNet. KsFiberNet will be contractually bound only upon execution, by an authorized representative, of a definitive agreement containing agreed upon terms and conditions. From: NANOG On Behalf Of Casey Russell Sent: Wednesday, January 16, 2019 13:46 To: Chris Kimball Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform I don't think a raspberry pi will reliably fill a full Gig and keep it full (maybe that's not required in this scenario), but I've installed a Linux based OS with the PerfSONAR tools (including iperf) on a couple of different mini PCs in the "few hundred dollars" price range. The last one was the Liva X from ECS. It was more than capable of filling 1G circuits with traffic and keeping them full without loss or wonky results due to things like CPU overrun or other processes causing bus contention. I'm pretty sure the Liva X is retired now, but their current gen should suffice as should a number of comparable competitors. Sincerely, Casey Russell Network Engineer [KanREN] [phone]785-856-9809 2029 Becker Drive, Suite 282 Lawrence, Kansas 66047 [linkedin][twitter][twitter]need support? On Wed, Jan 16, 2019 at 1:27 PM Chris Kimball > wrote: Would a raspberry pi work for this? Could 3D print a nice case with your logo for it. From: NANOG > On Behalf Of Colton Conor Sent: Wednesday, January 16, 2019 2:16 PM To: David Guo > Cc: NANOG > Subject: Re: Network Speed Testing and Monitoring Platform Last time I setup Iperf3 it was semi difficult, and would be impossible trying to coach a soccer mom on how to setup over the phone. I am leaning towards a CPE that has speed test built in, or a low cost, sub $100 device we could ship to the customer to install. Anyone know of something like that? On Wed, Jan 16, 2019 at 10:55 AM David Guo > wrote: We ask our customers use iperf3 to test speed. Get Outlook for iOS ________________________________ From: NANOG > on behalf of Colton Conor > Sent: Thursday, January 17, 2019 00:54 To: NANOG Subject: Network Speed Testing and Monitoring Platform As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. What opensource and commercial options are out there? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The information contained in this electronic message may be confidential, and the message is for the use of intended recipients only. If you are not the intended recipient, do not disseminate, copy, or disclose this communication or its contents. If you have received this communication in error, please immediately notify me by replying to the email or call MIS Alliance at 617-500-1700 and permanently delete this communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog.org at seidata.com Wed Jan 16 20:00:12 2019 From: nanog.org at seidata.com (R. Scott Evans) Date: Wed, 16 Jan 2019 15:00:12 -0500 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: In the US this type of testing may be an actual requirement for some ISP's if they get funding from the government. https://docs.fcc.gov/public/attachments/DA-18-710A1.pdf We provide basic CPE routers to our DSL & FTTH customers and are trying to get a custom firmware from the device manufacturer (Comtrend) to do these measurements. We're not there yet (the manufacturer has been working with us on it but it's not very accurate yet) but the goal is to have a TR-143 client on the routers themselves that then talks to our test server (although per the FCC rule, we'll eventually have to place the test server at an FCC approved IX). Alternatively, at a trade show I saw a product called a BETTI Box by VantagePoint that is a very small whitebox (maybe a 1" cube w/ eth port) to do this. I only saw the device on a table so have no idea how effective or how much the device is. On 1/16/19 11:52 AM, Colton Conor wrote: > As an internet service provider with many small business and > residential customers, our most common tech support calls are speed > related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly > tells us up-time and if data is flowing across the interface. We can > of course see the link speed, but customer call in saying the are not > getting that speed. > > We are looking for a way to remotely test customers internet > connections besides telling the customer to go to speedtest.net > , or worse sending a tech out with a laptop to > do the same thing. > > What opensource and commercial options are out there? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rapier at psc.edu Wed Jan 16 20:01:14 2019 From: rapier at psc.edu (rapier) Date: Wed, 16 Jan 2019 15:01:14 -0500 Subject: Network Speed Testing and Monitoring Platform Message-ID: <4157ea06-569d-a933-8d14-633848887493@psc.edu> Hello all, A colleague of mine pointed out this conversation to me. I'm not sure this is going to be the best solution to your problem but it may be helpful in some instances or for other people. At PSC we also have to deal with customers complaining of speed issues. Generally speaking this is all on the customer end but diagnosing these issues remotely, especially when people have limited access or skills, is huge time sink. It's compounded by the fact that many times we're trying to work over a number of different operating systems configurations and so forth. In order to cut down on that we created a service called TestRig2.0. In short, it dynamically generates an bootable ISO that automatically runs the host system through a number of network performance tests, packages the results, and send them back the network engineers via scp. The tests are run against the perfSonar infrastructure*. The reason why we use a bootable ISO is because we want to make sure that the tests are being conducted under a known good OS environment. Additionally, we can also limit the number of tests the users can run - either by restricting them to specific time frame (say 7 days) or a total number of runs. After that the ISO will no longer conduct the tests. If anyone is interested please take a look at https://testrig.psc.edu/ for more information. If you are interested in using the service let me know. Setting up an account is pretty easy but I'd like to work with people in the initial process. Thanks, Chris Rapier * Not all commodity users will have access to all of the perfSonar nodes so this is a part where some extra work might be required on the part of the engineer. From rapple at technologieshq.com Thu Jan 17 14:36:40 2019 From: rapple at technologieshq.com (Raleigh Apple) Date: Thu, 17 Jan 2019 09:36:40 -0500 Subject: Coloblox Atlanta down? Message-ID: Is anyone else experiencing issues connecting to equipment hosted at Coloblox in Atlanta? -- Raleigh Apple JP Technologies office: 770/831-1036x105 “A dying culture invariably exhibits personal rudeness. Bad manners. Lack of consideration for others in minor matters. A loss of politeness, of gentle manners, is more significant than is a riot.” --Robert Heinlein -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at errxtx.net Thu Jan 17 17:44:03 2019 From: christian at errxtx.net (Christian Meutes) Date: Thu, 17 Jan 2019 18:44:03 +0100 Subject: Stupid Question maybe? In-Reply-To: References: Message-ID: Hi Aseem, On Wed, Dec 26, 2018 at 6:42 PM Aseem Choudhary wrote: > Hi Christian, > > Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2. > > You can refer below link for details: > > https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620 > > I'am running 5.2.2. and it does definitely not work, only continues bits do work (typhoon-based LCs / 9001). cheers -- Christian e-mail/xmpp: christian at errxtx.net PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Thu Jan 17 19:02:04 2019 From: blake at ispn.net (Blake Hudson) Date: Thu, 17 Jan 2019 13:02:04 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <6f99a173-e269-aae6-395f-305b6fad211e@ispn.net> Zach Puls wrote on 1/16/2019 1:53 PM: > > Maybe try setting up an Ookla on-site speedtest server? I believe the > product is called Speedtest Custom. Setup is pretty simple, and is > relatively inexpensive. > > That gives you the ease-of-use of speedtest.net, with the accuracy > similar to having a local iperf server. > > *Zach Puls* > > /Network Engineer / > > /MEF-CECP/ > > Title: KsFiberNet - Description: Macintosh > HD:Users:chunt:Documents:Logos_Brand > Guide_KFN:WEB_logos:KFN_logo-WEB.png ** > > Direct: +1 (316) 221-2094 > > Email: zpuls at ksfiber.net > > *Technical Support:  855-KFN-HELP (536-4357) * > > /This e-mail, including any attachments, is intended only for the > person or entity to which it is addressed and may contain > confidential, proprietary and/or privileged material. Any review, > retransmission, dissemination or other use of this information, > directly or indirectly, by persons or entities other than the intended > recipient is prohibited and may subject you to legal liability. If you > received this in error, please contact the sender and delete the > material from all computers in which it resides. This email, including > any attachments, is not intended to constitute the formation of a > contract binding KsFiberNet. KsFiberNet will be contractually bound > only upon execution, by an authorized representative, of a definitive > agreement containing agreed upon terms and conditions./ > > Last time I checked, the Ookla Speedtest Custom software license required for a local server installation (e.g. not using the public speedtest servers) started at ~$2k/year. That does not include the speedtest server hardware which may run you another $2k or more if you want to meet the minimum recommended specs for a gigabit speedtest. Perhaps an initial investment of $4k and a reoccurring $2k/year is inexpensive for some, but I can imagine some folks will struggle to find the value at that price point. --Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Thu Jan 17 19:12:28 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 17 Jan 2019 19:12:28 -0000 Subject: Announcing Peering-LAN prefixes to customers In-Reply-To: References: <5c1a56b1.1c69fb81.ace6c.8296SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <005001d4ae98$976c82c0$c6458840$@netconsultings.com> > Job Snijders > Sent: Thursday, December 20, 2018 5:55 PM > We don't see a need for NTT to attempt to make such peering lan networks > reachable for third parties. Such reachability may negatively impact > operations, especially when more-specifics of Peering LAN prefixes are > distributed through the default-free zone. > > As a consequence, for IXPs this policy suggests that it is a necessity to host > their own infrastructure (IXP website, mail server, etc) outside the peering > lan prefix. > Reading this thread makes me wonder if the reasoning mentioned thus far should in fact be extrapolated to any Providers' infrastructure prefixes (essentially the plumbing prefixes). Wondering what is the community's stance on this. adam From john at essenz.com Thu Jan 17 19:45:00 2019 From: john at essenz.com (John Von Essen) Date: Thu, 17 Jan 2019 14:45:00 -0500 Subject: No IPv6 by design to increase reliability... Message-ID: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4? My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...) Thoughts? -John From blake at ispn.net Thu Jan 17 19:52:34 2019 From: blake at ispn.net (Blake Hudson) Date: Thu, 17 Jan 2019 13:52:34 -0600 Subject: No IPv6 by design to increase reliability... In-Reply-To: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> References: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> Message-ID: <0fb7e937-61f3-d5b3-da22-78cdcac771ec@ispn.net> Broken IPv6 connectivity happens all the time, sometimes for weeks, before some folks seem to notice. I could understand why one could take the stance that IPv4 only is less problematic (and therefore more available) than dual stack. Overall, it might depend on your application and the happy eyeballs tech built (or not built) into it. John Von Essen wrote on 1/17/2019 1:45 PM: > I was having a debate with someone on this. Take a critical web site, > say one where you want 100% global uptime, no potential issues with > end users having connectivity or routing issues getting to your IP. > Would it be advantageous to purposely not support a AAAA record in DNS > and disable IPv6, only exist on IPv4? > > My argument against this was "Broken IPv6 Connectivity" doesn't really > occur anymore, also, almost all browsers and OS IP stacks implement > Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 > dies it will try v4. I would also argue that lack of IPv6 technically > makes the site unreachable from native IPv6 clients, and in the event > of an IPv4 outage, connectivity might still remain on IPv6 if the site > had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP > session, but the IPv6 session remained up and transiting traffic...) > > Thoughts? > > > -John > > > From owen at delong.com Thu Jan 17 19:53:16 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jan 2019 11:53:16 -0800 Subject: No IPv6 by design to increase reliability... In-Reply-To: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> References: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> Message-ID: <39BFCD05-62CB-46C7-83E6-0CC25D393137@delong.com> I think you’ve got it basically right. Over time, the number of v6 only clients will continue to grow. (It’s infinitessimally small right now) It should, however, also be noted that there are a larger and growing number of v6 capable clients with increasingly degraded v4 capabilities (v6 only handsets with nat64 or 464xlat, cgn, etc.) which are also negatively impacted by the decision not to support v6 in the scenario described. If v6 were such a problem as described, I think it wouldn’t be so readily embraced by facebook, google, Comcast, Netflix, etc. Owen > On Jan 17, 2019, at 11:45, John Von Essen wrote: > > I was having a debate with someone on this. Take a critical web site, say one where you want 100% global uptime, no potential issues with end users having connectivity or routing issues getting to your IP. Would it be advantageous to purposely not support a AAAA record in DNS and disable IPv6, only exist on IPv4? > > My argument against this was "Broken IPv6 Connectivity" doesn't really occur anymore, also, almost all browsers and OS IP stacks implement Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 dies it will try v4. I would also argue that lack of IPv6 technically makes the site unreachable from native IPv6 clients, and in the event of an IPv4 outage, connectivity might still remain on IPv6 if the site had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, but the IPv6 session remained up and transiting traffic...) > > Thoughts? > > > -John > > From cb.list6 at gmail.com Thu Jan 17 19:59:11 2019 From: cb.list6 at gmail.com (Ca By) Date: Thu, 17 Jan 2019 11:59:11 -0800 Subject: No IPv6 by design to increase reliability... In-Reply-To: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> References: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> Message-ID: On Thu, Jan 17, 2019 at 11:46 AM John Von Essen wrote: > I was having a debate with someone on this. Take a critical web site, > say one where you want 100% global uptime, no potential issues with end > users having connectivity or routing issues getting to your IP. Would it > be advantageous to purposely not support a AAAA record in DNS and > disable IPv6, only exist on IPv4? > No > My argument against this was "Broken IPv6 Connectivity" doesn't really > occur anymore, also, almost all browsers and OS IP stacks implement > Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 > dies it will try v4. I would also argue that lack of IPv6 technically > makes the site unreachable from native IPv6 clients, and in the event of > an IPv4 outage, connectivity might still remain on IPv6 if the site had > an IPv6 address (I've experienced scenarios with a bad IPv4 BGP session, > but the IPv6 session remained up and transiting traffic...) > > Thoughts? > Correct, the broken ipv6 thing is super rare and those rare event are solved with Happy eyeballs. There are well over 100 million ipv6-only Android and iOS devices in north america alone. Failing to deploy ipv6 on the website means they get to share capacity on a CGN, ip repution issues, and indirection to reach the CGN. FB, Google, Netflix, Akamai and other push ipv6 because it is good for business, the business of running money making content. > > -John > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Thu Jan 17 20:40:30 2019 From: johnl at iecc.com (John Levine) Date: 17 Jan 2019 15:40:30 -0500 Subject: No IPv6 by design to increase reliability... In-Reply-To: <39BFCD05-62CB-46C7-83E6-0CC25D393137@delong.com> Message-ID: <20190117204030.D22B1200CDAFCF@ary.qy> In article <39BFCD05-62CB-46C7-83E6-0CC25D393137 at delong.com> you write: >If v6 were such a problem as described, I think it wouldn’t be so readily embraced by facebook, google, Comcast, Netflix, etc. Their priorities are probably not your priorities. For example, I expect they want to be able to distinguish among the devices behind a v4 NAT so they can segment and market more precisely. -- Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From carlosm3011 at gmail.com Thu Jan 17 20:53:11 2019 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Thu, 17 Jan 2019 17:53:11 -0300 Subject: No IPv6 by design to increase reliability... In-Reply-To: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> References: <68a2b818-a25d-39f2-4487-21b19313e7cf@essenz.com> Message-ID: It is an interesting question to ponder. It is true that IPv6 tends to be somewhat more problematic than IPv4, but these days the incidents where IPv6 becomes unavailable or has issues are rare. BTW I have had recently an issue where I had IPv4 reachability problems while IPv6 worked perfectly. regards, -Carlos On 17 Jan 2019, at 16:45, John Von Essen wrote: > I was having a debate with someone on this. Take a critical web site, > say one where you want 100% global uptime, no potential issues with > end users having connectivity or routing issues getting to your IP. > Would it be advantageous to purposely not support a AAAA record in DNS > and disable IPv6, only exist on IPv4? > > My argument against this was "Broken IPv6 Connectivity" doesn't really > occur anymore, also, almost all browsers and OS IP stacks implement > Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 > dies it will try v4. I would also argue that lack of IPv6 technically > makes the site unreachable from native IPv6 clients, and in the event > of an IPv4 outage, connectivity might still remain on IPv6 if the site > had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP > session, but the IPv6 session remained up and transiting traffic...) > > Thoughts? > > > -John From owen at delong.com Thu Jan 17 22:17:46 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Jan 2019 14:17:46 -0800 Subject: No IPv6 by design to increase reliability... In-Reply-To: <20190117204030.D22B1200CDAFCF@ary.qy> References: <20190117204030.D22B1200CDAFCF@ary.qy> Message-ID: <7EADFD28-6800-4572-804F-8BFA06AC414B@delong.com> > On Jan 17, 2019, at 12:40 PM, John Levine wrote: > > In article <39BFCD05-62CB-46C7-83E6-0CC25D393137 at delong.com> you write: >> If v6 were such a problem as described, I think it wouldn’t be so readily embraced by facebook, google, Comcast, Netflix, etc. > > Their priorities are probably not your priorities. For example, I > expect they want to be able to distinguish among the devices behind a > v4 NAT so they can segment and market more precisely. That’s already relatively easy to do through other mechanisms (cookies anyone). Having had in depth conversations with the people running those networks, I can assure you that a number of their priorities are in line with mine: a stable, functional internet that can accommodate existing users and scale for a workable future. That simply isn’t possible in IPv4. It hasn’t been for years. IPv4 continues to degrade. Eventually it will reach a point where the problems are so obvious that they can no longer be ignored by the laggards that still haven’t implemented IPv6. One of several things will eventually resolve that issue: 1. The remaining content providers failing to support IPv6 become sufficiently insignificant that ISPs turning off IPv4 will consider the revenue lost by losing customers that care to be significantly less than the cost to continue supporting IPv4 for those customers. 2. Enough eyeball ISPs will begin charging a premium for IPv4 services to cover the growing cost of maintaining this backwards compatibility that it drives a user revolt against the sites described in the previous paragraph, thus accelerating situation 1 above. 3. A sufficient critical mass of eyeballs are connected to IPv6 only networks that don’t offer IPv4 backwards compatibility that the content providers that fail to support them recognize significant revenue drop. I suspect that the most likely scenario will be 2 accelerating 1, but it could play out in any of the above ways. Bottom line is that anyone still supporting IPv4 only is basically running on a toxic-polluter business model depending on everyone else to cover the growing costs of the mess they are making of the current internet. Owen From Philip.Loenneker at tasmanet.com.au Thu Jan 17 23:07:04 2019 From: Philip.Loenneker at tasmanet.com.au (Philip Loenneker) Date: Thu, 17 Jan 2019 23:07:04 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Connor, If you use the Traffic Generator tool instead of the Bandwidth Test tool built into MikroTik, you can definitely flood a 1Gbps link. However it requires the device to receive the packets that it has sent out, so it’s only viable for links with the same up/down speed. We have been investigating some TR-069 platforms, and several of those offer speed test functionality built in. This means our helpdesk guys can just click a few buttons to trigger it, it only talks to the CPE (nothing on customer LAN), and people don’t need to know how to configure the test other than “click here”. TR-069 also has a lot of other advantages which you can easily discover with a quick search. Regards, Philip Loenneker | Network Engineer | TasmaNet From: NANOG On Behalf Of Colton Conor Sent: Friday, 18 January 2019 12:17 AM To: James Bensley Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform All, thanks for the recommendations both on and off list. It has been brought to my attention that a Mikrotik has a bandwidth speed test tool built into their operating system. Someone recommended a https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes of the newest version say: !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); *) btest - added multithreading support for both UDP and TCP tests; Do you think this device can push a full 1Gbps connection? It does have a quad core qualcom processor. Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that. Seems like a commercial solution would exist for this. I though CAF providers have to test bandwidth for the FCC randomly to get funding? On Thu, Jan 17, 2019 at 2:59 AM James Bensley > wrote: On Wed, 16 Jan 2019 at 16:54, Colton Conor > wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? Hi Colton, In the past I have used CPEs which support remote loopback. When the customer complains we enable remote loopback, send the traffic to that customers connection (rather than requiring a CPE that can generate the traffic or having an on site device) and measuring what comes back. Cheers, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jan 17 23:15:34 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 Jan 2019 17:15:34 -0600 (CST) Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <818081175.8328.1547766934257.JavaMail.mhammett@ThunderFuck> Mikrotik RC has a new speed-test tool. I believe it's an improved BTEst. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Philip Loenneker" To: "NANOG" Sent: Thursday, January 17, 2019 5:07:04 PM Subject: RE: Network Speed Testing and Monitoring Platform Connor, If you use the Traffic Generator tool instead of the Bandwidth Test tool built into MikroTik, you can definitely flood a 1Gbps link. However it requires the device to receive the packets that it has sent out, so it’s only viable for links with the same up/down speed. We have been investigating some TR-069 platforms, and several of those offer speed test functionality built in. This means our helpdesk guys can just click a few buttons to trigger it, it only talks to the CPE (nothing on customer LAN), and people don’t need to know how to configure the test other than “click here”. TR-069 also has a lot of other advantages which you can easily discover with a quick search. Regards, Philip Loenneker | Network Engineer | TasmaNet From: NANOG On Behalf Of Colton Conor Sent: Friday, 18 January 2019 12:17 AM To: James Bensley Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform All, thanks for the recommendations both on and off list. It has been brought to my attention that a Mikrotik has a bandwidth speed test tool built into their operating system. Someone recommended a https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes of the newest version say: !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); *) btest - added multithreading support for both UDP and TCP tests; Do you think this device can push a full 1Gbps connection? It does have a quad core qualcom processor. Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that. Seems like a commercial solution would exist for this. I though CAF providers have to test bandwidth for the FCC randomly to get funding? On Thu, Jan 17, 2019 at 2:59 AM James Bensley < jwbensley at gmail.com > wrote: On Wed, 16 Jan 2019 at 16:54, Colton Conor < colton.conor at gmail.com > wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net , or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? Hi Colton, In the past I have used CPEs which support remote loopback. When the customer complains we enable remote loopback, send the traffic to that customers connection (rather than requiring a CPE that can generate the traffic or having an on site device) and measuring what comes back. Cheers, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasammon at gmail.com Fri Jan 18 04:06:04 2019 From: thomasammon at gmail.com (Tom Ammon) Date: Thu, 17 Jan 2019 23:06:04 -0500 Subject: colocation in Kansas City Message-ID: Does anybody here do business with Tierpoint in Kansas City? Do you recommend them? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Jan 18 11:52:09 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 18 Jan 2019 13:52:09 +0200 Subject: ASNs decimation in ZW this morning In-Reply-To: <92aacd6740d4a04f9807ad6a1683a8ba@mail.dessus.com> References: <92aacd6740d4a04f9807ad6a1683a8ba@mail.dessus.com> Message-ID: <5d36c264-222e-b94d-c223-a61ed92a71b7@seacom.mu> On 17/Jan/19 16:57, Keith Medcalf wrote: > However, like the Internet Off switch installed in the Pentagon after 911 (which shutdown the DNS Severs), you may find that you have to reboot the Internet so you can upload your Save the World video to Twitter ... https://www.youtube.com/watch?v=RYHci_KYIT4 Mark. From colinj at gt86car.org.uk Fri Jan 18 12:24:49 2019 From: colinj at gt86car.org.uk (Colin Johnston) Date: Fri, 18 Jan 2019 12:24:49 +0000 Subject: ASNs decimation in ZW this morning In-Reply-To: <5d36c264-222e-b94d-c223-a61ed92a71b7@seacom.mu> References: <92aacd6740d4a04f9807ad6a1683a8ba@mail.dessus.com> <5d36c264-222e-b94d-c223-a61ed92a71b7@seacom.mu> Message-ID: <43041436-E4BC-4319-9FA2-683D34A6CEAE@gt86car.org.uk> > On 18 Jan 2019, at 11:52, Mark Tinka wrote: > > > > On 17/Jan/19 16:57, Keith Medcalf wrote: > >> However, like the Internet Off switch installed in the Pentagon after 911 (which shutdown the DNS Severs), you may find that you have to reboot the Internet so you can upload your Save the World video to Twitter ... > > https://www.youtube.com/watch?v=RYHci_KYIT4 > > Mark. someone needs to tell Zim Gov that BACS-IP payroll needs IP connectivity to banks to pay gov employees otherwise.... Col From adamv0025 at netconsultings.com Fri Jan 18 13:30:55 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 18 Jan 2019 13:30:55 -0000 Subject: Your opinion on network analysis in the presence of uncertain events In-Reply-To: <004f01d4ae98$970b9e10$c522da30$@netconsultings.com> References: <6C701F01-E70D-4D37-B357-F9B142736BE9@ethz.ch> <27CD50DC-798E-43F4-A973-E9EA45BD8916@beckman.org>, , <000601d4addc$289598d0$79c0ca70$@netconsultings.com> <900E9450-E9F3-48C7-B1C5-6FE48CD176AC@beckman.org> <004f01d4ae98$970b9e10$c522da30$@netconsultings.com> Message-ID: <00a401d4af32$0ac7d140$205773c0$@netconsultings.com> > From: Mel Beckman > Sent: Wednesday, January 16, 2019 9:21 PM > > MTBF can’t be used alone to predict failure probability, because product > mortality follows the infamous “bathtub curve”. Products are as likely to fail > early in their lives as later in their lives. MTBF as a scalar value is just an > average. > Yes very good point -however that's where the historical data should come to rescue to help bend the MTBF line into this expected "bathtub curve". adam From colton.conor at gmail.com Fri Jan 18 14:31:58 2019 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 18 Jan 2019 08:31:58 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <818081175.8328.1547766934257.JavaMail.mhammett@ThunderFuck> References: <818081175.8328.1547766934257.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, So are you saying in Mikrotik, there is a Btest tool, a traffic generator tool, and a new speed-test tool? Sounds like this low cost CPE has a ton of options for remote speed test functionality? On Thu, Jan 17, 2019 at 5:16 PM Mike Hammett wrote: > Mikrotik RC has a new speed-test tool. I believe it's an improved BTEst. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Philip Loenneker" > *To: *"NANOG" > *Sent: *Thursday, January 17, 2019 5:07:04 PM > *Subject: *RE: Network Speed Testing and Monitoring Platform > > Connor, > > > > If you use the Traffic Generator tool instead of the Bandwidth Test tool > built into MikroTik, you can definitely flood a 1Gbps link. However it > requires the device to receive the packets that it has sent out, so it’s > only viable for links with the same up/down speed. > > > > We have been investigating some TR-069 platforms, and several of those > offer speed test functionality built in. This means our helpdesk guys can > just click a few buttons to trigger it, it only talks to the CPE (nothing > on customer LAN), and people don’t need to know how to configure the test > other than “click here”. TR-069 also has a lot of other advantages which > you can easily discover with a quick search. > > > > Regards, > > Philip Loenneker | Network Engineer | TasmaNet > > > > *From:* NANOG *On Behalf Of *Colton Conor > *Sent:* Friday, 18 January 2019 12:17 AM > *To:* James Bensley > *Cc:* NANOG > *Subject:* Re: Network Speed Testing and Monitoring Platform > > > > All, thanks for the recommendations both on and off list. > > > > It has been brought to my attention that a Mikrotik has a bandwidth speed > test tool built into their operating system. Someone recommended a > https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes > of the newest version say: > > > > !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and > TCP and UDP download, upload speed measurements (CLI only); > *) btest - added multithreading support for both UDP and TCP tests; > > > > Do you think this device can push a full 1Gbps connection? It does have a > quad core qualcom processor. > > > > Besides mikrotik, I haven't found anything that doesn't require me to > build a solution. Like OpenWRT with ipef3, or something like that. > > > > Seems like a commercial solution would exist for this. I though CAF > providers have to test bandwidth for the FCC randomly to get funding? > > > > On Thu, Jan 17, 2019 at 2:59 AM James Bensley wrote: > > On Wed, 16 Jan 2019 at 16:54, Colton Conor wrote: > > > > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. > > > > We have a SNMP and ping monitoring platform today, but that mainly tells > us up-time and if data is flowing across the interface. We can of course > see the link speed, but customer call in saying the are not getting that > speed. > > > > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > > > What opensource and commercial options are out there? > > Hi Colton, > > In the past I have used CPEs which support remote loopback. When the > customer complains we enable remote loopback, send the traffic to that > customers connection (rather than requiring a CPE that can generate > the traffic or having an on site device) and measuring what comes > back. > > Cheers, > James. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Fri Jan 18 14:33:50 2019 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 18 Jan 2019 08:33:50 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Philip, Which TR-069 tools are you referring to? I looked at TR-143, but its my understanding it downloads a small file (like 50MB) from the TR-069 server to the CPE's ram. Then uploads the file back. Unfortunately I couldn't see how this would reliability test 1Gbps connections. Can you increase the file size? Most of these modems have like 128MB ram right now? On Thu, Jan 17, 2019 at 5:07 PM Philip Loenneker < Philip.Loenneker at tasmanet.com.au> wrote: > Connor, > > > > If you use the Traffic Generator tool instead of the Bandwidth Test tool > built into MikroTik, you can definitely flood a 1Gbps link. However it > requires the device to receive the packets that it has sent out, so it’s > only viable for links with the same up/down speed. > > > > We have been investigating some TR-069 platforms, and several of those > offer speed test functionality built in. This means our helpdesk guys can > just click a few buttons to trigger it, it only talks to the CPE (nothing > on customer LAN), and people don’t need to know how to configure the test > other than “click here”. TR-069 also has a lot of other advantages which > you can easily discover with a quick search. > > > > Regards, > > Philip Loenneker | Network Engineer | TasmaNet > > > > *From:* NANOG *On Behalf Of *Colton Conor > *Sent:* Friday, 18 January 2019 12:17 AM > *To:* James Bensley > *Cc:* NANOG > *Subject:* Re: Network Speed Testing and Monitoring Platform > > > > All, thanks for the recommendations both on and off list. > > > > It has been brought to my attention that a Mikrotik has a bandwidth speed > test tool built into their operating system. Someone recommended a > https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes > of the newest version say: > > > > !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and > TCP and UDP download, upload speed measurements (CLI only); > *) btest - added multithreading support for both UDP and TCP tests; > > > > Do you think this device can push a full 1Gbps connection? It does have a > quad core qualcom processor. > > > > Besides mikrotik, I haven't found anything that doesn't require me to > build a solution. Like OpenWRT with ipef3, or something like that. > > > > Seems like a commercial solution would exist for this. I though CAF > providers have to test bandwidth for the FCC randomly to get funding? > > > > On Thu, Jan 17, 2019 at 2:59 AM James Bensley wrote: > > On Wed, 16 Jan 2019 at 16:54, Colton Conor wrote: > > > > As an internet service provider with many small business and residential > customers, our most common tech support calls are speed related. Customers > complaining on slow speeds, slowdowns, etc. > > > > We have a SNMP and ping monitoring platform today, but that mainly tells > us up-time and if data is flowing across the interface. We can of course > see the link speed, but customer call in saying the are not getting that > speed. > > > > We are looking for a way to remotely test customers internet connections > besides telling the customer to go to speedtest.net, or worse sending a > tech out with a laptop to do the same thing. > > > > What opensource and commercial options are out there? > > Hi Colton, > > In the past I have used CPEs which support remote loopback. When the > customer complains we enable remote loopback, send the traffic to that > customers connection (rather than requiring a CPE that can generate > the traffic or having an on site device) and measuring what comes > back. > > Cheers, > James. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Fri Jan 18 14:37:26 2019 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 18 Jan 2019 08:37:26 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> References: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> Message-ID: Aaron, How does the https://account.speedtestcustom.com/login differ from hosting a speedtest.net server as an ISP, and letting anyone test through it? Seems the speedtest custom is a paid option, but hosting a speedtest.net server is free if you allow it to the public domain. Sure it uses up bandwidth (which I am sure you have a ton of), so I don't see the point of having a custom one? On Thu, Jan 17, 2019 at 10:27 AM Aaron Gould wrote: > https://github.com/adolfintel/speedtest - one drawback we’ve seen is > upload test has issues on some iphones (maybe other mobile devices) in > safari, but I think chrome might work, unsure > > > > https://account.speedtestcustom.com/login - ookla customer speedtest – we > have this running **internally** in our network on VM and also > bare-metal, this is where our customers test locally > > > > Iperf - us engineers used it > > wifiperf – us engineers used it > > > > -Aaron > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Jan 18 15:07:56 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 18 Jan 2019 09:07:56 -0600 (CST) Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: <818081175.8328.1547766934257.JavaMail.mhammett@ThunderFuck> Message-ID: <1977659067.8637.1547824076328.JavaMail.mhammett@ThunderFuck> What's new in 6.44beta39 (2018-Nov-27 12:14): !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); https://wiki.mikrotik.com/wiki/Manual:Tools/Speed_Test https://wiki.mikrotik.com/wiki/Manual:Tools/Traffic_Generator https://wiki.mikrotik.com/wiki/Manual:Tools/Bandwidth_Test ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Colton Conor" To: "Mike Hammett" Cc: "Philip Loenneker" , "NANOG" Sent: Friday, January 18, 2019 8:31:58 AM Subject: Re: Network Speed Testing and Monitoring Platform Mike, So are you saying in Mikrotik, there is a Btest tool, a traffic generator tool, and a new speed-test tool? Sounds like this low cost CPE has a ton of options for remote speed test functionality? On Thu, Jan 17, 2019 at 5:16 PM Mike Hammett < nanog at ics-il.net > wrote: Mikrotik RC has a new speed-test tool. I believe it's an improved BTEst. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Philip Loenneker" < Philip.Loenneker at tasmanet.com.au > To: "NANOG" < nanog at nanog.org > Sent: Thursday, January 17, 2019 5:07:04 PM Subject: RE: Network Speed Testing and Monitoring Platform Connor, If you use the Traffic Generator tool instead of the Bandwidth Test tool built into MikroTik, you can definitely flood a 1Gbps link. However it requires the device to receive the packets that it has sent out, so it’s only viable for links with the same up/down speed. We have been investigating some TR-069 platforms, and several of those offer speed test functionality built in. This means our helpdesk guys can just click a few buttons to trigger it, it only talks to the CPE (nothing on customer LAN), and people don’t need to know how to configure the test other than “click here”. TR-069 also has a lot of other advantages which you can easily discover with a quick search. Regards, Philip Loenneker | Network Engineer | TasmaNet From: NANOG < nanog-bounces at nanog.org > On Behalf Of Colton Conor Sent: Friday, 18 January 2019 12:17 AM To: James Bensley < jwbensley at gmail.com > Cc: NANOG < nanog at nanog.org > Subject: Re: Network Speed Testing and Monitoring Platform All, thanks for the recommendations both on and off list. It has been brought to my attention that a Mikrotik has a bandwidth speed test tool built into their operating system. Someone recommended a https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes of the newest version say: !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); *) btest - added multithreading support for both UDP and TCP tests; Do you think this device can push a full 1Gbps connection? It does have a quad core qualcom processor. Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that. Seems like a commercial solution would exist for this. I though CAF providers have to test bandwidth for the FCC randomly to get funding? On Thu, Jan 17, 2019 at 2:59 AM James Bensley < jwbensley at gmail.com > wrote:
On Wed, 16 Jan 2019 at 16:54, Colton Conor < colton.conor at gmail.com > wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net , or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? Hi Colton, In the past I have used CPEs which support remote loopback. When the customer complains we enable remote loopback, send the traffic to that customers connection (rather than requiring a CPE that can generate the traffic or having an on site device) and measuring what comes back. Cheers, James.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at impulse.net Thu Jan 17 19:35:23 2019 From: victor at impulse.net (Victor Breen) Date: Thu, 17 Jan 2019 19:35:23 +0000 Subject: AT&T starting to charge for RFOs on ASE tail circuits? Message-ID: Hey All, I just caught wind from multiple support reps of ours that AT&T is now demanding payment to get an RFO. As in, our folks are calling up AT&T to see why a particular tail circuit was down for whatever period of time and has since come back up with no clear utility power issue or backhoe fade to explain it. The response they get is that an RFO is billable and they have been asked to accept the charge to proceed (which they have rightly rejected thus far). This is the first time I've heard of this happening with any of our last-mile transport providers. I'm very curious, has anyone else experienced this lately with AT&T or any other carriers? -- Victor Breen | victor at impulse.net Sr. Engineer | Impulse Advanced Communications www.impulse.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Fri Jan 18 15:44:22 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 18 Jan 2019 15:44:22 -0000 Subject: Anyone using AT&T's ECOMP/ONAP? In-Reply-To: References: <00c101d488b4$0906fa10$1b14ee30$@netconsultings.com> Message-ID: <00b601d4af44$af5cd2c0$0e167840$@netconsultings.com> > From: John Kinsella > Sent: Friday, November 30, 2018 5:49 PM > > A few of us at my startup worked with onap for a few months last year as > part of a container security project for a large telco. It was a bit of a PIA to get > going. Att open sourced it in name - an enterprise sw project that was built > by a large team over several years with lots of people coming and going. So > I’d say don’t expect an easy go if it. > > Onap was a popular topic at kubecon last year - lots of telcos medium and > large looking at it, so due to popularity maybe the community support has > improved in the last year. > Hi folks, So trying to resurrect this thread, All in all I received 4 responses, that in itself sort of suggests how popular the ONAP platform is among operators. Now I'd like to ask a slightly different question in light of the most helpful response above from John. And that is whether you know of any integrator that offers maintenance and development and help getting ONAP (or a fork of it) into production environments? Maybe one of those that contribute most to the code. I'm hoping for the similar ecosystem that grew around ODL where one can get exactly that. Call me romantic but I really fell for the model driven everything approach for running a telco. And unfortunately all the commercial products we reviewed thus far are basically just nice extensions of ansible (nice ways of pushing the config to network). But in real world I can't just stitch VRF+BGP+QOS config together and call it service1, push it into the network and hope for the best... In reality I'd need to functionality, scale and interworking test each of the building blocks and the whole solution to certify the service1 for production, only then I can push it on to the network, but then again I need to verify whether the service is ready for customers and I need to maintain throughout its lifecycle as well. Some of the products we reviewed provide only a basic framework with very little out of the box while others offer ready-made solution -but only to parts of the whole Design->Certify->Deploy->Verify->Monitor process. If you know of any commercial solution that addresses the whole network service lifecycle, then I'd be really thankful for any pointers. Thanks adam From erich at gotfusion.net Fri Jan 18 16:17:39 2019 From: erich at gotfusion.net (Kaiser, Erich) Date: Fri, 18 Jan 2019 10:17:39 -0600 Subject: AT&T starting to charge for RFOs on ASE tail circuits? In-Reply-To: References: Message-ID: Yes we have seen that response in the past on RFOs. Most of these random outages are maintenance for moving fiber due to construction and they do not tell you when it is going to happen, we have been complaining about this for the past year to them. Every other carrier issues a maintenance notification (most of the time), for some reason they do not feel it is necessary and blame the ASE product. We are now a gold status customers so the support has gotten better. We are 2 months into it so we will see long term how it will work out. Dealing with them has been frustrating for sure... Erich Kaiser The Fusion Network On Fri, Jan 18, 2019 at 9:19 AM Victor Breen wrote: > Hey All, > > > I just caught wind from multiple support reps of ours that AT&T is > now demanding payment to get an RFO. As in, our folks are calling up AT&T > to see why a particular tail circuit was down for whatever period of time > and has since come back up with no clear utility power issue or backhoe > fade to explain it. The response they get is that an RFO is billable and > they have been asked to accept the charge to proceed (which they > have rightly rejected thus far). This is the first time I've heard of this > happening with any of our last-mile transport providers. > > > I'm very curious, has anyone else experienced this lately with AT&T or any > other carriers? > > > -- > Victor Breen | victor at impulse.net > Sr. Engineer | Impulse Advanced Communications > www.impulse.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From James at arenalgroup.co Fri Jan 18 16:52:38 2019 From: James at arenalgroup.co (James Breeden) Date: Fri, 18 Jan 2019 16:52:38 +0000 Subject: colocation in Kansas City In-Reply-To: References: Message-ID: I've done business with Tierpoint before but not in KC. Good facilities, kinda middle of the road support - they take care of you though. Fairly easy to work with. I remember security being kinda lax, you signed in on a kiosk but it didnt really integrate with the doors and you just kinda picked up a general visitor access card to go in at the time.. hopefully that's changed by now. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co ________________________________ From: NANOG on behalf of Tom Ammon Sent: Thursday, January 17, 2019 10:06:04 PM To: NANOG Subject: colocation in Kansas City Does anybody here do business with Tierpoint in Kansas City? Do you recommend them? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricpatara at gmail.com Fri Jan 18 17:05:39 2019 From: ricpatara at gmail.com (Ricardo Patara) Date: Fri, 18 Jan 2019 15:05:39 -0200 Subject: contact from AS3 Message-ID: <0c3c05b0-dc05-d3f4-3b6d-2434f956d914@gmail.com> Hello, I need to contact someone form AS3. If in the list, could you please contact me privately. It seems this ASN is announcing IP blocks from other organization. Thanks Ricardo Patara From stillwaxin at gmail.com Fri Jan 18 17:10:45 2019 From: stillwaxin at gmail.com (Michael Still) Date: Fri, 18 Jan 2019 12:10:45 -0500 Subject: contact from AS3 In-Reply-To: <0c3c05b0-dc05-d3f4-3b6d-2434f956d914@gmail.com> References: <0c3c05b0-dc05-d3f4-3b6d-2434f956d914@gmail.com> Message-ID: This is likely just a poor effort at prepending. What is the next ASN in the path? They are likely the culprit. On Fri, Jan 18, 2019 at 12:06 PM Ricardo Patara wrote: > Hello, > > I need to contact someone form AS3. If in the list, could you please > contact me privately. > > It seems this ASN is announcing IP blocks from other organization. > > Thanks > Ricardo Patara > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Jan 18 17:17:59 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 18 Jan 2019 11:17:59 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> Message-ID: <002101d4af51$c355f830$4a01e890$@gvtc.com> I think the motivation for the paid/onsite version of ookla was so that we could say how good our customers speed is, without going through the internet. We can’t control utilization on the Internet, but we can internally. -Aaron From: Colton Conor [mailto:colton.conor at gmail.com] Sent: Friday, January 18, 2019 8:37 AM To: Aaron Gould Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform Aaron, How does the https://account.speedtestcustom.com/login differ from hosting a speedtest.net server as an ISP, and letting anyone test through it? Seems the speedtest custom is a paid option, but hosting a speedtest.net server is free if you allow it to the public domain. Sure it uses up bandwidth (which I am sure you have a ton of), so I don't see the point of having a custom one? On Thu, Jan 17, 2019 at 10:27 AM Aaron Gould wrote: https://github.com/adolfintel/speedtest - one drawback we’ve seen is upload test has issues on some iphones (maybe other mobile devices) in safari, but I think chrome might work, unsure https://account.speedtestcustom.com/login - ookla customer speedtest – we have this running *internally* in our network on VM and also bare-metal, this is where our customers test locally Iperf - us engineers used it wifiperf – us engineers used it -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Fri Jan 18 17:22:21 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 18 Jan 2019 17:22:21 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <002101d4af51$c355f830$4a01e890$@gvtc.com> References: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> <002101d4af51$c355f830$4a01e890$@gvtc.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FC61264@RTC-EXCH01.RESERVE.LDS> The paid version gives you access to all the reporting from the test ran against your server. Luke Ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Friday, January 18, 2019 11:18 AM To: 'Colton Conor' Cc: 'NANOG' Subject: RE: Network Speed Testing and Monitoring Platform I think the motivation for the paid/onsite version of ookla was so that we could say how good our customers speed is, without going through the internet. We can’t control utilization on the Internet, but we can internally. -Aaron From: Colton Conor [mailto:colton.conor at gmail.com] Sent: Friday, January 18, 2019 8:37 AM To: Aaron Gould Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform Aaron, How does the https://account.speedtestcustom.com/login differ from hosting a speedtest.net server as an ISP, and letting anyone test through it? Seems the speedtest custom is a paid option, but hosting a speedtest.net server is free if you allow it to the public domain. Sure it uses up bandwidth (which I am sure you have a ton of), so I don't see the point of having a custom one? On Thu, Jan 17, 2019 at 10:27 AM Aaron Gould > wrote: https://github.com/adolfintel/speedtest - one drawback we’ve seen is upload test has issues on some iphones (maybe other mobile devices) in safari, but I think chrome might work, unsure https://account.speedtestcustom.com/login - ookla customer speedtest – we have this running *internally* in our network on VM and also bare-metal, this is where our customers test locally Iperf - us engineers used it wifiperf – us engineers used it -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at impulse.net Fri Jan 18 17:27:35 2019 From: victor at impulse.net (Victor Breen) Date: Fri, 18 Jan 2019 17:27:35 +0000 Subject: AT&T starting to charge for RFOs on ASE tail circuits? In-Reply-To: References: , Message-ID: Well, I guess it's nice to know we're not the only ones getting that treatment. I'll have to see about this "gold status" you speak of. -- Victor Breen | victor at impulse.net Sr. Engineer | Impulse Advanced Communications main 805.456.5800 | www.impulse.net ________________________________ From: Kaiser, Erich Sent: Friday, January 18, 2019 8:17:39 AM To: Victor Breen Cc: nanog at nanog.org Subject: Re: AT&T starting to charge for RFOs on ASE tail circuits? Yes we have seen that response in the past on RFOs. Most of these random outages are maintenance for moving fiber due to construction and they do not tell you when it is going to happen, we have been complaining about this for the past year to them. Every other carrier issues a maintenance notification (most of the time), for some reason they do not feel it is necessary and blame the ASE product. We are now a gold status customers so the support has gotten better. We are 2 months into it so we will see long term how it will work out. Dealing with them has been frustrating for sure... Erich Kaiser The Fusion Network On Fri, Jan 18, 2019 at 9:19 AM Victor Breen > wrote: Hey All, I just caught wind from multiple support reps of ours that AT&T is now demanding payment to get an RFO. As in, our folks are calling up AT&T to see why a particular tail circuit was down for whatever period of time and has since come back up with no clear utility power issue or backhoe fade to explain it. The response they get is that an RFO is billable and they have been asked to accept the charge to proceed (which they have rightly rejected thus far). This is the first time I've heard of this happening with any of our last-mile transport providers. I'm very curious, has anyone else experienced this lately with AT&T or any other carriers? -- Victor Breen | victor at impulse.net Sr. Engineer | Impulse Advanced Communications www.impulse.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Fri Jan 18 17:29:56 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 18 Jan 2019 17:29:56 +0000 Subject: AT&T starting to charge for RFOs on ASE tail circuits? In-Reply-To: References: , , Message-ID: <54B4AA65-1C77-43C5-BB96-B69106E950F2@beckman.org> I wonder how this fits in with AT&T’s SLA commitments? How can you audit your SLA without the RFOs? -mel beckman On Jan 18, 2019, at 9:28 AM, Victor Breen > wrote: Well, I guess it's nice to know we're not the only ones getting that treatment. I'll have to see about this "gold status" you speak of. -- Victor Breen | victor at impulse.net Sr. Engineer | Impulse Advanced Communications main 805.456.5800 | www.impulse.net ________________________________ From: Kaiser, Erich > Sent: Friday, January 18, 2019 8:17:39 AM To: Victor Breen Cc: nanog at nanog.org Subject: Re: AT&T starting to charge for RFOs on ASE tail circuits? Yes we have seen that response in the past on RFOs. Most of these random outages are maintenance for moving fiber due to construction and they do not tell you when it is going to happen, we have been complaining about this for the past year to them. Every other carrier issues a maintenance notification (most of the time), for some reason they do not feel it is necessary and blame the ASE product. We are now a gold status customers so the support has gotten better. We are 2 months into it so we will see long term how it will work out. Dealing with them has been frustrating for sure... Erich Kaiser The Fusion Network On Fri, Jan 18, 2019 at 9:19 AM Victor Breen > wrote: Hey All, I just caught wind from multiple support reps of ours that AT&T is now demanding payment to get an RFO. As in, our folks are calling up AT&T to see why a particular tail circuit was down for whatever period of time and has since come back up with no clear utility power issue or backhoe fade to explain it. The response they get is that an RFO is billable and they have been asked to accept the charge to proceed (which they have rightly rejected thus far). This is the first time I've heard of this happening with any of our last-mile transport providers. I'm very curious, has anyone else experienced this lately with AT&T or any other carriers? -- Victor Breen | victor at impulse.net Sr. Engineer | Impulse Advanced Communications www.impulse.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricpatara at gmail.com Fri Jan 18 17:30:52 2019 From: ricpatara at gmail.com (Ricardo Patara) Date: Fri, 18 Jan 2019 15:30:52 -0200 Subject: contact from AS3 In-Reply-To: References: <0c3c05b0-dc05-d3f4-3b6d-2434f956d914@gmail.com> Message-ID: <6bd5f61e-9087-021c-bd5b-bea4f274a1c0@gmail.com> hi, good point! that is what looks like it is happening. I will check with the network admin that complained with me. thanks all (and as3 admin that reached out very quickly) regards Em 18/01/2019 15:10, Michael Still escreveu: > This is likely just a poor effort at prepending. What is the next ASN in > the path? They are likely the culprit. > > > On Fri, Jan 18, 2019 at 12:06 PM Ricardo Patara > wrote: > > Hello, > > I need to contact someone form AS3. If in the list, could you please > contact me privately. > > It seems this ASN is announcing IP blocks from other organization. > > Thanks > Ricardo Patara > > > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ From tony at swalter.com Fri Jan 18 17:34:42 2019 From: tony at swalter.com (Tony Patti) Date: Fri, 18 Jan 2019 17:34:42 +0000 Subject: AT&T starting to charge for RFOs on ASE tail circuits? In-Reply-To: References: Message-ID: Hi Victor, I was curious about this, so I did a Google search, and found this AT&T RFO PDF: http://attnocpr.com/custportal/wp-content/uploads/2017/01/ATT-PR-NOC-RFO.pdf While it does not specifically talk to your cost question, it does define a simple procedure to request RFO via email, and one would presume there is no cost, since none specified. Tony Patti [SW_logo_HighRes] CIO t: (215) 867-8401 f: (215) 268-7184 e: tony at swalter.com w: www.swalter.com From: NANOG > On Behalf Of Victor Breen Sent: Thursday, January 17, 2019 2:35 PM To: nanog at nanog.org Subject: AT&T starting to charge for RFOs on ASE tail circuits? Hey All, I just caught wind from multiple support reps of ours that AT&T is now demanding payment to get an RFO. As in, our folks are calling up AT&T to see why a particular tail circuit was down for whatever period of time and has since come back up with no clear utility power issue or backhoe fade to explain it. The response they get is that an RFO is billable and they have been asked to accept the charge to proceed (which they have rightly rejected thus far). This is the first time I've heard of this happening with any of our last-mile transport providers. I'm very curious, has anyone else experienced this lately with AT&T or any other carriers? -- Victor Breen | victor at impulse.net Sr. Engineer | Impulse Advanced Communications www.impulse.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Fri Jan 18 17:36:45 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 18 Jan 2019 17:36:45 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <755026443.8886.1547832291375.JavaMail.mhammett@ThunderFuck> References: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> <002101d4af51$c355f830$4a01e890$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FC61264@RTC-EXCH01.RESERVE.LDS> <755026443.8886.1547832291375.JavaMail.mhammett@ThunderFuck> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FC6149A@RTC-EXCH01.RESERVE.LDS> Here is what you get. resultDate ipAddress country region city latitude longitude serverId serverName userAgent connectionType ispName ispNameRaw download (Kbps) upload (Kbps) ping (ms) jitter testId From: Mike Hammett [mailto:nanog at ics-il.net] Sent: Friday, January 18, 2019 11:25 AM To: Luke Guillory Cc: NANOG; Aaron Gould; Colton Conor Subject: Re: Network Speed Testing and Monitoring Platform I haven't seen the level of reporting on the paid service because I don't have it, but I get reporting on a free, public server. ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Luke Guillory" > To: "Aaron Gould" >, "Colton Conor" > Cc: "NANOG" > Sent: Friday, January 18, 2019 11:22:21 AM Subject: RE: Network Speed Testing and Monitoring Platform The paid version gives you access to all the reporting from the test ran against your server. Luke Ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gould Sent: Friday, January 18, 2019 11:18 AM To: 'Colton Conor' Cc: 'NANOG' Subject: RE: Network Speed Testing and Monitoring Platform I think the motivation for the paid/onsite version of ookla was so that we could say how good our customers speed is, without going through the internet. We can’t control utilization on the Internet, but we can internally. -Aaron From: Colton Conor [mailto:colton.conor at gmail.com] Sent: Friday, January 18, 2019 8:37 AM To: Aaron Gould Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform Aaron, How does the https://account.speedtestcustom.com/login differ from hosting a speedtest.net server as an ISP, and letting anyone test through it? Seems the speedtest custom is a paid option, but hosting a speedtest.net server is free if you allow it to the public domain. Sure it uses up bandwidth (which I am sure you have a ton of), so I don't see the point of having a custom one? On Thu, Jan 17, 2019 at 10:27 AM Aaron Gould > wrote: https://github.com/adolfintel/speedtest - one drawback we’ve seen is upload test has issues on some iphones (maybe other mobile devices) in safari, but I think chrome might work, unsure https://account.speedtestcustom.com/login - ookla customer speedtest – we have this running *internally* in our network on VM and also bare-metal, this is where our customers test locally Iperf - us engineers used it wifiperf – us engineers used it -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Fri Jan 18 17:49:01 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Fri, 18 Jan 2019 12:49:01 -0500 Subject: Waves between Buffalo and Manhattan Message-ID: <6CA0DFDD-AEB8-4218-A281-4DDFE6DF5EB1@lixfeld.ca> Hello, Does anyone have knowledge of carriers who are able to deliver 10G or 100G waves between Buffalo and Manhattan that *do not* touch Albany? I know Zayo is one. I’m waiting to hear back from CenturyLink. I’ve reviewed networkatlas.org , to see if anything pops up there, but otherwise I’m coming up empty. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Fri Jan 18 17:59:01 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 18 Jan 2019 09:59:01 -0800 Subject: Waves between Buffalo and Manhattan In-Reply-To: <6CA0DFDD-AEB8-4218-A281-4DDFE6DF5EB1@lixfeld.ca> References: <6CA0DFDD-AEB8-4218-A281-4DDFE6DF5EB1@lixfeld.ca> Message-ID: hi Jason https://dev.networkatlas.org shows Zayo, Windstream (and Earthlink) there. We are working with Charter , Level3/CL to load their fiber routes , but it will be there and you will be able to connect with the sales teams directly by clicking on a route. . In addition to that there are other small players in this region. Mehmet On Fri, Jan 18, 2019 at 9:49 AM Jason Lixfeld wrote: > Hello, > > Does anyone have knowledge of carriers who are able to deliver 10G or 100G > waves between Buffalo and Manhattan that *do not* touch Albany? > > I know Zayo is one. I’m waiting to hear back from CenturyLink. I’ve > reviewed networkatlas.org, to see if anything pops up there, but > otherwise I’m coming up empty. > > Thanks in advance. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Jan 18 18:03:25 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Jan 2019 04:03:25 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190118180325.8FFE5C44B7@thyme.apnic.net> 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-stats at 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 19 Jan, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 734004 Prefixes after maximum aggregation (per Origin AS): 282378 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 353532 Total ASes present in the Internet Routing Table: 62962 Prefixes per ASN: 11.66 Origin-only ASes present in the Internet Routing Table: 54273 Origin ASes announcing only one prefix: 23530 Transit ASes present in the Internet Routing Table: 8689 Transit-only ASes present in the Internet Routing Table: 265 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 22 Number of instances of unregistered ASNs: 24 Number of 32-bit ASNs allocated by the RIRs: 25491 Number of 32-bit ASNs visible in the Routing Table: 20715 Prefixes from 32-bit ASNs in the Routing Table: 89526 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 273 Number of addresses announced to Internet: 2841952643 Equivalent to 169 /8s, 100 /16s and 193 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 245866 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 199790 Total APNIC prefixes after maximum aggregation: 57093 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 196929 Unique aggregates announced from the APNIC address blocks: 81448 APNIC Region origin ASes present in the Internet Routing Table: 9384 APNIC Prefixes per ASN: 20.99 APNIC Region origin ASes announcing only one prefix: 2643 APNIC Region transit ASes present in the Internet Routing Table: 1386 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4378 Number of APNIC addresses announced to Internet: 769374242 Equivalent to 45 /8s, 219 /16s and 184 /24s APNIC AS Blocks 4608-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: 217361 Total ARIN prefixes after maximum aggregation: 103199 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 216564 Unique aggregates announced from the ARIN address blocks: 103707 ARIN Region origin ASes present in the Internet Routing Table: 18321 ARIN Prefixes per ASN: 11.82 ARIN Region origin ASes announcing only one prefix: 6799 ARIN Region transit ASes present in the Internet Routing Table: 1847 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2549 Number of ARIN addresses announced to Internet: 1079601824 Equivalent to 64 /8s, 89 /16s and 106 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 201336 Total RIPE prefixes after maximum aggregation: 95847 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 197689 Unique aggregates announced from the RIPE address blocks: 116800 RIPE Region origin ASes present in the Internet Routing Table: 25749 RIPE Prefixes per ASN: 7.68 RIPE Region origin ASes announcing only one prefix: 11481 RIPE Region transit ASes present in the Internet Routing Table: 3615 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7738 Number of RIPE addresses announced to Internet: 716348864 Equivalent to 42 /8s, 178 /16s and 157 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 95296 Total LACNIC prefixes after maximum aggregation: 22034 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 96718 Unique aggregates announced from the LACNIC address blocks: 42241 LACNIC Region origin ASes present in the Internet Routing Table: 7994 LACNIC Prefixes per ASN: 12.10 LACNIC Region origin ASes announcing only one prefix: 2186 LACNIC Region transit ASes present in the Internet Routing Table: 1494 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5547 Number of LACNIC addresses announced to Internet: 173205248 Equivalent to 10 /8s, 82 /16s and 231 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 20198 Total AfriNIC prefixes after maximum aggregation: 4186 AfriNIC Deaggregation factor: 4.83 Prefixes being announced from the AfriNIC address blocks: 25831 Unique aggregates announced from the AfriNIC address blocks: 9092 AfriNIC Region origin ASes present in the Internet Routing Table: 1232 AfriNIC Prefixes per ASN: 20.97 AfriNIC Region origin ASes announcing only one prefix: 421 AfriNIC Region transit ASes present in the Internet Routing Table: 242 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 19 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 503 Number of AfriNIC addresses announced to Internet: 103019520 Equivalent to 6 /8s, 35 /16s and 244 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4649 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4610 524 522 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3043 1159 92 VIETEL-AS-AP Viettel Group, VN 45899 3000 1721 111 VNPT-AS-VN VNPT Corp, VN 4766 2809 11127 767 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 551 BSNL-NIB National Internet Backbone, IN 9808 2473 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2401 4906 29 CTTNET China TieTong Telecommunications 4755 2143 438 181 TATACOMM-AS TATA Communications formerl 17974 2035 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3536 1326 92 SHAW - Shaw Communications Inc., CA 11492 3490 225 613 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2606 5374 989 AMAZON-02 - Amazon.com, Inc., US 16625 2255 1238 1704 AKAMAI-AS - Akamai Technologies, Inc., 20115 2149 2753 537 CHARTER-20115 - Charter Communications, 18566 2136 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2118 355 111 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2089 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2071 5076 585 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5302 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3283 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2640 573 1937 AKAMAI-ASN1, US 12389 2230 2220 631 ROSTELECOM-AS, RU 34984 2056 338 525 TELLCOM-AS, TR 9121 1690 1691 17 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 8402 1301 545 15 CORBINA-AS OJSC "Vimpelcom", RU 9009 1279 139 714 M247, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5518 3326 588 Uninet S.A. de C.V., MX 10620 3143 473 915 Telmex Colombia S.A., CO 11830 2675 371 59 Instituto Costarricense de Electricidad 6503 1620 449 54 Axtel, S.A.B. de C.V., MX 7303 1441 961 226 Telecom Argentina S.A., AR 28573 1178 2239 183 CLARO S.A., BR 6147 1088 377 29 Telefonica del Peru S.A.A., PE 3816 1029 511 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 935 143 66 Alestra, S. de R.L. de C.V., MX 13999 928 535 253 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1148 393 22 LINKdotNET-AS, EG 37611 903 107 9 Afrihost, ZA 36903 797 401 139 MT-MPLS, MA 36992 784 1411 44 ETISALAT-MISR, EG 24835 684 634 21 RAYA-AS, EG 8452 642 1731 20 TE-AS TE-AS, EG 29571 482 70 13 ORANGE-COTE-IVOIRE, CI 37492 459 470 57 ORANGE-, TN 15399 417 45 11 WANANCHI-, KE 37342 416 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5518 3326 588 Uninet S.A. de C.V., MX 12479 5302 1628 138 UNI2-AS, ES 4538 4649 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4610 524 522 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3536 1326 92 SHAW - Shaw Communications Inc., CA 11492 3490 225 613 CABLEONE - CABLE ONE, INC., US 22773 3310 2979 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3283 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 10620 3143 473 915 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5302 5164 UNI2-AS, ES 4538 4649 4575 ERX-CERNET-BKB China Education and Research Net 7545 4610 4088 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3536 3444 SHAW - Shaw Communications Inc., CA 8551 3283 3240 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3310 3136 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3043 2951 VIETEL-AS-AP Viettel Group, VN 45899 3000 2889 VNPT-AS-VN VNPT Corp, VN 11492 3490 2877 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 174405 UNALLOCATED 103.217.158.0/24 135405 TMHTTWTL-AS-AP WELINK, MM 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.96.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:36 /11:99 /12:292 /13:568 /14:1129 /15:1917 /16:13358 /17:7881 /18:13838 /19:25541 /20:39660 /21:46167 /22:91397 /23:74725 /24:414525 /25:922 /26:827 /27:877 /28:20 /29:6 /30:7 /31:0 /32:190 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4153 5302 UNI2-AS, ES 6327 3299 3536 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2763 3490 CABLEONE - CABLE ONE, INC., US 8551 2739 3283 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2549 3310 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2031 2136 MEGAPATH5-US - MegaPath Corporation, US 11830 2021 2675 Instituto Costarricense de Electricidad y Telec 30036 1864 2118 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2089 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1612 2:895 3:1 4:23 5:2779 6:43 7:1 8:1176 12:1874 13:307 14:1890 15:36 16:2 17:218 18:59 20:49 23:2590 24:2413 25:2 27:2553 31:2040 32:92 35:31 36:827 37:3012 38:1606 39:289 40:122 41:3130 42:729 43:2000 44:140 45:6508 46:3158 47:247 49:1329 50:1084 51:320 52:1075 54:360 55:1 56:6 57:41 58:1715 59:1058 60:460 61:2070 62:2202 63:1811 64:5095 65:2194 66:4820 67:2676 68:1153 69:3453 70:1151 71:604 72:2281 74:2752 75:416 76:542 77:1719 78:1757 79:2316 80:1651 81:1431 82:1068 83:899 84:1082 85:2137 86:559 87:1544 88:983 89:2398 90:211 91:6556 92:1228 93:2375 94:2428 95:3204 96:910 97:349 98:938 99:169 100:87 101:1159 102:355 103:19831 104:3559 105:245 106:875 107:1822 108:695 109:3646 110:1642 111:1866 112:1403 113:1404 114:1154 115:1724 116:1655 117:1917 118:2215 119:1674 120:1063 121:1026 122:2365 123:1638 124:1443 125:1947 128:1197 129:693 130:520 131:1636 132:707 133:216 134:1046 135:229 136:544 137:679 138:1968 139:812 140:570 141:774 142:799 143:1004 144:908 145:504 146:1244 147:776 148:1716 149:810 150:781 151:1002 152:975 153:324 154:2412 155:969 156:1637 157:874 158:659 159:1907 160:1497 161:908 162:2659 163:775 164:1119 165:1590 166:452 167:1368 168:3261 169:870 170:4010 171:501 172:1067 173:2155 174:1000 175:869 176:2290 177:4069 178:2564 179:1291 180:2084 181:2382 182:2675 183:1059 184:1136 185:14570 186:3699 187:2439 188:2956 189:2095 190:8297 191:1420 192:10041 193:6523 194:5321 195:4036 196:2900 197:1729 198:5724 199:5951 200:7409 201:5026 202:10119 203:10112 204:4622 205:3012 206:3295 207:3265 208:3956 209:4214 210:3923 211:1983 212:3041 213:2834 214:1068 215:52 216:5982 217:2198 218:920 219:572 220:1833 221:995 222:977 223:1428 End of report From jason+nanog at lixfeld.ca Fri Jan 18 18:11:09 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Fri, 18 Jan 2019 13:11:09 -0500 Subject: Waves between Buffalo and Manhattan In-Reply-To: References: <6CA0DFDD-AEB8-4218-A281-4DDFE6DF5EB1@lixfeld.ca> Message-ID: Hi Mehmet, Indeed Windstream has dark on an appropriate route, and we’re talking to them about that. However they don’t seem to have lit services on that route. > On Jan 18, 2019, at 12:59 PM, Mehmet Akcin wrote: > > hi Jason > > https://dev.networkatlas.org shows Zayo, Windstream (and Earthlink) there. > > We are working with Charter , Level3/CL to load their fiber routes , but it will be there and you will be able to connect with the sales teams directly by clicking on a route. . In addition to that there are other small players in this region. > > Mehmet > > On Fri, Jan 18, 2019 at 9:49 AM Jason Lixfeld > wrote: > Hello, > > Does anyone have knowledge of carriers who are able to deliver 10G or 100G waves between Buffalo and Manhattan that *do not* touch Albany? > > I know Zayo is one. I’m waiting to hear back from CenturyLink. I’ve reviewed networkatlas.org , to see if anything pops up there, but otherwise I’m coming up empty. > > Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhatton at htva.net Fri Jan 18 18:36:17 2019 From: bhatton at htva.net (Benjamin Hatton) Date: Fri, 18 Jan 2019 13:36:17 -0500 Subject: Waves between Buffalo and Manhattan In-Reply-To: References: <6CA0DFDD-AEB8-4218-A281-4DDFE6DF5EB1@lixfeld.ca> Message-ID: The regional players in the area that may have something that would bypass Albany would be Firstlight (Formerly Finger Lakes Technology Group) and Uniti. Firstlight has more fiber in the area, and would be my choice over Uniti, I have services with both. Contact me off list if you want an introduction to a sales guy. On Fri, Jan 18, 2019 at 1:00 PM Mehmet Akcin wrote: > hi Jason > > https://dev.networkatlas.org shows Zayo, Windstream (and Earthlink) > there. > > We are working with Charter , Level3/CL to load their fiber routes , but > it will be there and you will be able to connect with the sales teams > directly by clicking on a route. . In addition to that there are other > small players in this region. > > Mehmet > > On Fri, Jan 18, 2019 at 9:49 AM Jason Lixfeld > wrote: > >> Hello, >> >> Does anyone have knowledge of carriers who are able to deliver 10G or >> 100G waves between Buffalo and Manhattan that *do not* touch Albany? >> >> I know Zayo is one. I’m waiting to hear back from CenturyLink. I’ve >> reviewed networkatlas.org, to see if anything pops up there, but >> otherwise I’m coming up empty. >> >> Thanks in advance. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Jan 18 20:57:36 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 18 Jan 2019 15:57:36 -0500 Subject: Waves between Buffalo and Manhattan In-Reply-To: References: <6CA0DFDD-AEB8-4218-A281-4DDFE6DF5EB1@lixfeld.ca> Message-ID: If it's for the use case I suspect it would be for, Firstlight and Windstream should bring you closer to where you'll want to be on the Buffalo side. On Fri, Jan 18, 2019 at 1:38 PM Benjamin Hatton wrote: > The regional players in the area that may have something that would bypass > Albany would be Firstlight (Formerly Finger Lakes Technology Group) and > Uniti. > > Firstlight has more fiber in the area, and would be my choice over Uniti, > I have services with both. > > > Contact me off list if you want an introduction to a sales guy. > > > On Fri, Jan 18, 2019 at 1:00 PM Mehmet Akcin wrote: > >> hi Jason >> >> https://dev.networkatlas.org shows Zayo, Windstream (and Earthlink) >> there. >> >> We are working with Charter , Level3/CL to load their fiber routes , but >> it will be there and you will be able to connect with the sales teams >> directly by clicking on a route. . In addition to that there are other >> small players in this region. >> >> Mehmet >> >> On Fri, Jan 18, 2019 at 9:49 AM Jason Lixfeld >> wrote: >> >>> Hello, >>> >>> Does anyone have knowledge of carriers who are able to deliver 10G or >>> 100G waves between Buffalo and Manhattan that *do not* touch Albany? >>> >>> I know Zayo is one. I’m waiting to hear back from CenturyLink. I’ve >>> reviewed networkatlas.org, to see if anything pops up there, but >>> otherwise I’m coming up empty. >>> >>> Thanks in advance. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton.conor at gmail.com Fri Jan 18 21:05:43 2019 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 18 Jan 2019 15:05:43 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> Message-ID: Tim, Doesn't OpenWRT support iperf3? Why not use that instead of wget? I think there are a ton of options if I go with an OpenWRT based router. Still not sure if I want to go through the process of developing out own consumer grade routers, but still no one beside Mikrotik seems to have speed test's built into their sub $100 CPEs. On Fri, Jan 18, 2019 at 11:35 AM Tim J wrote: > On 2019-01-18 10:37, Colton Conor wrote: > > Aaron, > > > > How does the https://account.speedtestcustom.com/login [2] differ > > from hosting a speedtest.net [3] server as an ISP, and letting anyone > > test through it? Seems the speedtest custom is a paid option, but > > hosting a speedtest.net [3] server is free if you allow it to the > > public domain. Sure it uses up bandwidth (which I am sure you have a > > ton of), so I don't see the point of having a custom one? > Hi Colton, > > This may be too light-weight and manual for you, but in the past I've > supplied a few clients with a decent OpenWrt router. I can then SSH in > and do a wget to my FTP site. It might not be 100% accurate, but it's > good low cost option for me, and enough for my purposes. YMMV. > > Tim > > > > > On Thu, Jan 17, 2019 at 10:27 AM Aaron Gould wrote: > > > >> https://github.com/adolfintel/speedtest [1] - one drawback we’ve > >> seen is upload test has issues on some iphones (maybe other mobile > >> devices) in safari, but I think chrome might work, unsure > >> > >> https://account.speedtestcustom.com/login [2] - ookla customer > >> speedtest – we have this running *INTERNALLY* in our network on VM > >> and also bare-metal, this is where our customers test locally > >> > >> Iperf - us engineers used it > >> > >> wifiperf – us engineers used it > >> > >> -Aaron > > > > > > Links: > > ------ > > [1] https://github.com/adolfintel/speedtest > > [2] https://account.speedtestcustom.com/login > > [3] http://speedtest.net > > -- > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > system manager. This message contains confidential information and is > intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. If you are > not the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Jan 18 22:16:52 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 18 Jan 2019 16:16:52 -0600 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FC61264@RTC-EXCH01.RESERVE.LDS> References: <002401d4ae81$856e9ca0$904bd5e0$@gvtc.com> <002101d4af51$c355f830$4a01e890$@gvtc.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FC61264@RTC-EXCH01.RESERVE.LDS> Message-ID: <006801d4af7b$83bdcfc0$8b396f40$@gvtc.com> Yes that too, thanks for the reminder, the linux sys eng I work with here showed me our internal stats the other day when I was asking him about this… -Aaron From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Friday, January 18, 2019 11:22 AM To: Aaron Gould; 'Colton Conor' Cc: 'NANOG' Subject: RE: Network Speed Testing and Monitoring Platform The paid version gives you access to all the reporting from the test ran against your server. Luke Ns -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Fri Jan 18 23:04:43 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 18 Jan 2019 15:04:43 -0800 Subject: Looking for a network operations/security contact at BNSF railway Message-ID: If anybody has one, please get in contact with me ASAP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Fri Jan 18 23:41:10 2019 From: ben at 6by7.net (Ben Cannon) Date: Fri, 18 Jan 2019 15:41:10 -0800 Subject: Contact for BART Message-ID: Could someone from BART get ahold of me off list? Netops/security/ROW team. -Ben From nanog at ics-il.net Sat Jan 19 00:02:46 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 18 Jan 2019 18:02:46 -0600 (CST) Subject: Charter Porting In-Reply-To: <1896674667.9330.1547856126987.JavaMail.mhammett@ThunderFuck> Message-ID: <346803511.9335.1547856164577.JavaMail.mhammett@ThunderFuck> I first tried on VoiceOps, but didn't get any responses. Anyone have a useful contact in Charter's porting department? We've been trying to port a number for 10 days, but haven't been setup with their portal yet. The luck I'm having with the people at the e-mail address (Charter.STL.LSR at charter.com) specified in their porting instructions web site (https://www.spectrum.com/policies/local-number-portability-business-rules.html) is about as good as building a bridge out of wet noodles. Can't start the port until we have access to their portal. Can't get access to their portal until they pull their heads out. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jan 19 01:16:36 2019 From: bill at herrin.us (William Herrin) Date: Fri, 18 Jan 2019 17:16:36 -0800 Subject: Contact for BART In-Reply-To: References: Message-ID: On Fri, Jan 18, 2019 at 3:41 PM Ben Cannon wrote: > Could someone from BART get ahold of me off list? Netops/security/ROW team. Matt Groening is unavailable. And why do you want to get in to a fight with him? (unless you think BART and ROW have other well understood meanings within the networking world?) -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From ben at 6by7.net Sat Jan 19 01:18:02 2019 From: ben at 6by7.net (Ben Cannon) Date: Fri, 18 Jan 2019 17:18:02 -0800 Subject: Contact for BART In-Reply-To: References: Message-ID: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… What are you talking about? -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Jan 18, 2019, at 5:16 PM, William Herrin wrote: > > On Fri, Jan 18, 2019 at 3:41 PM Ben Cannon wrote: >> Could someone from BART get ahold of me off list? Netops/security/ROW team. > > Matt Groening is unavailable. And why do you want to get in to a fight with him? > > (unless you think BART and ROW have other well understood meanings > within the networking world?) > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From llabas at gmail.com Sat Jan 19 01:24:54 2019 From: llabas at gmail.com (Larry LaBas) Date: Fri, 18 Jan 2019 17:24:54 -0800 Subject: Contact for BART In-Reply-To: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> Message-ID: I have the song from 'The Simpsons' running through my head right now.... Sent from my iPhone > On Jan 18, 2019, at 17:18, Ben Cannon wrote: > > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… > > What are you talking about? > > -Ben Cannon > CEO 6x7 Networks & 6x7 Telecom, LLC > ben at 6by7.net > > > > > >> On Jan 18, 2019, at 5:16 PM, William Herrin wrote: >> >>> On Fri, Jan 18, 2019 at 3:41 PM Ben Cannon wrote: >>> Could someone from BART get ahold of me off list? Netops/security/ROW team. >> >> Matt Groening is unavailable. And why do you want to get in to a fight with him? >> >> (unless you think BART and ROW have other well understood meanings >> within the networking world?) >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jan 19 01:25:20 2019 From: bill at herrin.us (William Herrin) Date: Fri, 18 Jan 2019 17:25:20 -0800 Subject: Contact for BART In-Reply-To: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> Message-ID: On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon wrote: > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… Now you've said enough that if the person you're looking for is here he'll have some idea you mean him. > What are you talking about? Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Sat Jan 19 01:27:51 2019 From: ben at 6by7.net (Ben Cannon) Date: Fri, 18 Jan 2019 17:27:51 -0800 Subject: Contact for BART In-Reply-To: References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> Message-ID: <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> HAH. Apologies for copying the list. But I think we all needed a good Friday laugh. Making it relevant again, also looking for a good contact within CALDOT (California Dept of Transportation) and the joint bridge authority for the Bay Bridge in San Francisco. Have a good weekend all :) -Ben Cannon > On Jan 18, 2019, at 5:25 PM, William Herrin wrote: > > On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon > wrote: > > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… > > Now you've said enough that if the person you're looking for is here he'll have some idea you mean him. > > > > What are you talking about? > > Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > <6x7_speedTest.JPG> -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jan 20 01:26:57 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Jan 2019 17:26:57 -0800 Subject: Contact for BART In-Reply-To: References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> Message-ID: > On Jan 18, 2019, at 17:25 , William Herrin wrote: > > On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon > wrote: > > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… > > Now you've said enough that if the person you're looking for is here he'll have some idea you mean him. If the person he was looking for was on here, they would have understood it without the additional details. Indeed, ANYONE in the state of California probably got his meaning. Certainly anyone in the SF Bay area understood. > > What are you talking about? > > Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? Could be amusing, perhaps an event some people would buy tickets to as a source of revenue. I agree that it’s worth considering the breadth of the audience you are posting to when deciding how much to abbreviate your message. However, it’s not unusual for people to fail to do that. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jan 20 01:27:39 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Jan 2019 17:27:39 -0800 Subject: Contact for BART In-Reply-To: <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> Message-ID: <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> You’ll have more luck finding California Dept. of Transportation if you call them “CalTrans” which is what they call themselves. Owen > On Jan 18, 2019, at 17:27 , Ben Cannon wrote: > > HAH. Apologies for copying the list. But I think we all needed a good Friday laugh. > > Making it relevant again, also looking for a good contact within CALDOT (California Dept of Transportation) and the joint bridge authority for the Bay Bridge in San Francisco. > > Have a good weekend all :) > > -Ben Cannon > >> On Jan 18, 2019, at 5:25 PM, William Herrin > wrote: >> >> On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon > wrote: >> > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… >> >> Now you've said enough that if the person you're looking for is here he'll have some idea you mean him. >> >> >> > What are you talking about? >> >> Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? >> >> Regards, >> Bill Herrin >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: > >> <6x7_speedTest.JPG> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc at ottie.org Sun Jan 20 09:52:16 2019 From: sc at ottie.org (Scott Christopher) Date: Sun, 20 Jan 2019 09:52:16 +0000 Subject: Contact for BART In-Reply-To: <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> Message-ID: <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> No :) BART is Bay Area Rapid Transit, a public transportation system with its own bureaucracy and publicly elected board. Caltrans is a separate State bureaucracy, though it has a big office in the city of Oakland near BART Headquarters. And then there is Caltrain which is the commuter rail that runs down the peninsula. That organization has its own bureaucracy and board, too. Lesson to be learned: don't use obscure acronyms unknown outside a small geographical region :) Owen DeLong wrote: > You’ll have more luck finding California Dept. of Transportation if > you call them “CalTrans” which is what they call themselves.> > Owen > > >> On Jan 18, 2019, at 17:27 , Ben Cannon wrote: >> >> HAH. Apologies for copying the list. But I think we all needed a >> good Friday laugh.>> >> Making it relevant again, also looking for a good contact within >> CALDOT (California Dept of Transportation) and the joint bridge >> authority for the Bay Bridge in San Francisco.>> >> Have a good weekend all :) >> >> -Ben Cannon >> >>> On Jan 18, 2019, at 5:25 PM, William Herrin wrote:>>> >>> On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon wrote: >>> > I’m speaking of the san francisco based Bay Area Rapid Transit >>> > department about Rights Of Way for fiber…>>> >>> Now you've said enough that if the person you're looking for is here >>> he'll have some idea you mean him.>>> >>> >>> > What are you talking about? >>> >>> Inappropriate abbreviation. I mean sure, why not a NANOG Friday >>> Fight Club, but why would you want to get in a ROW (noisy argument) >>> with BART Simpson?>>> >>> Regards, >>> Bill Herrin >>> >>> -- >>> William Herrin ................ herrin at dirtside.com bill at herrin.us>>> Dirtside Systems ......... Web: >>> <6x7_speedTest.JPG> S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyeronic.design at gmail.com Sun Jan 20 10:23:23 2019 From: eyeronic.design at gmail.com (Mike Hale) Date: Sun, 20 Jan 2019 02:23:23 -0800 Subject: Contact for BART In-Reply-To: <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> Message-ID: I mean, did anyone seriously ever confuse BART with Bart Simpson? Or ROW with row? Come on now. On Sun, Jan 20, 2019 at 1:53 AM Scott Christopher wrote: > > No :) > > BART is Bay Area Rapid Transit, a public transportation system with its own bureaucracy and publicly elected board. > > Caltrans is a separate State bureaucracy, though it has a big office in the city of Oakland near BART Headquarters. > > And then there is Caltrain which is the commuter rail that runs down the peninsula. That organization has its own bureaucracy and board, too. > > Lesson to be learned: don't use obscure acronyms unknown outside a small geographical region :) > > Owen DeLong wrote: > > You’ll have more luck finding California Dept. of Transportation if you call them “CalTrans” which is what they call themselves. > > Owen > > > On Jan 18, 2019, at 17:27 , Ben Cannon wrote: > > HAH. Apologies for copying the list. But I think we all needed a good Friday laugh. > > Making it relevant again, also looking for a good contact within CALDOT (California Dept of Transportation) and the joint bridge authority for the Bay Bridge in San Francisco. > > Have a good weekend all :) > > -Ben Cannon > > On Jan 18, 2019, at 5:25 PM, William Herrin wrote: > > On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon wrote: > > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… > > Now you've said enough that if the person you're looking for is here he'll have some idea you mean him. > > > > What are you talking about? > > Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > <6x7_speedTest.JPG> > > > S.C. > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From ramy.ihashish at gmail.com Sun Jan 20 10:52:44 2019 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Sun, 20 Jan 2019 12:52:44 +0200 Subject: DANOS - The Linux Foundation - AT&T Message-ID: Good day all, Following up the announcement in March 2018, aren't there any news for releasing the code? Thanks, Ramy -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jan 20 18:38:34 2019 From: owen at delong.com (Owen DeLong) Date: Sun, 20 Jan 2019 10:38:34 -0800 Subject: Contact for BART In-Reply-To: <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> Message-ID: > On Jan 20, 2019, at 01:52 , Scott Christopher wrote: > > No :) Huh? > > BART is Bay Area Rapid Transit, a public transportation system with its own bureaucracy and publicly elected board. > > Caltrans is a separate State bureaucracy, though it has a big office in the city of Oakland near BART Headquarters. I’m quite aware of this. If you’ll note, the thing I was replying to said he was ALSO looking for a good contact within CALDOT. I was pointing out that CALDOT doesn’t call itself CALDOT, but refers to itself as CalTrans. > And then there is Caltrain which is the commuter rail that runs down the peninsula. That organization has its own bureaucracy and board, too. Sure, but I’m not sure how that suddenly became relevant to the conversation. > Lesson to be learned: don't use obscure acronyms unknown outside a small geographical region :) Well, I think calling any of the above terms “obscure” is a bit of a stretch. I would agree that they are not widely known outside of California and that the level of common knowledge may decrease with distance from the immediate SF Bay Area. However, referring to them as obscure when I think you’d be hard pressed to find anyone who has ever spent more than 2 weeks i the bay area that isn’t familiar with them seems a bit of an exaggeration. Owen > > Owen DeLong wrote: > >> You’ll have more luck finding California Dept. of Transportation if you call them “CalTrans” which is what they call themselves. >> >> Owen >> >> >>> On Jan 18, 2019, at 17:27 , Ben Cannon > wrote: >>> >>> HAH. Apologies for copying the list. But I think we all needed a good Friday laugh. >>> >>> Making it relevant again, also looking for a good contact within CALDOT (California Dept of Transportation) and the joint bridge authority for the Bay Bridge in San Francisco. >>> >>> Have a good weekend all :) >>> >>> -Ben Cannon >>> >>>> On Jan 18, 2019, at 5:25 PM, William Herrin > wrote: >>>> >>>> On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon > wrote: >>>> > I’m speaking of the san francisco based Bay Area Rapid Transit department about Rights Of Way for fiber… >>>> >>>> Now you've said enough that if the person you're looking for is here he'll have some idea you mean him. >>>> >>>> >>>> > What are you talking about? >>>> >>>> Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> -- >>>> William Herrin ................ herrin at dirtside.com bill at herrin.us >>>> Dirtside Systems ......... Web: > >>>> <6x7_speedTest.JPG> > > S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Sun Jan 20 22:34:08 2019 From: ben at 6by7.net (Ben Cannon) Date: Sun, 20 Jan 2019 14:34:08 -0800 Subject: Contact for BART In-Reply-To: References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> Message-ID: <57C5988F-7840-460E-998C-3B5341956421@6by7.net> I mean, it’s the first hit in this thing we have at work called Google. http://bfy.tw/JYgG :) -Ben > On Jan 20, 2019, at 10:38 AM, Owen DeLong wrote: > > agree -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philip.Loenneker at tasmanet.com.au Sun Jan 20 22:55:23 2019 From: Philip.Loenneker at tasmanet.com.au (Philip Loenneker) Date: Sun, 20 Jan 2019 22:55:23 +0000 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: Hi Colton, Sorry for getting your name switched around last time, I only just noticed that! A specific TR-069 implementation that I know has the speed test function is UMP Cloud, however I’m not sure exactly how it does it. You can see their spiel here: https://www.avsystem.com/products/cloud-ump/ That said, TR-143 includes a time-based throughput test, so that you can test for defined number of seconds instead of a particular file size. That should allow you to suitably test any speed service. Refer to section 4.3 in the following document: https://www.broadband-forum.org/technical/download/TR-143.pdf Regards, Philip Loenneker | Network Engineer | TasmaNet From: Colton Conor Sent: Saturday, 19 January 2019 1:34 AM To: Philip Loenneker Cc: NANOG Subject: Re: Network Speed Testing and Monitoring Platform Philip, Which TR-069 tools are you referring to? I looked at TR-143, but its my understanding it downloads a small file (like 50MB) from the TR-069 server to the CPE's ram. Then uploads the file back. Unfortunately I couldn't see how this would reliability test 1Gbps connections. Can you increase the file size? Most of these modems have like 128MB ram right now? On Thu, Jan 17, 2019 at 5:07 PM Philip Loenneker > wrote: Connor, If you use the Traffic Generator tool instead of the Bandwidth Test tool built into MikroTik, you can definitely flood a 1Gbps link. However it requires the device to receive the packets that it has sent out, so it’s only viable for links with the same up/down speed. We have been investigating some TR-069 platforms, and several of those offer speed test functionality built in. This means our helpdesk guys can just click a few buttons to trigger it, it only talks to the CPE (nothing on customer LAN), and people don’t need to know how to configure the test other than “click here”. TR-069 also has a lot of other advantages which you can easily discover with a quick search. Regards, Philip Loenneker | Network Engineer | TasmaNet From: NANOG > On Behalf Of Colton Conor Sent: Friday, 18 January 2019 12:17 AM To: James Bensley > Cc: NANOG > Subject: Re: Network Speed Testing and Monitoring Platform All, thanks for the recommendations both on and off list. It has been brought to my attention that a Mikrotik has a bandwidth speed test tool built into their operating system. Someone recommended a https://mikrotik.com/product/hap_ac2 for MSRP of $69. The release notes of the newest version say: !) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only); *) btest - added multithreading support for both UDP and TCP tests; Do you think this device can push a full 1Gbps connection? It does have a quad core qualcom processor. Besides mikrotik, I haven't found anything that doesn't require me to build a solution. Like OpenWRT with ipef3, or something like that. Seems like a commercial solution would exist for this. I though CAF providers have to test bandwidth for the FCC randomly to get funding? On Thu, Jan 17, 2019 at 2:59 AM James Bensley > wrote: On Wed, 16 Jan 2019 at 16:54, Colton Conor > wrote: > > As an internet service provider with many small business and residential customers, our most common tech support calls are speed related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly tells us up-time and if data is flowing across the interface. We can of course see the link speed, but customer call in saying the are not getting that speed. > > We are looking for a way to remotely test customers internet connections besides telling the customer to go to speedtest.net, or worse sending a tech out with a laptop to do the same thing. > > What opensource and commercial options are out there? Hi Colton, In the past I have used CPEs which support remote loopback. When the customer complains we enable remote loopback, send the traffic to that customers connection (rather than requiring a CPE that can generate the traffic or having an on site device) and measuring what comes back. Cheers, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From EPers at ansencorp.com Mon Jan 21 18:32:29 2019 From: EPers at ansencorp.com (Edwin Pers) Date: Mon, 21 Jan 2019 18:32:29 +0000 Subject: Tools for streaming analysis In-Reply-To: References: Message-ID: <8848fff1655f45a681b9955c2ead3ea8@ansencorp.com> We’re been using elastiflow for about a year now with good results. It's elasticsearch in the backend, so be prepared to throw a lot of ram at it. -ed From: NANOG On Behalf Of Ben Logan Sent: Sunday, January 13, 2019 1:48 PM To: nanog at nanog.org Subject: Tools for streaming analysis Hey folks, Just wondered what others are using for traffic analysis, particularly for identifying the amount of streaming (audio/video) traffic on your networks.  I prefer open source, whether free or commercial, but am open to any good suggestions. Looked at ntopng and like it ok, but think it could be more flexible.  Like the idea of pmacctd and friends, but not sure how I'd break down the streaming traffic with it.  I'm ok with raw data...I can generate the graphs I want.  I don't like anything with Solarwinds in the title! Btw, the data will be from a mix of Brocade, Cisco and Juniper routers, so sflow, netflow and IPFIX may all be used. Thanks, Ben From sc at ottie.org Mon Jan 21 18:37:59 2019 From: sc at ottie.org (Scott Christopher) Date: Mon, 21 Jan 2019 18:37:59 +0000 Subject: Contact for BART In-Reply-To: References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> <8565C378-8988-42AF-A95B-E912E265620B@6by7.net> <5D35D3C8-9981-405D-BC3B-EC91CDD88446@delong.com> <1547977936.2423721.1639172096.49AAFAEC@webmail.messagingengine.com> Message-ID: <1548095879.125483.1640172512.0D521EED@webmail.messagingengine.com> Owen DeLong wrote: > I’m quite aware of this. If you’ll note, the thing I was replying to > said he was ALSO looking for a good contact within CALDOT. My bad - I didn't read this thread thoroughly. But my email client is at fault too... it hid all the quoted text under a button "Show quoted text" because you top-posted, so I didn't see any context. I'm filing a bug report. /me ducks and taps out S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mankamis at cisco.com Mon Jan 21 19:48:21 2019 From: mankamis at cisco.com (Mankamana Mishra (mankamis)) Date: Mon, 21 Jan 2019 19:48:21 +0000 Subject: do we not get agenda of nanog meeting in advance ? Message-ID: Hi, I was trying to figure out what is the agenda / presentation in Nanog 75 ? does it not get published in advance ? Thanks Mankamana -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at intentionet.com Mon Jan 21 20:04:59 2019 From: dan at intentionet.com (Dan Halperin) Date: Mon, 21 Jan 2019 12:04:59 -0800 Subject: do we not get agenda of nanog meeting in advance ? In-Reply-To: References: Message-ID: On Mon, Jan 21, 2019 at 11:49 AM Mankamana Mishra (mankamis) via NANOG < nanog at nanog.org> wrote: > Hi, > > I was trying to figure out what is the agenda / presentation in Nanog 75 ? > does it not get published in advance ? > > Per the CFP ( http://www.cvent.com/events/nanog-75/custom-22-948222eca5834bc2b7a679399063e724.aspx under Key Dates), the agenda will be published tomorrow. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jan 22 09:24:40 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 22 Jan 2019 11:24:40 +0200 Subject: Network Speed Testing and Monitoring Platform In-Reply-To: References: Message-ID: <5f85c788-2f43-ba05-e1fd-986a6bc364d2@seacom.mu> After faffing about for quite some time with Ookla and iPerf, we have now settled on Viavi's QT-600 platform:     https://www.viavisolutions.com/en-us/products/qt-600-ethernet-probe-portfolio We shall use it as a private system, primarily to activate and handover customer services, and on rare occasions, perform post-delivery testing. We are no longer interested in indulging endless speed tests that are practically meaningless and leave ISP's with the burden of explaining things they can't control. Mark. On 16/Jan/19 18:52, Colton Conor wrote: > As an internet service provider with many small business and > residential customers, our most common tech support calls are speed > related. Customers complaining on slow speeds, slowdowns, etc. > > We have a SNMP and ping monitoring platform today, but that mainly > tells us up-time and if data is flowing across the interface. We can > of course see the link speed, but customer call in saying the are not > getting that speed.  > > We are looking for a way to remotely test customers internet > connections besides telling the customer to go to speedtest.net > , or worse sending a tech out with a laptop to > do the same thing. > > What opensource and commercial options are out there?  > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Quincy.Marshall at reged.com Tue Jan 22 12:55:03 2019 From: Quincy.Marshall at reged.com (Marshall, Quincy) Date: Tue, 22 Jan 2019 12:55:03 +0000 Subject: Contact for BART In-Reply-To: References: <9A0E2DC2-0DA0-4E4F-9784-F238E39E6B7E@6by7.net> Message-ID: <3438B611A2B2C04495EF0E1B25729C463322D366@mbx032-e1-va-8.exch032.serverpod.net> > On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon wrote: > > What are you talking about? > > Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, but why would you want to get in a ROW (noisy argument) with BART Simpson? Here, here… first thought BART private aviation software package (http://seagilbart.com), then thought BART Simpson (and then about Matt Groening, however you pronounce his name) , then though a Google search was the best answer. Either way that FWIW that was a long drive, to get the left coast. Q. Marshall --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From cunha at dcc.ufmg.br Tue Jan 22 14:16:21 2019 From: cunha at dcc.ufmg.br (Italo Cunha) Date: Tue, 22 Jan 2019 09:16:21 -0500 Subject: BGP Experiment In-Reply-To: References: Message-ID: NANOG, This is a reminder that this experiment will resume tomorrow (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a BGP attribute of type 0xff (reserved for development) between 14:00 and 14:15 GMT. On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > > NANOG, > > We would like to inform you of an experiment to evaluate alternatives > for speeding up adoption of BGP route origin validation (research > paper with details [A]). > > Our plan is to announce prefix 184.164.224.0/24 with a valid > standards-compliant unassigned BGP attribute from routers operated by > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > development), and size 0x20 (256bits). > > Our collaborators recently ran an equivalent experiment with no > complaints or known issues [A], and so we do not anticipate any > arising. Back in 2010, an experiment using unassigned attributes by > RIPE and Duke University caused disruption in Internet routing due to > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > attributes have been assigned (BGPsec-path) and adopted (large > communities). We have successfully tested propagation of the > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > 1.6.3. > > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > predefined period of 15 minutes starting 14:30 GMT, from Monday to > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > locations [E]). We will stop the experiment immediately in case any > issues arise. > > Although we do not expect the experiment to cause disruption, we > welcome feedback on its safety and especially on how to make it safer. > We can be reached at disco-experiment at googlegroups.com. > > Amir Herzberg, University of Connecticut > Ethan Katz-Bassett, Columbia University > Haya Shulman, Fraunhofer SIT > Ítalo Cunha, Universidade Federal de Minas Gerais > Michael Schapira, Hebrew University of Jerusalem > Tomas Hlavacek, Fraunhofer SIT > Yossi Gilad, MIT > > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > [B] http://peering.usc.edu > [C] https://goo.gl/AFR1Cn > [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > [E] https://goo.gl/nJhmx1 From nanog at ics-il.net Tue Jan 22 20:43:49 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 22 Jan 2019 14:43:49 -0600 (CST) Subject: Charter Porting In-Reply-To: <346803511.9335.1547856164577.JavaMail.mhammett@ThunderFuck> References: <346803511.9335.1547856164577.JavaMail.mhammett@ThunderFuck> Message-ID: <1828815869.1916.1548189824978.JavaMail.mhammett@ThunderFuck> Today I got the form to fill out to gain access to their portal. Thanks for your help. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG" Sent: Friday, January 18, 2019 6:02:46 PM Subject: Charter Porting I first tried on VoiceOps, but didn't get any responses. Anyone have a useful contact in Charter's porting department? We've been trying to port a number for 10 days, but haven't been setup with their portal yet. The luck I'm having with the people at the e-mail address (Charter.STL.LSR at charter.com) specified in their porting instructions web site (https://www.spectrum.com/policies/local-number-portability-business-rules.html) is about as good as building a bridge out of wet noodles. Can't start the port until we have access to their portal. Can't get access to their portal until they pull their heads out. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Jan 23 08:24:22 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 22 Jan 2019 22:24:22 -1000 Subject: PREPA Message-ID: Looking for a contact/intro to Puerto Rico Power Company https://aeepr.com/ Thank you -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cunha at dcc.ufmg.br Wed Jan 23 17:19:09 2019 From: cunha at dcc.ufmg.br (Italo Cunha) Date: Wed, 23 Jan 2019 12:19:09 -0500 Subject: BGP Experiment In-Reply-To: References: Message-ID: Ben, NANOG, We have canceled this experiment permanently. On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote: > Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was > happening or why. > > Get a sandbox like every other researcher, as of now we have black holed > and filtered your whole ASN, and have reccomended others do the same. > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > >> NANOG, >> >> This is a reminder that this experiment will resume tomorrow >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> BGP attribute of type 0xff (reserved for development) between 14:00 >> and 14:15 GMT. >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: >> > >> > NANOG, >> > >> > We would like to inform you of an experiment to evaluate alternatives >> > for speeding up adoption of BGP route origin validation (research >> > paper with details [A]). >> > >> > Our plan is to announce prefix 184.164.224.0/24 with a valid >> > standards-compliant unassigned BGP attribute from routers operated by >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >> > development), and size 0x20 (256bits). >> > >> > Our collaborators recently ran an equivalent experiment with no >> > complaints or known issues [A], and so we do not anticipate any >> > arising. Back in 2010, an experiment using unassigned attributes by >> > RIPE and Duke University caused disruption in Internet routing due to >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >> > attributes have been assigned (BGPsec-path) and adopted (large >> > communities). We have successfully tested propagation of the >> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >> > 1.6.3. >> > >> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and >> > locations [E]). We will stop the experiment immediately in case any >> > issues arise. >> > >> > Although we do not expect the experiment to cause disruption, we >> > welcome feedback on its safety and especially on how to make it safer. >> > We can be reached at disco-experiment at googlegroups.com. >> > >> > Amir Herzberg, University of Connecticut >> > Ethan Katz-Bassett, Columbia University >> > Haya Shulman, Fraunhofer SIT >> > Ítalo Cunha, Universidade Federal de Minas Gerais >> > Michael Schapira, Hebrew University of Jerusalem >> > Tomas Hlavacek, Fraunhofer SIT >> > Yossi Gilad, MIT >> > >> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html >> > [B] http://peering.usc.edu >> > [C] https://goo.gl/AFR1Cn >> > [D] >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >> > [E] https://goo.gl/nJhmx1 >> > -- > Ben Cooper > Chief Executive Officer > PacketGG - Multicast > M(Telstra): 0410 411 301 > M(Optus): 0434 336 743 > E: ben at packet.gg & ben at multicast.net.au > W: https://packet.gg > W: https://multicast.net.au > > -- > You received this message because you are subscribed to the Google Groups > "DISCO Experiment" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to disco-experiment+unsubscribe at googlegroups.com. > To post to this group, send email to disco-experiment at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed Jan 23 17:40:52 2019 From: job at ntt.net (Job Snijders) Date: Wed, 23 Jan 2019 17:40:52 +0000 Subject: BGP Experiment In-Reply-To: References: Message-ID: <20190123174052.GD67948@vurt.meerval.net> Dear Ben, all, I'm not sure this experiment should be canceled. On the public Internet we MUST assume BGP speakers are compliant with the BGP-4 protocol. Broken BGP-4 speakers are what they are: broken. They must be fixed, or the operator must accept the consequences. "Get a sandbox like every other researcher" is not a fair statement, one can also posit "Get a compliant BGP-4 implementation like every other network operator". When bad guys explicitly seek to target these Asian and Australian operators you reference (who apparently have not upgraded to the vendor recommended release), using *valid* BGP updates, will a politely emailed request help resolve the situation? Of course not! Stopping the experiment is only treating symptoms, the root cause must be addressed: broken software. Kind regards, Job On Wed, Jan 23, 2019 at 12:19:09PM -0500, Italo Cunha wrote: > Ben, NANOG, > > We have canceled this experiment permanently. > > On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote: > > > Can you stop this? > > > > You caused again a massive prefix spike/flap, and as the internet is not > > centered around NA (shock horror!) a number of operators in Asia and > > Australia go effected by your “expirment” and had no idea what was > > happening or why. > > > > Get a sandbox like every other researcher, as of now we have black holed > > and filtered your whole ASN, and have reccomended others do the same. > > > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > > > >> NANOG, > >> > >> This is a reminder that this experiment will resume tomorrow > >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a > >> BGP attribute of type 0xff (reserved for development) between 14:00 > >> and 14:15 GMT. > >> > >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > >> > > >> > NANOG, > >> > > >> > We would like to inform you of an experiment to evaluate alternatives > >> > for speeding up adoption of BGP route origin validation (research > >> > paper with details [A]). > >> > > >> > Our plan is to announce prefix 184.164.224.0/24 with a valid > >> > standards-compliant unassigned BGP attribute from routers operated by > >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > >> > development), and size 0x20 (256bits). > >> > > >> > Our collaborators recently ran an equivalent experiment with no > >> > complaints or known issues [A], and so we do not anticipate any > >> > arising. Back in 2010, an experiment using unassigned attributes by > >> > RIPE and Duke University caused disruption in Internet routing due to > >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > >> > attributes have been assigned (BGPsec-path) and adopted (large > >> > communities). We have successfully tested propagation of the > >> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > >> > 1.6.3. > >> > > >> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to > >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > >> > locations [E]). We will stop the experiment immediately in case any > >> > issues arise. > >> > > >> > Although we do not expect the experiment to cause disruption, we > >> > welcome feedback on its safety and especially on how to make it safer. > >> > We can be reached at disco-experiment at googlegroups.com. > >> > > >> > Amir Herzberg, University of Connecticut > >> > Ethan Katz-Bassett, Columbia University > >> > Haya Shulman, Fraunhofer SIT > >> > Ítalo Cunha, Universidade Federal de Minas Gerais > >> > Michael Schapira, Hebrew University of Jerusalem > >> > Tomas Hlavacek, Fraunhofer SIT > >> > Yossi Gilad, MIT > >> > > >> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > >> > [B] http://peering.usc.edu > >> > [C] https://goo.gl/AFR1Cn > >> > [D] > >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > >> > [E] https://goo.gl/nJhmx1 > >> > > -- > > Ben Cooper > > Chief Executive Officer > > PacketGG - Multicast > > M(Telstra): 0410 411 301 > > M(Optus): 0434 336 743 > > E: ben at packet.gg & ben at multicast.net.au > > W: https://packet.gg > > W: https://multicast.net.au > > > > -- > > You received this message because you are subscribed to the Google Groups > > "DISCO Experiment" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to disco-experiment+unsubscribe at googlegroups.com. > > To post to this group, send email to disco-experiment at googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com > > > > . > > For more options, visit https://groups.google.com/d/optout. > > From eric.kuhnke at gmail.com Wed Jan 23 17:53:07 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 23 Jan 2019 09:53:07 -0800 Subject: BGP Experiment In-Reply-To: <20190123174052.GD67948@vurt.meerval.net> References: <20190123174052.GD67948@vurt.meerval.net> Message-ID: I would be very interested in hearing Ben's definition of something that is "massive", if announcing or withdrawing a single /24 from the global routing table constitutes, quote, "a massive prefix spike/flap". Individual /24s are moved around all the time by fully automated systems. On Wed, Jan 23, 2019 at 9:42 AM Job Snijders wrote: > Dear Ben, all, > > I'm not sure this experiment should be canceled. On the public Internet > we MUST assume BGP speakers are compliant with the BGP-4 protocol. > Broken BGP-4 speakers are what they are: broken. They must be fixed, or > the operator must accept the consequences. > > "Get a sandbox like every other researcher" is not a fair statement, one > can also posit "Get a compliant BGP-4 implementation like every other > network operator". > > When bad guys explicitly seek to target these Asian and Australian > operators you reference (who apparently have not upgraded to the vendor > recommended release), using *valid* BGP updates, will a politely emailed > request help resolve the situation? Of course not! > > Stopping the experiment is only treating symptoms, the root cause must > be addressed: broken software. > > Kind regards, > > Job > > On Wed, Jan 23, 2019 at 12:19:09PM -0500, Italo Cunha wrote: > > Ben, NANOG, > > > > We have canceled this experiment permanently. > > > > On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote: > > > > > Can you stop this? > > > > > > You caused again a massive prefix spike/flap, and as the internet is > not > > > centered around NA (shock horror!) a number of operators in Asia and > > > Australia go effected by your “expirment” and had no idea what was > > > happening or why. > > > > > > Get a sandbox like every other researcher, as of now we have black > holed > > > and filtered your whole ASN, and have reccomended others do the same. > > > > > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > > > > > >> NANOG, > > >> > > >> This is a reminder that this experiment will resume tomorrow > > >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a > > >> BGP attribute of type 0xff (reserved for development) between 14:00 > > >> and 14:15 GMT. > > >> > > >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha > wrote: > > >> > > > >> > NANOG, > > >> > > > >> > We would like to inform you of an experiment to evaluate > alternatives > > >> > for speeding up adoption of BGP route origin validation (research > > >> > paper with details [A]). > > >> > > > >> > Our plan is to announce prefix 184.164.224.0/24 with a valid > > >> > standards-compliant unassigned BGP attribute from routers operated > by > > >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > > >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > > >> > development), and size 0x20 (256bits). > > >> > > > >> > Our collaborators recently ran an equivalent experiment with no > > >> > complaints or known issues [A], and so we do not anticipate any > > >> > arising. Back in 2010, an experiment using unassigned attributes by > > >> > RIPE and Duke University caused disruption in Internet routing due > to > > >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and > other > > >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > > >> > attributes have been assigned (BGPsec-path) and adopted (large > > >> > communities). We have successfully tested propagation of the > > >> > announcements on Cisco IOS-based routers running versions > 12.2(33)SRA > > >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > > >> > 1.6.3. > > >> > > > >> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > > >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to > > >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule > and > > >> > locations [E]). We will stop the experiment immediately in case any > > >> > issues arise. > > >> > > > >> > Although we do not expect the experiment to cause disruption, we > > >> > welcome feedback on its safety and especially on how to make it > safer. > > >> > We can be reached at disco-experiment at googlegroups.com. > > >> > > > >> > Amir Herzberg, University of Connecticut > > >> > Ethan Katz-Bassett, Columbia University > > >> > Haya Shulman, Fraunhofer SIT > > >> > Ítalo Cunha, Universidade Federal de Minas Gerais > > >> > Michael Schapira, Hebrew University of Jerusalem > > >> > Tomas Hlavacek, Fraunhofer SIT > > >> > Yossi Gilad, MIT > > >> > > > >> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > > >> > [B] http://peering.usc.edu > > >> > [C] https://goo.gl/AFR1Cn > > >> > [D] > > >> > https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > > >> > [E] https://goo.gl/nJhmx1 > > >> > > > -- > > > Ben Cooper > > > Chief Executive Officer > > > PacketGG - Multicast > > > M(Telstra): 0410 411 301 > > > M(Optus): 0434 336 743 > > > E: ben at packet.gg & ben at multicast.net.au > > > W: https://packet.gg > > > W: https://multicast.net.au > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "DISCO Experiment" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an > > > email to disco-experiment+unsubscribe at googlegroups.com. > > > To post to this group, send email to disco-experiment at googlegroups.com > . > > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com > > > < > https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com?utm_medium=email&utm_source=footer > > > > > . > > > For more options, visit https://groups.google.com/d/optout. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 23 17:54:50 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 23 Jan 2019 17:54:50 +0000 Subject: BGP Experiment In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40318EF0808@MUNPRDMBXA1.medline.com> I hope you are as critical of your hardware vendor that cannot accept BGP4 compliant attributes or have you just not updated your code? You can black hole anything you want but as long as the “Internet” is sending you an RFC compliant BGP you better be able to handle it. Steven Naslund Chicago IL On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper > wrote: Can you stop this? You caused again a massive prefix spike/flap, and as the internet is not centered around NA (shock horror!) a number of operators in Asia and Australia go effected by your “expirment” and had no idea what was happening or why. Get a sandbox like every other researcher, as of now we have black holed and filtered your whole ASN, and have reccomended others do the same. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Jan 23 18:00:19 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 23 Jan 2019 21:00:19 +0300 Subject: BGP Experiment In-Reply-To: References: Message-ID: > On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote: > You caused again a massive prefix spike/flap, and as the internet is not centered around NA (shock horror!) a number of operators in Asia and Australia go effected by your “expirment” and had no idea what was happening or why. > > Get a sandbox like every other researcher The whole thing reminds me of a decades old story which can be found on Google by a search term "The Spider of Doom". What if next time e.g. the bad guys would be doing this? Would you urge them to also get a sandbox? -- Töma From aled.w.morris at googlemail.com Wed Jan 23 18:01:45 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Wed, 23 Jan 2019 18:01:45 +0000 Subject: BGP Experiment In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EF0808@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318EF0808@MUNPRDMBXA1.medline.com> Message-ID: On Wed, 23 Jan 2019 at 17:58, Naslund, Steve wrote: > I hope you are as critical of your hardware vendor that cannot accept BGP4 > compliant attributes or have you just not updated your code? You can black > hole anything you want but as long as the “Internet” is sending you an RFC > compliant BGP you better be able to handle it. > I'd go further and say that as long as you're connected to the Internet, your equipment better be resilient when receiving packets with any combination of bits set, RFC compliant or not. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Jan 23 18:08:23 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 23 Jan 2019 21:08:23 +0300 Subject: BGP Experiment In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318EF0808@MUNPRDMBXA1.medline.com> Message-ID: On Wed, Jan 23, 2019 at 9:05 PM Aled Morris via NANOG wrote: > I'd go further and say that as long as you're connected > to the Internet, your equipment better be resilient when > receiving packets with any combination of bits set, > RFC compliant or not. Well, here, when you receive this particular attribute and if you're vulnerable, your equipment automatically gets disconnected from the Internet, so the issue kinda solves itself. -- Töma From nick at foobar.org Wed Jan 23 18:12:46 2019 From: nick at foobar.org (Nick Hilliard) Date: Wed, 23 Jan 2019 18:12:46 +0000 Subject: BGP Experiment In-Reply-To: References: Message-ID: Töma Gavrichenkov wrote on 23/01/2019 18:00: > What if next time e.g. the bad guys would be doing this? Would you > urge them to also get a sandbox? Send them a strongly worded memo. If that doesn't work, threaten to send them a second. Nick From fhr at fhrnet.eu Wed Jan 23 18:16:31 2019 From: fhr at fhrnet.eu (Filip Hruska) Date: Wed, 23 Jan 2019 18:16:31 +0000 Subject: BGP Experiment In-Reply-To: References: Message-ID: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> This experiment should be continued. It's the only way to get people to patch stuff. And if all it takes to break things is a single announcement, than that's something that should be definitely fixed. Blacklisting an ASN is not a solution, that's ignorance. Regards, Filip Hruska On 23 January 2019 18:19:09 CET, Italo Cunha wrote: >Ben, NANOG, > >We have canceled this experiment permanently. > >On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote: > >> Can you stop this? >> >> You caused again a massive prefix spike/flap, and as the internet is >not >> centered around NA (shock horror!) a number of operators in Asia and >> Australia go effected by your “expirment” and had no idea what was >> happening or why. >> >> Get a sandbox like every other researcher, as of now we have black >holed >> and filtered your whole ASN, and have reccomended others do the same. >> >> On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha >wrote: >> >>> NANOG, >>> >>> This is a reminder that this experiment will resume tomorrow >>> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >>> BGP attribute of type 0xff (reserved for development) between 14:00 >>> and 14:15 GMT. >>> >>> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha >wrote: >>> > >>> > NANOG, >>> > >>> > We would like to inform you of an experiment to evaluate >alternatives >>> > for speeding up adoption of BGP route origin validation (research >>> > paper with details [A]). >>> > >>> > Our plan is to announce prefix 184.164.224.0/24 with a valid >>> > standards-compliant unassigned BGP attribute from routers operated >by >>> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 >>> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >>> > development), and size 0x20 (256bits). >>> > >>> > Our collaborators recently ran an equivalent experiment with no >>> > complaints or known issues [A], and so we do not anticipate any >>> > arising. Back in 2010, an experiment using unassigned attributes >by >>> > RIPE and Duke University caused disruption in Internet routing due >to >>> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and >other >>> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >>> > attributes have been assigned (BGPsec-path) and adopted (large >>> > communities). We have successfully tested propagation of the >>> > announcements on Cisco IOS-based routers running versions >12.2(33)SRA >>> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 >and >>> > 1.6.3. >>> > >>> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for >a >>> > predefined period of 15 minutes starting 14:30 GMT, from Monday to >>> > Thursday, between the 7th and 22nd of January, 2019 (full schedule >and >>> > locations [E]). We will stop the experiment immediately in case >any >>> > issues arise. >>> > >>> > Although we do not expect the experiment to cause disruption, we >>> > welcome feedback on its safety and especially on how to make it >safer. >>> > We can be reached at disco-experiment at googlegroups.com. >>> > >>> > Amir Herzberg, University of Connecticut >>> > Ethan Katz-Bassett, Columbia University >>> > Haya Shulman, Fraunhofer SIT >>> > Ítalo Cunha, Universidade Federal de Minas Gerais >>> > Michael Schapira, Hebrew University of Jerusalem >>> > Tomas Hlavacek, Fraunhofer SIT >>> > Yossi Gilad, MIT >>> > >>> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html >>> > [B] http://peering.usc.edu >>> > [C] https://goo.gl/AFR1Cn >>> > [D] >>> >https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >>> > [E] https://goo.gl/nJhmx1 >>> >> -- >> Ben Cooper >> Chief Executive Officer >> PacketGG - Multicast >> M(Telstra): 0410 411 301 >> M(Optus): 0434 336 743 >> E: ben at packet.gg & ben at multicast.net.au >> W: https://packet.gg >> W: https://multicast.net.au >> >> -- >> You received this message because you are subscribed to the Google >Groups >> "DISCO Experiment" group. >> To unsubscribe from this group and stop receiving emails from it, >send an >> email to disco-experiment+unsubscribe at googlegroups.com. >> To post to this group, send email to >disco-experiment at googlegroups.com. >> To view this discussion on the web visit >> >https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com >> > >> . >> For more options, visit https://groups.google.com/d/optout. >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 23 18:27:40 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 23 Jan 2019 18:27:40 +0000 Subject: BGP Experiment In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40318EF0808@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EF08A6@MUNPRDMBXA1.medline.com> Contact your hardware vendor. That is not acceptable behavior. If it is not RFC compliant they need to accept the attribute, if it's not RFC compliant they should gracefully ignore it. Now we all know that anyone using that gear is vulnerable to a DoS attack. Won't be long until anyone else sends that to you. Steven Naslund Chicago IL >Well, here, when you receive this particular attribute and if you're vulnerable, your equipment automatically gets disconnected from the Internet, so the issue kinda solves >itself. > >-- >Töma From SNaslund at medline.com Wed Jan 23 18:30:28 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 23 Jan 2019 18:30:28 +0000 Subject: BGP Experiment In-Reply-To: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> References: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EF08BA@MUNPRDMBXA1.medline.com> Agreed, do you think you will not see that attribute again now that the public knows that you are vulnerable to this DoS method. Expect to see an attack based on this method shortly. They just did you a favor by exposing your vulnerability, you should take it as such. I would be putting in emergency patches tonight if available. Steven Naslund Chicago IL >This experiment should be continued. > >It's the only way to get people to patch stuff. >And if all it takes to break things is a single announcement, than that's something that should be definitely fixed. > >Blacklisting an ASN is not a solution, that's ignorance. > >Regards, >Filip Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 23 18:32:01 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 23 Jan 2019 18:32:01 +0000 Subject: BGP Experiment In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EF08A6@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40318EF0808@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40318EF08A6@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EF08CC@MUNPRDMBXA1.medline.com> Sorry. Correction. If it IS RFC compliant they should accept the attribute. If it is NOT, they should drop (and maybe log it). Steve >Contact your hardware vendor. That is not acceptable behavior. If it is not RFC compliant they need to accept the attribute, if it's not RFC compliant they should gracefully >ignore it. Now we all know that anyone using that gear is vulnerable to a DoS attack. Won't be long until anyone else sends that to you. >Steven Naslund >Chicago IL From christoffer at netravnen.de Wed Jan 23 18:32:15 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Wed, 23 Jan 2019 19:32:15 +0100 Subject: BGP Experiment In-Reply-To: References: Message-ID: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> On 23/01/2019 18:19, Italo Cunha wrote: > We have canceled this experiment permanently. Sad to hear! :/ My impression if you continue is more users will get aware of bugs with running BGP implementations. Not all follow announcement from $vendor and will continue to run older broken code and complain to $vendor about errors with the software. From nik at neko.id.au Wed Jan 23 18:45:50 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Wed, 23 Jan 2019 18:45:50 +0000 Subject: BGP Experiment In-Reply-To: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> References: , <39754390-827e-1094-5486-447c5151ac47@netravnen.de> Message-ID: <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> Throwing my support behind continuing the experiment also. A singular complaint from a company advertising unallocated ASN and IPv4 resources (the irony) does not warrant cessation of the experiment. The experiment is in compliance with the relevant RFCs, the affected “vendor” has released fixed software and announced it to their notifications list. I can only hope this and future research continues. > On Jan 23, 2019, at 1:39 PM, Christoffer Hansen wrote: > > >> On 23/01/2019 18:19, Italo Cunha wrote: >> We have canceled this experiment permanently. > > Sad to hear! :/ > > My impression if you continue is more users will get aware of bugs with > running BGP implementations. Not all follow announcement from $vendor > and will continue to run older broken code and complain to $vendor about > errors with the software. From christoffer at netravnen.de Wed Jan 23 18:57:27 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Wed, 23 Jan 2019 19:57:27 +0100 Subject: BGP Experiment In-Reply-To: References: Message-ID: <4739f0c8-3961-bb28-c4b7-82c1b36cbce1@netravnen.de> > On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote: > >> Can you stop this? >> >> You caused again a massive prefix spike/flap, and as the internet is not >> centered around NA (shock horror!) a number of operators in Asia and >> Australia go effected by your “expirment” and had no idea what was >> happening or why. You could(?) be helpful by propagating the announcement to other $lists or point out to the authors they are not spreading their announcements about the experiment wide enough. >> Get a sandbox like every other researcher, as of now we have black holed >> and filtered your whole ASN, and have reccomended others do the same. Probably the previous sent announcement about the prefix announcements sent out today. Should have gone to more mailing lists at RIRs and NOGs. (Encountered a FRR user today, too. Who had missed previous announcements) -Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From james.jun at towardex.com Wed Jan 23 19:01:46 2019 From: james.jun at towardex.com (James Jun) Date: Wed, 23 Jan 2019 14:01:46 -0500 Subject: BGP Experiment In-Reply-To: <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> Message-ID: <20190123190146.GA74032@mis10.towardex.com> On Wed, Jan 23, 2019 at 06:45:50PM +0000, Nikolas Geyer wrote: > Throwing my support behind continuing the experiment also. A singular complaint from a company advertising unallocated ASN and IPv4 resources (the irony) does not warrant cessation of the experiment. Agreed; Please resume the experiment. We're all operators here, and we MUST have confidence that BGP speakers on our network are compliant with protocol specification. Experiments like this are opportunities for a real-life validation of how our devices handle messages that are out of the norm, and help us identify issues. Kudos to researchers by the way, for sending courtesy announcements in advance, and testing against some common platforms available to them (Cisco, Quagga & BIRD) prior to the experiment. James From christoffer at netravnen.de Wed Jan 23 19:12:34 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Wed, 23 Jan 2019 20:12:34 +0100 Subject: BGP Experiment In-Reply-To: <20190123190146.GA74032@mis10.towardex.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> Message-ID: On 23/01/2019 20:01, James Jun wrote: > Kudos to researchers by the way, for sending courtesy announcements in advance, and testing > against some common platforms available to them (Cisco, Quagga & BIRD) prior to the experiment. On 18/12/2018 16:05, Italo Cunha wrote: > We have successfully tested propagation of the > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > 1.6.3. If tests was done _only_ Quagga, BIRD, Cisco IOS... I can only conclude a limited set has been done. (But then again, $_vendors and $_versions of $_software cannot be counted in small numbers.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From astephens at ptera.com Wed Jan 23 21:06:16 2019 From: astephens at ptera.com (Art Stephens) Date: Wed, 23 Jan 2019 13:06:16 -0800 Subject: IPv6 NAT64 Message-ID: I know this might be off topic but hopefully not too far off. I heard rumors that there are ISPs out there running IPv6 only networks where the clients can still get to the IPv4 world without the $30,000 plus dollar expense of buying a NAT64 appliance to service 4,000 plus customers. Anyone have some insight into this? -- Arthur Stephens Senior Network Administrator Ptera Inc. PO Box 135 24001 E Mission Suite 50 Liberty Lake, WA 99019 509-927-7837 ptera.com | facebook.com/PteraInc | twitter.com/Ptera ----------------------------------------------------------------------------- "This message may contain confidential and/or propriety information, and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company." From lists.nanog at monmotha.net Wed Jan 23 21:21:44 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 23 Jan 2019 16:21:44 -0500 Subject: IPv6 NAT64 In-Reply-To: References: Message-ID: <0cf79bf1-5e79-8fa9-a6ec-586699340517@monmotha.net> On 1/23/19 4:06 PM, Art Stephens wrote: > I know this might be off topic but hopefully not too far off. > I heard rumors that there are ISPs out there running IPv6 only > networks where the clients can still get to the IPv4 world without the > $30,000 plus dollar expense of buying a NAT64 appliance to service > 4,000 plus customers. > Anyone have some insight into this? Look into stateless transition mechanisms like LW4o6 or MAP. You can push a few 10s of Gbps through a relatively modest PC with these and the right software. Eventually somebody will hopefully add them to the relevant router software. Since they're stateless, most of the common "match and manipulate" type packet pusher ASICs can presumably do it. It's not much different than an IPv6-over-IPv4 tunnel or MPLS switching in that respect. -- Brandon Martin From cb.list6 at gmail.com Wed Jan 23 21:54:20 2019 From: cb.list6 at gmail.com (Ca By) Date: Wed, 23 Jan 2019 13:54:20 -0800 Subject: IPv6 NAT64 In-Reply-To: References: Message-ID: On Wed, Jan 23, 2019 at 1:08 PM Art Stephens wrote: > I know this might be off topic but hopefully not too far off. > I heard rumors that there are ISPs out there running IPv6 only > networks where the clients can still get to the IPv4 world without the > $30,000 plus dollar expense of buying a NAT64 appliance to service > 4,000 plus customers. > Anyone have some insight into this? 1. For many networks where youtube, netflix, and fb dominate, most traffic will run ipv6 end to end. 2. For nat64, opensource dns64 and nat64 are available and mature https://www.jool.mx/en/index.html > > -- > Arthur Stephens > Senior Network Administrator > Ptera Inc. > PO Box 135 > 24001 E Mission Suite 50 > Liberty Lake, WA 99019 > 509-927-7837 > ptera.com | > facebook.com/PteraInc | twitter.com/Ptera > > ----------------------------------------------------------------------------- > "This message may contain confidential and/or propriety information, > and is intended for the person/entity to whom it was originally > addressed. > Any use by others is strictly prohibited. Please note that any views > or opinions presented in this email are solely those of the author and > are not intended to represent those of the company." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jan 23 23:46:46 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Jan 2019 15:46:46 -0800 Subject: BGP Experiment In-Reply-To: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> References: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> Message-ID: > On Jan 23, 2019, at 10:16 , Filip Hruska wrote: > > This experiment should be continued. > > It's the only way to get people to patch stuff. > And if all it takes to break things is a single announcement, than that's something that should be definitely fixed. > > Blacklisting an ASN is not a solution, that's ignorance. Actually, at the point where you blacklist the ASN, you’ve moved from ignorance to willful ignorance (aka stupidity). Owen From Brian at ampr.org Thu Jan 24 00:10:38 2019 From: Brian at ampr.org (Brian Kantor) Date: Wed, 23 Jan 2019 16:10:38 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 Message-ID: <20190124001038.GH98649@meow.BKantor.net> Quoting from the web site at https://dnsflagday.net/ What is happening? The current DNS is unnecessarily slow and suffers from inability to deploy new features. To remediate these problems, vendors of DNS software and also big public DNS providers are going to remove certain workarounds on February 1st, 2019. This change affects only sites which operate software which is not following published standards. Are you affected? On that web page, there is a Domain Owner's test. You can enter a domain name and click 'test' and shortly receive a report of what was found regarding your domain's DNS servers. I somehow managed to miss the announcement of this upcoming event, even though I read this mailing list fairly closely. Perhaps it was announced somewhere else instead. I think it needs to be mentioned here if it hasn't already been. - Brian From contact at winterei.se Thu Jan 24 00:22:48 2019 From: contact at winterei.se (Paul S.) Date: Thu, 24 Jan 2019 09:22:48 +0900 Subject: BGP Experiment In-Reply-To: References: Message-ID: Replying to throw in my support behind continuing the experiment as well. Assurance that my gear will NOT fall over under adversarial situations is paramount, thank you for the research that you're doing to ensure that. Ben, you may wish to re-evaluate how "rock solid" [1] your networking truly is if you're being taken down by random BGP updates. As others have noted, the right target to be angry at is your equipment vendor. [1]: https://packet.gg/ On 1/24/2019 02:19 午前, Italo Cunha wrote: > Ben, NANOG, > > We have canceled this experiment permanently. > > On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper > wrote: > > Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet > is not centered around NA (shock horror!) a number of operators in > Asia and Australia go effected by your “expirment” and had no idea > what was happening or why. > > Get a sandbox like every other researcher, as of now we have black > holed and filtered your whole ASN, and have reccomended others do > the same. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 24 00:22:44 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 11:22:44 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <20190124001038.GH98649@meow.BKantor.net> References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> I’ve been complaining for YEARS about lack of EDNS compliance. If you run really old Windows DNS servers you are broken. If you run a firewall in front of your DNS server you may be broken. If you are QWEST you are broken. Mark > On 24 Jan 2019, at 11:10 am, Brian Kantor wrote: > > Quoting from the web site at https://dnsflagday.net/ > > What is happening? > > The current DNS is unnecessarily slow and suffers from inability > to deploy new features. To remediate these problems, vendors of > DNS software and also big public DNS providers are going to > remove certain workarounds on February 1st, 2019. > > This change affects only sites which operate software which is > not following published standards. Are you affected? > > On that web page, there is a Domain Owner's test. You can enter > a domain name and click 'test' and shortly receive a report of > what was found regarding your domain's DNS servers. > > I somehow managed to miss the announcement of this upcoming event, > even though I read this mailing list fairly closely. Perhaps it > was announced somewhere else instead. I think it needs to be > mentioned here if it hasn't already been. > - Brian > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From ximaera at gmail.com Thu Jan 24 01:27:36 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 24 Jan 2019 04:27:36 +0300 Subject: BGP Experiment In-Reply-To: References: Message-ID: On Thu, Jan 24, 2019 at 3:23 AM Paul S. wrote: > As others have noted, the right target to be angry at is your > equipment vendor. ...whose name I'd personally be quite delighted to finally hear. Is it just the same FRR that got a patch someone failed to apply, or this time the issue is more serious? > Replying to throw in my support behind continuing the experiment as well. +1. I've yet to see any disruptions caused by the experiment in my area. -- Töma From mark.tinka at seacom.mu Thu Jan 24 02:31:02 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 24 Jan 2019 04:31:02 +0200 Subject: BGP Experiment In-Reply-To: <20190123190146.GA74032@mis10.towardex.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> Message-ID: <43a33a0c-6b42-3922-5ed7-1710f69812be@seacom.mu> On 23/Jan/19 21:01, James Jun wrote: > Agreed; Please resume the experiment. We're all operators here, and we MUST have confidence > that BGP speakers on our network are compliant with protocol specification. Experiments like > this are opportunities for a real-life validation of how our devices handle messages that are > out of the norm, and help us identify issues. > > Kudos to researchers by the way, for sending courtesy announcements in advance, and testing > against some common platforms available to them (Cisco, Quagga & BIRD) prior to the experiment. +1. Mark. From morrowc.lists at gmail.com Thu Jan 24 04:35:16 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Jan 2019 23:35:16 -0500 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <20190124001038.GH98649@meow.BKantor.net> References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > Quoting from the web site at https://dnsflagday.net/ > > huh, from the 'dns illuminati' eh" DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in github's ip space, routed by fastly.com ... I'm sure glad the whois data for that domain is sensible too... :( none of that particularly leaves me feeling like I should go put any data at all into the site. -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 24 04:44:56 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 15:44:56 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here” which is what https://dnsflagday.net calls behind the scenes. You will just need to interpret the results as they apply to DNS flag day. If you don’t want to go there you can go to https://gitlab.isc.org and down load and compile the DNS compliance tester and then run “genreport -i bind11 -e”. which is the actual test code being run. But hey you did do proper acceptance testing when you installed your DNS servers and firewalls to ensure that they implemented the DNS protocol correctly and they your firewalls don’t block well formed DNS queries (lots of them do by default). Mark > On 24 Jan 2019, at 3:35 pm, Christopher Morrow wrote: > > > > On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > Quoting from the web site at https://dnsflagday.net/ > > > huh, from the 'dns illuminati' eh" > > DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in github's ip space, routed by fastly.com ... > I'm sure glad the whois data for that domain is sensible too... :( > > none of that particularly leaves me feeling like I should go put any data at all into the site. > > -chris -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Thu Jan 24 04:51:40 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Jan 2019 23:51:40 -0500 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: > Well you can go to https://ednscomp.isc.org and click on "Test Your > Servers Here” > which is what https://dnsflagday.net calls behind the scenes. You will > just need > to interpret the results as they apply to DNS flag day. If you don’t want > to go > there you can go to https://gitlab.isc.org and down load and compile the > DNS > compliance tester and then run “genreport -i bind11 -e”. which is the > actual test > code being run. > > oh excellent, I'll do this version. thanks. > But hey you did do proper acceptance testing when you installed your DNS > servers > and firewalls to ensure that they implemented the DNS protocol correctly > and they > your firewalls don’t block well formed DNS queries (lots of them do by > default). > > I did, yes. > Mark > > > On 24 Jan 2019, at 3:35 pm, Christopher Morrow > wrote: > > > > > > > > On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > > Quoting from the web site at https://dnsflagday.net/ > > > > > > huh, from the 'dns illuminati' eh" > > > > DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in > github's ip space, routed by fastly.com ... > > I'm sure glad the whois data for that domain is sensible too... :( > > > > none of that particularly leaves me feeling like I should go put any > data at all into the site. > > > > -chris > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 24 05:32:58 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 16:32:58 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> Also as a lot of you use F5 servers here is information about DNS flag day fixes. https://support.f5.com/csp/article/K07808381?sf206085287=1 > On 24 Jan 2019, at 3:51 pm, Christopher Morrow wrote: > > > > On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: > Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here” > which is what https://dnsflagday.net calls behind the scenes. You will just need > to interpret the results as they apply to DNS flag day. If you don’t want to go > there you can go to https://gitlab.isc.org and down load and compile the DNS > compliance tester and then run “genreport -i bind11 -e”. which is the actual test > code being run. > > > oh excellent, I'll do this version. thanks. > > But hey you did do proper acceptance testing when you installed your DNS servers > and firewalls to ensure that they implemented the DNS protocol correctly and they > your firewalls don’t block well formed DNS queries (lots of them do by default). > > > I did, yes. > > Mark > > > On 24 Jan 2019, at 3:35 pm, Christopher Morrow wrote: > > > > > > > > On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > > Quoting from the web site at https://dnsflagday.net/ > > > > > > huh, from the 'dns illuminati' eh" > > > > DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in github's ip space, routed by fastly.com ... > > I'm sure glad the whois data for that domain is sensible too... :( > > > > none of that particularly leaves me feeling like I should go put any data at all into the site. > > > > -chris > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jan 24 05:35:52 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 16:35:52 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> Message-ID: <08284E1B-E373-4793-BE4D-DCE3F4DD89F2@isc.org> And if you don’t want to go to the web site you can still see the content here https://github.com/dns-violations/dnsflagday > On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote: > > Also as a lot of you use F5 servers here is information about DNS flag day > fixes. > > https://support.f5.com/csp/article/K07808381?sf206085287=1 > >> On 24 Jan 2019, at 3:51 pm, Christopher Morrow wrote: >> >> >> >> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: >> Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here” >> which is what https://dnsflagday.net calls behind the scenes. You will just need >> to interpret the results as they apply to DNS flag day. If you don’t want to go >> there you can go to https://gitlab.isc.org and down load and compile the DNS >> compliance tester and then run “genreport -i bind11 -e”. which is the actual test >> code being run. >> >> >> oh excellent, I'll do this version. thanks. >> >> But hey you did do proper acceptance testing when you installed your DNS servers >> and firewalls to ensure that they implemented the DNS protocol correctly and they >> your firewalls don’t block well formed DNS queries (lots of them do by default). >> >> >> I did, yes. >> >> Mark >> >>> On 24 Jan 2019, at 3:35 pm, Christopher Morrow wrote: >>> >>> >>> >>> On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: >>> Quoting from the web site at https://dnsflagday.net/ >>> >>> >>> huh, from the 'dns illuminati' eh" >>> >>> DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in github's ip space, routed by fastly.com ... >>> I'm sure glad the whois data for that domain is sensible too... :( >>> >>> none of that particularly leaves me feeling like I should go put any data at all into the site. >>> >>> -chris >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Thu Jan 24 05:45:42 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Jan 2019 00:45:42 -0500 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <08284E1B-E373-4793-BE4D-DCE3F4DD89F2@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> <08284E1B-E373-4793-BE4D-DCE3F4DD89F2@isc.org> Message-ID: On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote: > And if you don’t want to go to the web site you can still see the content > here > > https://github.com/dns-violations/dnsflagday > > I think part of my snark was lost as snark here... So, we're asking 'everyone' to do 'something' on behalf of their domains, their users and the rest of the internet... we can't seem to do that in a fashion that's traceable, clearly has ownership and doesn't look like every halfbaked spam campaign in the world. Yes I could go digging for the right starting point at ISC or github or .. what?? Why wasn't this pretty clearly owned by 'ICANN' or some organization like that? It's lovely that github, fastly, gandi and ISC want to help, but... somewhere here some legitimacy could have been injected into the process, right? "HI, we're ICANN we do dns thingies, and we'd like to help make you make things better. Please use the website (provided by our partner(s) X, Y, Z to do the following A, B, C things, and get guidance on repair for problems at site FOO, BAR or BAZ. If there are questions please see our FAQ ( https://www.icann.org/dnsfixin/faq) or email . Thanks for taking the time to make the world better?" it's not super hard to do this, it's also apparently super easy to look like a spam/malware campaign. > > On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote: > > > > Also as a lot of you use F5 servers here is information about DNS flag > day > > fixes. > > > > https://support.f5.com/csp/article/K07808381?sf206085287=1 > > > >> On 24 Jan 2019, at 3:51 pm, Christopher Morrow > wrote: > >> > >> > >> > >> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: > >> Well you can go to https://ednscomp.isc.org and click on "Test Your > Servers Here” > >> which is what https://dnsflagday.net calls behind the scenes. You > will just need > >> to interpret the results as they apply to DNS flag day. If you don’t > want to go > >> there you can go to https://gitlab.isc.org and down load and compile > the DNS > >> compliance tester and then run “genreport -i bind11 -e”. which is the > actual test > >> code being run. > >> > >> > >> oh excellent, I'll do this version. thanks. > >> > >> But hey you did do proper acceptance testing when you installed your > DNS servers > >> and firewalls to ensure that they implemented the DNS protocol > correctly and they > >> your firewalls don’t block well formed DNS queries (lots of them do by > default). > >> > >> > >> I did, yes. > >> > >> Mark > >> > >>> On 24 Jan 2019, at 3:35 pm, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >>> > >>> > >>> > >>> On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > >>> Quoting from the web site at https://dnsflagday.net/ > >>> > >>> > >>> huh, from the 'dns illuminati' eh" > >>> > >>> DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in > github's ip space, routed by fastly.com ... > >>> I'm sure glad the whois data for that domain is sensible too... :( > >>> > >>> none of that particularly leaves me feeling like I should go put any > data at all into the site. > >>> > >>> -chris > >> > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > >> > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Jan 23 19:19:55 2019 From: bill at herrin.us (William Herrin) Date: Wed, 23 Jan 2019 11:19:55 -0800 Subject: BGP Experiment In-Reply-To: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> References: <010201687bed897d-262df32a-65ce-4df7-9ae1-ffc5483e49d9-000000@eu-west-1.amazonses.com> Message-ID: On Wed, Jan 23, 2019 at 10:16 AM Filip Hruska wrote: > This experiment should be continued. > It's the only way to get people to patch stuff. Agreed. But be gentle. Wait a couple months between repeats to give folks a generous amount of time to patch their gear. If you create the emergency that a hacker could but hasn't, you've done the hacker's job for him. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From marka at isc.org Thu Jan 24 06:09:38 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 17:09:38 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> <08284E1B-E373-4793-BE4D-DCE3F4DD89F2@isc.org> Message-ID: > On 24 Jan 2019, at 4:45 pm, Christopher Morrow wrote: > > > > On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote: > And if you don’t want to go to the web site you can still see the content here > > https://github.com/dns-violations/dnsflagday > > > I think part of my snark was lost as snark here... > So, we're asking 'everyone' to do 'something' on behalf of their domains, their users and the rest of the internet... we can't seem to do that in a fashion that's traceable, clearly has ownership and doesn't look like every halfbaked spam campaign in the world. > > Yes I could go digging for the right starting point at ISC or github or .. what?? > Why wasn't this pretty clearly owned by 'ICANN' or some organization like that? Well the IETF doesn’t want to be “Protocol Police”. ICANN has enforced this on gTLD operators as they are contractually obligated to run protocol compliant servers. Almost all of the ccTLD servers are fixed as well. https://ednscomp.isc.org/compliance/ts/tld-graphs.html https://ednscomp.isc.org/compliance/tld-report.html I’ve argued for years that TLD operators should be doing tests like this on all delegated domains and delisting them until they have fixed the server after a initial grace period with multiple warnings. They are in a position to send warning to operators and owners of delegated zones. They just say “this is not our job” despite RFC 1033 actually listing removal of delegation as something that should be done by the parent zone (TLD) if other methods of fixing servers that don’t follow the specification fail. No one wanted own this. This is Open Source DNS vendors saying "Enough is Enough”. We are tired of having to write workarounds for all the broken servers out there especially as those workarounds impacts on sites that have protocol compliant servers. None of use could move alone as we would get “But it works with …”. This needed to be a collective move. The public DNS resolver operators are also on board. No system works if there are not checks and balances in place. The DNS still doesn’t have checks and balances in place. Mark > It's lovely that github, fastly, gandi and ISC want to help, but... somewhere here some legitimacy could have been injected into the process, right? > > "HI, we're ICANN we do dns thingies, and we'd like to help make you make things better. Please use the website (provided by our partner(s) X, Y, Z to do the following A, B, C things, and get guidance on repair for problems at site FOO, BAR or BAZ. If there are questions please see our FAQ (https://www.icann.org/dnsfixin/faq) or email . Thanks for taking the time to make the world better?" > > it's not super hard to do this, it's also apparently super easy to look like a spam/malware campaign. > > > On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote: > > > > Also as a lot of you use F5 servers here is information about DNS flag day > > fixes. > > > > https://support.f5.com/csp/article/K07808381?sf206085287=1 > > > >> On 24 Jan 2019, at 3:51 pm, Christopher Morrow wrote: > >> > >> > >> > >> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: > >> Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here” > >> which is what https://dnsflagday.net calls behind the scenes. You will just need > >> to interpret the results as they apply to DNS flag day. If you don’t want to go > >> there you can go to https://gitlab.isc.org and down load and compile the DNS > >> compliance tester and then run “genreport -i bind11 -e”. which is the actual test > >> code being run. > >> > >> > >> oh excellent, I'll do this version. thanks. > >> > >> But hey you did do proper acceptance testing when you installed your DNS servers > >> and firewalls to ensure that they implemented the DNS protocol correctly and they > >> your firewalls don’t block well formed DNS queries (lots of them do by default). > >> > >> > >> I did, yes. > >> > >> Mark > >> > >>> On 24 Jan 2019, at 3:35 pm, Christopher Morrow wrote: > >>> > >>> > >>> > >>> On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > >>> Quoting from the web site at https://dnsflagday.net/ > >>> > >>> > >>> huh, from the 'dns illuminati' eh" > >>> > >>> DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in github's ip space, routed by fastly.com ... > >>> I'm sure glad the whois data for that domain is sensible too... :( > >>> > >>> none of that particularly leaves me feeling like I should go put any data at all into the site. > >>> > >>> -chris > >> > >> -- > >> Mark Andrews, ISC > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > >> > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Wed Jan 23 22:29:18 2019 From: bill at herrin.us (William Herrin) Date: Wed, 23 Jan 2019 14:29:18 -0800 Subject: IPv6 NAT64 In-Reply-To: References: Message-ID: On Wed, Jan 23, 2019 at 1:06 PM Art Stephens wrote: > I know this might be off topic but hopefully not too far off. > I heard rumors that there are ISPs out there running IPv6 only > networks where the clients can still get to the IPv4 world without the > $30,000 plus dollar expense of buying a NAT64 appliance to service > 4,000 plus customers. > Anyone have some insight into this? Hi Art, Less ISPs than mobile carriers (e.g. T-Mobile) where the operator has substantial control over the subscriber's CPE and can require the presence of a CLAT client for 464XLAT. The key challenge (and key cost driver) with v6-only eyeball networks is the wealth of obsolete v4-only client software your customers use that might, if you're lucky, dribble away over the next few decades. Useful references: ftp://ftp.registro.br/pub/gter/gter43/06-ipv6-464xlat-residencial.pdf http://www.litech.org/tayga/ Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mike.meredith at port.ac.uk Thu Jan 24 10:02:18 2019 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Thu, 24 Jan 2019 10:02:18 +0000 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> Message-ID: <20190124100218.3d60c6d2@scrofula.eps.is.port.ac.uk> On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews may have written: > If you run a firewall in front of your DNS server you may be broken. If you run a firewall in front of your DNS server and the firewall breaks EDNS, then your firewall is broken. And has been a long, long time. I put a firewall in place back in 2004, and EDNS compliance was one of the tests back then. -- Mike Meredith, University of Portsmouth Chief Systems Engineer, Hostmaster, Security, and Timelord! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From niels=nanog at bakker.net Thu Jan 24 11:04:10 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 24 Jan 2019 12:04:10 +0100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> <08284E1B-E373-4793-BE4D-DCE3F4DD89F2@isc.org> Message-ID: <20190124110410.GA45327@jima.tpb.net> * morrowc.lists at gmail.com (Christopher Morrow) [Thu 24 Jan 2019, 06:46 CET]: >So, we're asking 'everyone' to do 'something' on behalf of their >domains, their users and the rest of the internet... we can't seem >to do that in a fashion that's traceable, clearly has ownership and >doesn't look like every halfbaked spam campaign in the world. Do those link to presentations given at major industry conferences like RIPE and DNS-OARC, with well known industry people getting on stage to talk about it? What more do you need? More recent additions, mayhaps? UKNOF? https://www.youtube.com/watch?v=e4KdsexpB7Q LACNIC? https://www.youtube.com/watch?v=_hCGucH0kRU SDNOG? https://www.youtube.com/watch?v=UksQZkxOC-Q Oh wait, you had to scroll down on the main dnsflagday.net page to see those links, which in this day of only the first page of Google results mattering, isn't going to happen, apparently. -- Niels. From marka at isc.org Thu Jan 24 11:13:10 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 22:13:10 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <20190124100218.3d60c6d2@scrofula.eps.is.port.ac.uk> References: <20190124001038.GH98649@meow.BKantor.net> <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> <20190124100218.3d60c6d2@scrofula.eps.is.port.ac.uk> Message-ID: <3CFF25F5-1A8D-450F-A54F-A2CBF68D53D3@isc.org> > On 24 Jan 2019, at 9:02 pm, Mike Meredith wrote: > > On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews may have > written: >> If you run a firewall in front of your DNS server you may be broken. > > If you run a firewall in front of your DNS server and the firewall breaks > EDNS, then your firewall is broken. And has been a long, long time. I put a > firewall in place back in 2004, and EDNS compliance was one of the tests > back then. EDNS usage has changed since them. Back in 2004 there was zero use of EDNS options in queries. That is no longer true. NSID (RFC 5001) the first option to make it into main stream code was allocated in 2007 and that saw occasional use. DNS COOKIE has been in every query named has emitted since BIND 9.11.0 and in late BIND 9.10 versions. Lots of firewalls still reject it. > -- > Mike Meredith, University of Portsmouth > Chief Systems Engineer, Hostmaster, Security, and Timelord! > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jan 24 12:46:09 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Jan 2019 23:46:09 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <3CFF25F5-1A8D-450F-A54F-A2CBF68D53D3@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> <20190124100218.3d60c6d2@scrofula.eps.is.port.ac.uk> <3CFF25F5-1A8D-450F-A54F-A2CBF68D53D3@isc.org> Message-ID: We see Juniper firewalls blocking EDNS(1) and NSID by default. We see Checkpoint firewalls blocking EDNS(1) and EDNS flags by default. There is a another vendor that blocks EDNS(1). Juniper and Checkpoint have newer code that doesn’t do this. The old firewalls are still out there however. You can see them easily when you are doing bulk testing and mark timeouts in a different colour. Please go look at the reports on https://ednscomp.isc.org to see how obvious they are. There were times in the last 4 years where over 50% of the tested servers were dropping EDNS(1) queries. With drop rates like that you limited the ability of the IETF to use EDNS(1) to fix issues with EDNS correctly. The RFC 6891 would have included a version bump except for these stupid firewalls. The clarification of unknown EDNS option behaviour warranted a version bump. Blocking any of the extension mechanisms (version, flag or option) isn’t doing anyone any benefit. If you have a firewall that does it please FIX IT. > On 24 Jan 2019, at 10:13 pm, Mark Andrews wrote: > > > >> On 24 Jan 2019, at 9:02 pm, Mike Meredith wrote: >> >> On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews may have >> written: >>> If you run a firewall in front of your DNS server you may be broken. >> >> If you run a firewall in front of your DNS server and the firewall breaks >> EDNS, then your firewall is broken. And has been a long, long time. I put a >> firewall in place back in 2004, and EDNS compliance was one of the tests >> back then. > > EDNS usage has changed since them. Back in 2004 there was zero use of EDNS > options in queries. That is no longer true. NSID (RFC 5001) the first option > to make it into main stream code was allocated in 2007 and that saw occasional > use. DNS COOKIE has been in every query named has emitted since BIND 9.11.0 and > in late BIND 9.10 versions. Lots of firewalls still reject it. > >> -- >> Mike Meredith, University of Portsmouth >> Chief Systems Engineer, Hostmaster, Security, and Timelord! >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bjorn at mork.no Thu Jan 24 13:50:32 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 24 Jan 2019 14:50:32 +0100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> (Mark Andrews's message of "Thu, 24 Jan 2019 11:22:44 +1100") References: <20190124001038.GH98649@meow.BKantor.net> <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> Message-ID: <8736picggn.fsf@miraculix.mork.no> Mark Andrews writes: > I’ve been complaining for YEARS about lack of EDNS compliance. Didn't help. bjorn at miraculix:~$ dig +edns=42 +noednsnegotiation @1.1 ; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 9060 IN NS d.root-servers.net. . 9060 IN NS e.root-servers.net. . 9060 IN NS f.root-servers.net. . 9060 IN NS g.root-servers.net. . 9060 IN NS h.root-servers.net. . 9060 IN NS i.root-servers.net. . 9060 IN NS j.root-servers.net. . 9060 IN NS k.root-servers.net. . 9060 IN NS l.root-servers.net. . 9060 IN NS m.root-servers.net. . 9060 IN NS a.root-servers.net. . 9060 IN NS b.root-servers.net. . 9060 IN NS c.root-servers.net. ;; Query time: 3 msec ;; SERVER: 1.0.0.1#53(1.0.0.1) ;; WHEN: Thu Jan 24 14:40:00 CET 2019 ;; MSG SIZE rcvd: 431 Bjørn From mike at sentex.net Thu Jan 24 14:40:11 2019 From: mike at sentex.net (Mike Tancsa) Date: Thu, 24 Jan 2019 09:40:11 -0500 Subject: Global statistics during the experiment (was Re: BGP Experiment) In-Reply-To: References: Message-ID: On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote: > >> Replying to throw in my support behind continuing the experiment as well. > +1. I've yet to see any disruptions caused by the experiment in my area. > Speaking of which, were there any statistics gathered and published before, during and after the experiment about the size of the global routing table and how many ASNs were impacted ?     ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From ximaera at gmail.com Thu Jan 24 15:08:40 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 24 Jan 2019 18:08:40 +0300 Subject: Global statistics during the experiment (was Re: BGP Experiment) In-Reply-To: References: Message-ID: On Thu, Jan 24, 2019, 5:40 PM Mike Tancsa wrote: > On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote: > > +1. I've yet to see any disruptions caused by the experiment in my area. > > > Speaking of which, were there any statistics gathered and published > before, during and after the experiment about the size of the global > routing table and how many ASNs were impacted ? > No, sorry. Like I said, Radar has seen nothing more than few minor interruptions during that period. If we detected anything serious, we would have posted that to our blog. I wonder if the experiment organizers have also collected any data. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailsnpipes at gmail.com Tue Jan 22 21:07:08 2019 From: tailsnpipes at gmail.com (Rich Edwards) Date: Tue, 22 Jan 2019 13:07:08 -0800 Subject: Cloud networking technologies landscape Message-ID: Hi experts, I'd appreciate some help on my research in networking technologies that public cloud providers are using today and maybe in the future too. What I can see today is more or less a mix of classic SP/DC routing/switching technologies like BGP, MPLS, SR, EVPN, RIFT, Open Fabric, SFC, GBP. Minor stuff is happening in the application/networking orchestration space 'services to services' mesh, Application based routing/Load balancing/ADC. Maybe some clouds are trying to make sense out of disaggregation, whiteboxes and their stack, specially for the data plane components (IOVisor, FD.IO , vRouter, OVS...etc). There are also some zero touch provisioning/automation/modeling work (Netconf, YANG, ZTP, iPXE...etc). Lastly, (gRPC, gRIBI, gNPI...etc) and provider specific one (RIB and FIB APIs). Am i missing anything obvious from this landscape ? It'd be great if someone can directly message me to have a short conversation. Best regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.williams at coop.org Wed Jan 23 13:42:29 2019 From: david.williams at coop.org (David Williams) Date: Wed, 23 Jan 2019 13:42:29 +0000 Subject: DWDM 10ms failover Message-ID: I'm looking for some real world feedback on 10ms DWDM failover times from Omaha to Denver on 10Gbps transmission waves. I have seen several documents that report 10 ms failure detection time but I suspect the failover mechanism takes some time to react and propagate the failed state across multiple nodes in what is probably at least 600 mile cable routes with multiple nodes along the way. Is that kind of performance something we could realistically expect? This email and any files transmitted with it are confidential and intended solely for the designated recipient. Any other use of this email is prohibited. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From minlanyu at g.harvard.edu Wed Jan 23 15:32:19 2019 From: minlanyu at g.harvard.edu (Yu, Minlan) Date: Wed, 23 Jan 2019 10:32:19 -0500 Subject: A survey about networking incidents Message-ID: Hi Nanog, We all know that networks are at the heart of many of the systems we use today. When these systems break, the underlying networks are often the first suspects. Networks are hard to diagnose and they are most likely to be blamed for problems even if they are completely healthy. As networking engineers, we have all seen cases where another part of the system was causing an issue but the network was held the suspect until the problem was resolved. We are researchers from Harvard and The University of Pennsylvania who are interested in understanding this problem and its impact better in order to build a solution. Our goal is to be able to quickly rule out the network as a root cause for incidents in order to be able to speed up diagnosis and also to improve operator efficiency. We are interested in learning the answer to a few questions. Specifically, we would like to know: How often do you see problems where the network is blamed but after investigating you find the problem to be caused by some other part of the system? How often have you had incidents where the cause of the incident was outside of the boundary of your organization? How much do you think fixing this problem can help you and your organization more quickly diagnose problems? We have created a *very* short survey to be able to get an operator's perspective on these questions. It should take less than 15 minutes to finish. The findings should help us as well as the research community at large to be able to build a solution that can benefit all types of networks, of different sizes, to improve how they do the diagnosis. We will be presenting the results of this anonymous survey in a scientific article later this year. We will report back our research once it's finished. Survey URL: https://docs.google.com/forms/d/e/1FAIpQLScx-U54eQFQi5AdBCOOucMaI6BVmLwcMFiZl2HVZ9bHi1q8bA/viewform We would greatly appreciate it if you could help us with this research. Please feel free forward this survey to other operators you know. Thank you! Minlan Yu http://minlanyu.seas.harvard.edu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at packet.gg Wed Jan 23 17:00:27 2019 From: ben at packet.gg (Ben Cooper) Date: Thu, 24 Jan 2019 04:00:27 +1100 Subject: BGP Experiment In-Reply-To: References: Message-ID: Can you stop this? You caused again a massive prefix spike/flap, and as the internet is not centered around NA (shock horror!) a number of operators in Asia and Australia go effected by your “expirment” and had no idea what was happening or why. Get a sandbox like every other researcher, as of now we have black holed and filtered your whole ASN, and have reccomended others do the same. On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > NANOG, > > This is a reminder that this experiment will resume tomorrow > (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a > BGP attribute of type 0xff (reserved for development) between 14:00 > and 14:15 GMT. > > On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > > > > NANOG, > > > > We would like to inform you of an experiment to evaluate alternatives > > for speeding up adoption of BGP route origin validation (research > > paper with details [A]). > > > > Our plan is to announce prefix 184.164.224.0/24 with a valid > > standards-compliant unassigned BGP attribute from routers operated by > > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > > development), and size 0x20 (256bits). > > > > Our collaborators recently ran an equivalent experiment with no > > complaints or known issues [A], and so we do not anticipate any > > arising. Back in 2010, an experiment using unassigned attributes by > > RIPE and Duke University caused disruption in Internet routing due to > > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > > attributes have been assigned (BGPsec-path) and adopted (large > > communities). We have successfully tested propagation of the > > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > > 1.6.3. > > > > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > > predefined period of 15 minutes starting 14:30 GMT, from Monday to > > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > > locations [E]). We will stop the experiment immediately in case any > > issues arise. > > > > Although we do not expect the experiment to cause disruption, we > > welcome feedback on its safety and especially on how to make it safer. > > We can be reached at disco-experiment at googlegroups.com. > > > > Amir Herzberg, University of Connecticut > > Ethan Katz-Bassett, Columbia University > > Haya Shulman, Fraunhofer SIT > > Ítalo Cunha, Universidade Federal de Minas Gerais > > Michael Schapira, Hebrew University of Jerusalem > > Tomas Hlavacek, Fraunhofer SIT > > Yossi Gilad, MIT > > > > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > > [B] http://peering.usc.edu > > [C] https://goo.gl/AFR1Cn > > [D] > https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > > [E] https://goo.gl/nJhmx1 > -- Ben Cooper Chief Executive Officer PacketGG - Multicast M(Telstra): 0410 411 301 M(Optus): 0434 336 743 E: ben at packet.gg & ben at multicast.net.au W: https://packet.gg W: https://multicast.net.au -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.schoch at towardex.com Wed Jan 23 20:50:14 2019 From: gavin.schoch at towardex.com (Gavin Schoch) Date: Wed, 23 Jan 2019 20:50:14 +0000 Subject: Contact at Google - Security Reliability Engineering Message-ID: <1548276616027.83549@towardex.com> Hello, Can someone from Security Reliability Engineering at Google contact me off-list? We're trying to address a re-CAPTCHA issue involving some of our blocks, but we haven't been getting response on our follow ups. Thanks! -Gavin? [http://code.twdxlabs.com/signature_twdx_logo_centered.png] Gavin Schoch | TOWARDEX | Your Network Success Story(tm) 1 Marina Park Drive, 14th Flr | Boston, MA 02210 Direct 617-849-7278 x173 | Mobile 617-651-6663 | gavin.schoch at towardex.com MASS IX: Boston's Neutral Peering Point -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivaram.mysore at gmail.com Wed Jan 23 21:53:03 2019 From: shivaram.mysore at gmail.com (Shivaram Mysore) Date: Wed, 23 Jan 2019 13:53:03 -0800 Subject: Cloud based Network monitoring service Message-ID: Hello, Recently on this mailing list, I have seen requests for network monitoring tools. Service Fractal, a startup in its early days, is providing a cloud based network and security monitoring with focus on business outcomes Service Fractal is vendor-neutral (Cisco, HPE, Allied Telesis and many white box networking solutions), provides context-aware analytics and reduces cost of operations. The core technology is built on algorithmic intelligence. Service is configured for operational use in less than 30 minutes, available on a monthly subscription basis with no terms. List of supported hardware is available at https://www.servicefractal.com/solutions (scroll down) Currently, there is a *3-month free subscription *to their services - no card needed! If you are interested, please reach out to sales at servicefractal.com Thanks /Shivaram -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at rednarb.com Thu Jan 24 02:41:40 2019 From: mailinglists at rednarb.com (Eric Brander) Date: Wed, 23 Jan 2019 19:41:40 -0700 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> Message-ID: On Wed, Jan 23, 2019 at 5:27 PM Mark Andrews wrote: > I’ve been complaining for YEARS about lack of EDNS compliance. > > If you run really old Windows DNS servers you are broken. > > If you run a firewall in front of your DNS server you may be broken. > > If you are QWEST you are broken. > > Mark > > > duckdns.org :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From sj_hznm at hotmail.com Thu Jan 24 08:27:52 2019 From: sj_hznm at hotmail.com (aun Joe) Date: Thu, 24 Jan 2019 08:27:52 +0000 Subject: Any way to collect network usage data for dial-up subscriber In-Reply-To: <20160522070414.GA14908@puck.nether.net> References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net>, <20160522070414.GA14908@puck.nether.net> Message-ID: NANOGers , is there anyway for AAA to get special online subscriber usage information without enable interim accouting on BRAS? Reading through RADIUS protocol , it seems that if we want to get online subscriber information enable interim accounting on BRAS is the only way . But, if enable that on BRAS ,, all online subscribers accouting infromation will be reported periodically. that will generate too much load on AAA , and we need to monitor a small set of subscribers only. thanks in advance. joe sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Thu Jan 24 15:14:20 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 24 Jan 2019 07:14:20 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: <55d32013-84be-d2c5-f56d-80c9ba0b791a@satchell.net> On 1/23/19 8:44 PM, Mark Andrews wrote: > and they your firewalls don’t block well formed DNS queries (lots of > them do by default). My edge routers block *all* inbound DNS requests -- I was being hit by a ton of them at one point. Cavaet: I don't run a DNS server that is a domain zone master -- I use a DNS service for that. I do have a DNS server inside, but only to handle recursive requests from inside my network. Outbound DNS requests? Lets them through, and responses too. From adamv0025 at netconsultings.com Thu Jan 24 15:49:46 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 24 Jan 2019 15:49:46 -0000 Subject: BGP Experiment In-Reply-To: <20190123190146.GA74032@mis10.towardex.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> Message-ID: <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> > From: James Jun > Sent: Wednesday, January 23, 2019 7:02 PM > > Agreed; Please resume the experiment. We're all operators here, and we > MUST have confidence that BGP speakers on our network are compliant with > protocol specification. Experiments like this are opportunities for a real-life > validation of how our devices handle messages that are out of the norm, and > help us identify issues. > > Kudos to researchers by the way, for sending courtesy announcements in > advance, and testing against some common platforms available to them > (Cisco, Quagga & BIRD) prior to the experiment. > This actually makes me thing that it might be worthwhile including these types of test to the regression testing suite. So that every time we evaluate new code or vendor we don't only test for functionality, performance and scalability, but also for robustness i.e. sending a whole heap of trash down the sockets which are accessible form the Internet (via the iACL holes), to limit the scope of the test. Rather than relying on experiments to notify us the hard way that something is not right. adam From Brian at ampr.org Thu Jan 24 15:57:37 2019 From: Brian at ampr.org (Brian Kantor) Date: Thu, 24 Jan 2019 07:57:37 -0800 Subject: BGP Experiment In-Reply-To: <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> Message-ID: <20190124155737.GA71357@meow.BKantor.net> On Thu, Jan 24, 2019 at 03:49:46PM -0000, adamv0025 at netconsultings.com wrote: > This actually makes me thing that it might be worthwhile including these > types of test to the regression testing suite. > So that every time we evaluate new code or vendor we don't only test for > functionality, performance and scalability, but also for robustness > i.e. sending a whole heap of trash down the sockets which are accessible > form the Internet (via the iACL holes), to limit the scope of the test. > > Rather than relying on experiments to notify us the hard way that something > is not right. > > adam I agree. It seems to me that testing with almost-valid data (well formed, but with disallowed values) as well as fuzz-testing are essential parts of software quality control. - Brian From adamv0025 at netconsultings.com Thu Jan 24 16:24:25 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 24 Jan 2019 16:24:25 -0000 Subject: BGP Experiment In-Reply-To: <20190124155737.GA71357@meow.BKantor.net> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> <20190124155737.GA71357@meow.BKantor.net> Message-ID: <019a01d4b401$459f9400$d0debc00$@netconsultings.com> > From: Brian Kantor > Sent: Thursday, January 24, 2019 3:58 PM > > I agree. > > It seems to me that testing with almost-valid data (well formed, but with > disallowed values) as well as fuzz-testing are essential parts of software > quality control. > To be frank, Have blasted packets at the platforms from ixias and sipernts to see if they break gracefully, loaded millions of routes and thousands of VRF and BGP sessions to see what happens, even designed the backbones with separate Internet and VPN RRs, and enabled enhanced error handling, but have I ever sat down and generated BGP packets with slight deviations to see how the BGP session, process or whole RPD copes with these? I've got to say no, never. And judging from the overly positive (or even negative) responses to the BGP Experiment I'm not alone in this. Otherwise everyone would be like, nah I don't care as I have all my bases covered and I know how my BGP behaves processing exceptions. adam From saku at ytti.fi Thu Jan 24 16:27:57 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 24 Jan 2019 18:27:57 +0200 Subject: BGP Experiment In-Reply-To: <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> Message-ID: On Thu, 24 Jan 2019 at 17:52, wrote: > This actually makes me thing that it might be worthwhile including these > types of test to the regression testing suite. I seem to recall one newish entrant to SP market explaining that they are limited by wall-time in blackbox testing. They would have no particularly challenge testing everything, but the amount of permutations and wall-time to execute single test simply makes it impossible to test comprehensively. So if you can't test everything, what do you test? How do you predict what is more likely to be broken? Focus on MTBF is fools errant, maybe someone like FB, AMZN, MSFT can do statistical analysis on outcome of change, rest of us are just guessing what we did increased MTBF, we don't have enough failures to actually know. Focus should be on MTTR. There are some commercial BGP fuzzers, I've only tested one of them: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing/defensics/protocols/bgp4-server.html -- ++ytti From adamv0025 at netconsultings.com Thu Jan 24 16:43:00 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 24 Jan 2019 16:43:00 -0000 Subject: BGP Experiment In-Reply-To: References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> Message-ID: <01a601d4b403$de7b2160$9b716420$@netconsultings.com> > From: Saku Ytti > Sent: Thursday, January 24, 2019 4:28 PM > > On Thu, 24 Jan 2019 at 17:52, wrote: > > > This actually makes me thing that it might be worthwhile including > > these types of test to the regression testing suite. > > I seem to recall one newish entrant to SP market explaining that they are > limited by wall-time in blackbox testing. They would have no particularly > challenge testing everything, but the amount of permutations and wall-time > to execute single test simply makes it impossible to test comprehensively. So > if you can't test everything, what do you test? How do you predict what is > more likely to be broken? > We fight with that all the time, I'd say that from the whole Design->Certify->Deploy->Verify->Monitor service lifecycle time budget, the service certification testing is almost half of it. That's why I'm so interested in a model driven design and testing approach. I really need to have this ever growing library of test cases that the automat will churn through with very little human intervention, in order to reduce the testing from months to days or weeks at least. > There are some commercial BGP fuzzers, I've only tested one of them: > https://www.synopsys.com/software-integrity/security-testing/fuzz- > testing/defensics/protocols/bgp4-server.html > Thank you very much for the link. adam From morrowc.lists at gmail.com Thu Jan 24 16:54:33 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Jan 2019 11:54:33 -0500 Subject: Any way to collect network usage data for dial-up subscriber In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net> <20160522070414.GA14908@puck.nether.net> Message-ID: radius On Thu, Jan 24, 2019 at 10:37 AM aun Joe wrote: > NANOGers , > > > is there anyway for AAA to get special online subscriber usage > information without enable interim accouting on BRAS? > > Reading through RADIUS protocol , it seems that if we want to get > online subscriber information enable interim accounting on BRAS is the only > way . > But, if enable that on BRAS ,, all online subscribers accouting > infromation will be reported periodically. that will generate too much > load on AAA , and > we need to monitor a small set of subscribers only. > > > thanks in advance. > > joe sun > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyeronic.design at gmail.com Thu Jan 24 17:03:56 2019 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 24 Jan 2019 09:03:56 -0800 Subject: BGP Experiment In-Reply-To: References: Message-ID: Or you could simply fix your gear rather than leaving a big hole in your infrastructure. *shrug* On Thu, Jan 24, 2019, 7:25 AM Ben Cooper Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was > happening or why. > > Get a sandbox like every other researcher, as of now we have black holed > and filtered your whole ASN, and have reccomended others do the same. > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > >> NANOG, >> >> This is a reminder that this experiment will resume tomorrow >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> BGP attribute of type 0xff (reserved for development) between 14:00 >> and 14:15 GMT. >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: >> > >> > NANOG, >> > >> > We would like to inform you of an experiment to evaluate alternatives >> > for speeding up adoption of BGP route origin validation (research >> > paper with details [A]). >> > >> > Our plan is to announce prefix 184.164.224.0/24 with a valid >> > standards-compliant unassigned BGP attribute from routers operated by >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >> > development), and size 0x20 (256bits). >> > >> > Our collaborators recently ran an equivalent experiment with no >> > complaints or known issues [A], and so we do not anticipate any >> > arising. Back in 2010, an experiment using unassigned attributes by >> > RIPE and Duke University caused disruption in Internet routing due to >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >> > attributes have been assigned (BGPsec-path) and adopted (large >> > communities). We have successfully tested propagation of the >> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >> > 1.6.3. >> > >> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and >> > locations [E]). We will stop the experiment immediately in case any >> > issues arise. >> > >> > Although we do not expect the experiment to cause disruption, we >> > welcome feedback on its safety and especially on how to make it safer. >> > We can be reached at disco-experiment at googlegroups.com. >> > >> > Amir Herzberg, University of Connecticut >> > Ethan Katz-Bassett, Columbia University >> > Haya Shulman, Fraunhofer SIT >> > Ítalo Cunha, Universidade Federal de Minas Gerais >> > Michael Schapira, Hebrew University of Jerusalem >> > Tomas Hlavacek, Fraunhofer SIT >> > Yossi Gilad, MIT >> > >> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html >> > [B] http://peering.usc.edu >> > [C] https://goo.gl/AFR1Cn >> > [D] >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >> > [E] https://goo.gl/nJhmx1 >> > -- > Ben Cooper > Chief Executive Officer > PacketGG - Multicast > M(Telstra): 0410 411 301 > M(Optus): 0434 336 743 > E: ben at packet.gg & ben at multicast.net.au > W: https://packet.gg > W: https://multicast.net.au > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Thu Jan 24 17:31:40 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 24 Jan 2019 11:31:40 -0600 Subject: A survey about networking incidents In-Reply-To: References: Message-ID: <003b01d4b40a$aac4e4d0$004eae70$@gvtc.com> It seems that this is even increasingly harder in a MEF/SP-type Layer 2 emulated network of eline, elan, etree type things… Yeah seems that you have to have synthetic-type traffic generated and inserted into the data path to measure on… Isn’t CFM/Ethernet OAM supposed to segment up the network into management domains-of-responsibility with mips/meps, etc so that you can real-time-monitor your system and others can monitor theirs… I have not set this up, but I thought that was one way of being able to know on-going the state of the network, link-by-link and endpoint-to-endpoint… I think on-going CMM’s flow to give you an idea of the extent to which links and services are good or not good. Perhaps that’s the proof you could point at for anyone trying to blame the network I’m sure there are other ways… like cisco’s ip sla… accedian’s paa, twamp (I just remembered about twamp, and I think that’s perhaps an ip-layer version of what is like Ethernet layer cfm/oam, I could be wrong…but as I think about it, I recall mpls-oam, perhaps others too Yes, as network engineer’s, I/we continually have to clear-my-name (clear the network) of blame -Aaron p.s. I’ll try to look at the survey later From: NANOG [mailto:nanog-bounces+aaron1=gvtc.com at nanog.org] On Behalf Of Yu, Minlan Sent: Wednesday, January 23, 2019 9:32 AM To: nanog at nanog.org Subject: A survey about networking incidents Hi Nanog, We all know that networks are at the heart of many of the systems we use today. When these systems break, the underlying networks are often the first suspects. Networks are hard to diagnose and they are most likely to be blamed for problems even if they are completely healthy. As networking engineers, we have all seen cases where another part of the system was causing an issue but the network was held the suspect until the problem was resolved. We are researchers from Harvard and The University of Pennsylvania who are interested in understanding this problem and its impact better in order to build a solution. Our goal is to be able to quickly rule out the network as a root cause for incidents in order to be able to speed up diagnosis and also to improve operator efficiency. We are interested in learning the answer to a few questions. Specifically, we would like to know: How often do you see problems where the network is blamed but after investigating you find the problem to be caused by some other part of the system? How often have you had incidents where the cause of the incident was outside of the boundary of your organization? How much do you think fixing this problem can help you and your organization more quickly diagnose problems? We have created a *very* short survey to be able to get an operator's perspective on these questions. It should take less than 15 minutes to finish. The findings should help us as well as the research community at large to be able to build a solution that can benefit all types of networks, of different sizes, to improve how they do the diagnosis. We will be presenting the results of this anonymous survey in a scientific article later this year. We will report back our research once it's finished. Survey URL: https://docs.google.com/forms/d/e/1FAIpQLScx-U54eQFQi5AdBCOOucMaI6BVmLwcMFiZl2HVZ9bHi1q8bA/viewform We would greatly appreciate it if you could help us with this research. Please feel free forward this survey to other operators you know. Thank you! Minlan Yu http://minlanyu.seas.harvard.edu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Thu Jan 24 18:36:34 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 25 Jan 2019 07:36:34 +1300 Subject: Any way to collect network usage data for dial-up subscriber In-Reply-To: References: <995C5F36-3D4F-45EC-86AE-C686A7914D47@arin.net> <14004985-B60E-45C7-92CA-3444979A6E5E@arin.net>, <20160522070414.GA14908@puck.nether.net> Message-ID: <004801d4b413$bbd4a2c0$337de840$@wicks.co.nz> Hi, I don't know what your scale is but setting a 15minute interim radius update has always worked well for me. A standard freeradius server running on SSD's would be able to handle the load from 100k users without too much of a load issue. Above that load balancing radius requests among servers is not really that difficult. From: NANOG On Behalf Of aun Joe Sent: Thursday, 24 January 2019 9:28 PM To: NANOG Subject: Any way to collect network usage data for dial-up subscriber NANOGers , is there anyway for AAA to get special online subscriber usage information without enable interim accouting on BRAS? Reading through RADIUS protocol , it seems that if we want to get online subscriber information enable interim accounting on BRAS is the only way . But, if enable that on BRAS ,, all online subscribers accouting infromation will be reported periodically. that will generate too much load on AAA , and we need to monitor a small set of subscribers only. thanks in advance. joe sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Jan 24 18:42:56 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Jan 2019 13:42:56 -0500 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <20190124110410.GA45327@jima.tpb.net> References: <20190124001038.GH98649@meow.BKantor.net> <4808CFC9-8A45-4F7F-965C-DA87E23CEC74@isc.org> <08284E1B-E373-4793-BE4D-DCE3F4DD89F2@isc.org> <20190124110410.GA45327@jima.tpb.net> Message-ID: you are seriously cracking me up... but. On Thu, Jan 24, 2019 at 6:05 AM Niels Bakker wrote: > * morrowc.lists at gmail.com (Christopher Morrow) [Thu 24 Jan 2019, 06:46 > CET]: > >So, we're asking 'everyone' to do 'something' on behalf of their > >domains, their users and the rest of the internet... we can't seem > >to do that in a fashion that's traceable, clearly has ownership and > >doesn't look like every halfbaked spam campaign in the world. > > Oh wait, you had to scroll down on the main dnsflagday.net page to see > those links, which in this day of only the first page of Google > results mattering, isn't going to happen, apparently. > > someone sent a url in a mail message, you didn't seriously just click on it without any attempt to verify it wasn't bad/problematic/going-to-eat-your-brain ? (in this day and age, everyone apparently does just do that) -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Jan 24 19:13:15 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 24 Jan 2019 14:13:15 -0500 Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> Message-ID: I hate to necro-thread , but has anyone seen any movement from Amazon on this? I just got a Strongly Worded Message about it, and according to my peering team , it's been radio silence for months. On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG wrote: > This is a note I received on Oct18 when checking on a peering request > submitted on Aug7.. > > “Apologies for the delays here. We have temporarily frozen IX peering as > we revise some of our automation processes. I’m hopeful this will be > unblocked by early November. Thank you for your continued patience.” > > On Nov 24, 2018, at 10:59, Darin Steffl wrote: > > It seems wasteful for Amazon to connect to an IX but then ignore peering > requests for a year. > > They have 40G of connectivity but are unresponsive. I'll try emailing all > the other contacts listed in peeringdb. > > Thanks > > On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >> I've e-mailed my contacts there a couple times on people's behalf. No >> response yet. >> >> It seems like a lot of organizations need 1 more person in their peering >> departments. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ------------------------------ >> *From: *"Darin Steffl" >> *To: *"North American Network Operators' Group" >> *Sent: *Friday, November 23, 2018 10:21:51 PM >> *Subject: *Amazon Peering >> >> Hey all, >> >> Does anyone have a direct contact to get a peering session established >> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >> this Sept and Nov with no response. >> >> I sent to peering at amazon.com and received one automated response back so >> I know they received my email but nothing since. >> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Thu Jan 24 19:21:15 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 24 Jan 2019 14:21:15 -0500 Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> Message-ID: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> We circled back with them yesterday on a request we made in late November where at the time they said they wouldn’t be turned up until 2019 due to holiday network change freeze. They responded within about 4 hours, thanked us for our patience and understanding and said we should expect them to be turned up in about 6 weeks, which is apparently their typical timing. > On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: > > I hate to necro-thread , but has anyone seen any movement from Amazon on this? I just got a Strongly Worded Message about it, and according to my peering team , it's been radio silence for months. > > > On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG > wrote: > This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. > > “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” > > On Nov 24, 2018, at 10:59, Darin Steffl > wrote: > >> It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. >> >> They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. >> >> Thanks >> >> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett wrote: >> I've e-mailed my contacts there a couple times on people's behalf. No response yet. >> >> It seems like a lot of organizations need 1 more person in their peering departments. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> From: "Darin Steffl" > >> To: "North American Network Operators' Group" > >> Sent: Friday, November 23, 2018 10:21:51 PM >> Subject: Amazon Peering >> >> Hey all, >> >> Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. >> >> I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. >> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 24 19:34:56 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 25 Jan 2019 06:34:56 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <8736picggn.fsf@miraculix.mork.no> References: <20190124001038.GH98649@meow.BKantor.net> <41BE0CE7-4603-4850-84A9-4C0020F0A22C@isc.org> <8736picggn.fsf@miraculix.mork.no> Message-ID: > On 25 Jan 2019, at 12:50 am, Bjørn Mork wrote: > > Mark Andrews writes: > >> I’ve been complaining for YEARS about lack of EDNS compliance. > > Didn't help. Perfect vs incremental improvement. Please go look at the graphs on ednscomp.isc.org. You will see the fixes being applied. You can see firewalls being removed. You can seen IPv6 being deployed on DNS server farms with broken DNS servers. You can see when name servers are fixed to remove implementation flaws. > bjorn at miraculix:~$ dig +edns=42 +noednsnegotiation @1.1 > > ; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1 > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1452 > ;; QUESTION SECTION: > ;. IN NS > > ;; ANSWER SECTION: > . 9060 IN NS d.root-servers.net. > . 9060 IN NS e.root-servers.net. > . 9060 IN NS f.root-servers.net. > . 9060 IN NS g.root-servers.net. > . 9060 IN NS h.root-servers.net. > . 9060 IN NS i.root-servers.net. > . 9060 IN NS j.root-servers.net. > . 9060 IN NS k.root-servers.net. > . 9060 IN NS l.root-servers.net. > . 9060 IN NS m.root-servers.net. > . 9060 IN NS a.root-servers.net. > . 9060 IN NS b.root-servers.net. > . 9060 IN NS c.root-servers.net. > > ;; Query time: 3 msec > ;; SERVER: 1.0.0.1#53(1.0.0.1) > ;; WHEN: Thu Jan 24 14:40:00 CET 2019 > ;; MSG SIZE rcvd: 431 > > > > Bjørn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From beecher at beecher.cc Thu Jan 24 19:38:51 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 24 Jan 2019 14:38:51 -0500 Subject: Amazon Peering In-Reply-To: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> Message-ID: Thanks Jason. I'll have my peering team take another crack at reaching out and see what happens. Appreciate it! On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld wrote: > We circled back with them yesterday on a request we made in late November > where at the time they said they wouldn’t be turned up until 2019 due to > holiday network change freeze. > > They responded within about 4 hours, thanked us for our patience and > understanding and said we should expect them to be turned up in about 6 > weeks, which is apparently their typical timing. > > On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: > > I hate to necro-thread , but has anyone seen any movement from Amazon on > this? I just got a Strongly Worded Message about it, and according to my > peering team , it's been radio silence for months. > > > On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG > wrote: > >> This is a note I received on Oct18 when checking on a peering request >> submitted on Aug7.. >> >> “Apologies for the delays here. We have temporarily frozen IX peering as >> we revise some of our automation processes. I’m hopeful this will be >> unblocked by early November. Thank you for your continued patience.” >> >> On Nov 24, 2018, at 10:59, Darin Steffl wrote: >> >> It seems wasteful for Amazon to connect to an IX but then ignore peering >> requests for a year. >> >> They have 40G of connectivity but are unresponsive. I'll try emailing all >> the other contacts listed in peeringdb. >> >> Thanks >> >> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett > >>> I've e-mailed my contacts there a couple times on people's behalf. No >>> response yet. >>> >>> It seems like a lot of organizations need 1 more person in their peering >>> departments. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ------------------------------ >>> *From: *"Darin Steffl" >>> *To: *"North American Network Operators' Group" >>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>> *Subject: *Amazon Peering >>> >>> Hey all, >>> >>> Does anyone have a direct contact to get a peering session established >>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >>> this Sept and Nov with no response. >>> >>> I sent to peering at amazon.com and received one automated response back >>> so I know they received my email but nothing since. >>> >>> >>> >>> -- >>> Darin Steffl >>> Minnesota WiFi >>> www.mnwifi.com >>> 507-634-WiFi >>> Like us on Facebook >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jan 24 19:45:08 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 24 Jan 2019 13:45:08 -0600 (CST) Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> Message-ID: <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Let us know your success as well. I'll hold off following up on my requests until I see that other people are successful. I don't want to contribute to flooding them with requests. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher" To: "Jason Lixfeld" Cc: "North American Network Operators' Group" Sent: Thursday, January 24, 2019 1:38:51 PM Subject: Re: Amazon Peering Thanks Jason. I'll have my peering team take another crack at reaching out and see what happens. Appreciate it! On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld < jason+nanog at lixfeld.ca > wrote: We circled back with them yesterday on a request we made in late November where at the time they said they wouldn’t be turned up until 2019 due to holiday network change freeze. They responded within about 4 hours, thanked us for our patience and understanding and said we should expect them to be turned up in about 6 weeks, which is apparently their typical timing.
On Jan 24, 2019, at 2:13 PM, Tom Beecher < beecher at beecher.cc > wrote: I hate to necro-thread , but has anyone seen any movement from Amazon on this? I just got a Strongly Worded Message about it, and according to my peering team , it's been radio silence for months. On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG < nanog at nanog.org > wrote:
This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” On Nov 24, 2018, at 10:59, Darin Steffl < darin.steffl at mnwifi.com > wrote:
It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. Thanks On Sat, Nov 24, 2018, 10:38 AM Mike Hammett < nanog at ics-il.net wrote:
I've e-mailed my contacts there a couple times on people's behalf. No response yet. It seems like a lot of organizations need 1 more person in their peering departments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Darin Steffl" < darin.steffl at mnwifi.com > To: "North American Network Operators' Group" < nanog at nanog.org > Sent: Friday, November 23, 2018 10:21:51 PM Subject: Amazon Peering Hey all, Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook
-------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 24 19:46:55 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 25 Jan 2019 06:46:55 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <55d32013-84be-d2c5-f56d-80c9ba0b791a@satchell.net> References: <20190124001038.GH98649@meow.BKantor.net> <55d32013-84be-d2c5-f56d-80c9ba0b791a@satchell.net> Message-ID: <9A4B0A55-0961-432D-8836-FCD7C5BD5CB6@isc.org> > On 25 Jan 2019, at 2:14 am, Stephen Satchell wrote: > > On 1/23/19 8:44 PM, Mark Andrews wrote: >> and they your firewalls don’t block well formed DNS queries (lots of >> them do by default). > > My edge routers block *all* inbound DNS requests -- I was being hit by a > ton of them at one point. Cavaet: I don't run a DNS server that is a > domain zone master -- I use a DNS service for that. I do have a DNS > server inside, but only to handle recursive requests from inside my network. > > Outbound DNS requests? Lets them through, and responses too. Well does your DNS service properly manage the firewall in front of their servers? Does the anti DoS scrubbing service they are using also pass the well formed packets to the DNS server they are advertising? This was about testing the servers YOU directly or indirectly advertise to the world. It also applies to any recursive servers. They too need properly handle EDNS queries in all their forms. The test tool has a recursive mode for testing them (genreport -R). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From darin.steffl at mnwifi.com Thu Jan 24 20:13:46 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Thu, 24 Jan 2019 14:13:46 -0600 Subject: Amazon Peering In-Reply-To: <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Message-ID: We've been waiting since December 2017 with multiple followup. Their most recent response said that February would probably be when they turn us up, 15 months after our first request. On Thu, Jan 24, 2019, 1:46 PM Mike Hammett Let us know your success as well. I'll hold off following up on my > requests until I see that other people are successful. I don't want to > contribute to flooding them with requests. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Tom Beecher" > *To: *"Jason Lixfeld" > *Cc: *"North American Network Operators' Group" > *Sent: *Thursday, January 24, 2019 1:38:51 PM > *Subject: *Re: Amazon Peering > > Thanks Jason. I'll have my peering team take another crack at reaching out > and see what happens. Appreciate it! > > On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld > wrote: > >> We circled back with them yesterday on a request we made in late November >> where at the time they said they wouldn’t be turned up until 2019 due to >> holiday network change freeze. >> >> They responded within about 4 hours, thanked us for our patience and >> understanding and said we should expect them to be turned up in about 6 >> weeks, which is apparently their typical timing. >> >> On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: >> >> I hate to necro-thread , but has anyone seen any movement from Amazon on >> this? I just got a Strongly Worded Message about it, and according to my >> peering team , it's been radio silence for months. >> >> >> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG >> wrote: >> >>> This is a note I received on Oct18 when checking on a peering request >>> submitted on Aug7.. >>> >>> “Apologies for the delays here. We have temporarily frozen IX peering as >>> we revise some of our automation processes. I’m hopeful this will be >>> unblocked by early November. Thank you for your continued patience.” >>> >>> On Nov 24, 2018, at 10:59, Darin Steffl wrote: >>> >>> It seems wasteful for Amazon to connect to an IX but then ignore peering >>> requests for a year. >>> >>> They have 40G of connectivity but are unresponsive. I'll try emailing >>> all the other contacts listed in peeringdb. >>> >>> Thanks >>> >>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >> >>>> I've e-mailed my contacts there a couple times on people's behalf. No >>>> response yet. >>>> >>>> It seems like a lot of organizations need 1 more person in their >>>> peering departments. >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> Midwest-IX >>>> http://www.midwest-ix.com >>>> >>>> ------------------------------ >>>> *From: *"Darin Steffl" >>>> *To: *"North American Network Operators' Group" >>>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>>> *Subject: *Amazon Peering >>>> >>>> Hey all, >>>> >>>> Does anyone have a direct contact to get a peering session established >>>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >>>> this Sept and Nov with no response. >>>> >>>> I sent to peering at amazon.com and received one automated response back >>>> so I know they received my email but nothing since. >>>> >>>> >>>> >>>> -- >>>> Darin Steffl >>>> Minnesota WiFi >>>> www.mnwifi.com >>>> 507-634-WiFi >>>> Like us on Facebook >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Thu Jan 24 21:21:03 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 24 Jan 2019 13:21:03 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <9A4B0A55-0961-432D-8836-FCD7C5BD5CB6@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <55d32013-84be-d2c5-f56d-80c9ba0b791a@satchell.net> <9A4B0A55-0961-432D-8836-FCD7C5BD5CB6@isc.org> Message-ID: <5a7cbf3e-3ee7-618c-2595-155ac33a286a@satchell.net> On 1/24/19 11:46 AM, Mark Andrews wrote: >On 25 Jan 2019, at 2:14 am, Stephen Satchell wrote: >> My edge routers block *all* inbound DNS requests -- I was being hit by a >> ton of them at one point. Cavaet: I don't run a DNS server that is a >> domain zone master -- I use a DNS service for that. I do have a DNS >> server inside, but only to handle recursive requests from inside my network. >> >> Outbound DNS requests? Lets them through, and responses too. > > Well does your DNS service properly manage the firewall in front of their > servers? Does the anti DoS scrubbing service they are using also pass the > well formed packets to the DNS server they are advertising? I have domains on several DNS services. Most of the services work properly according to the ISC tests. Two of the services show failures. So I called support on the pair. One service says they are deploying updates before the 1 Feb 19 deadline to all their DNS servers. The other one (starts with an "A") doesn't know when they will be fully compliant "but your customers should have no difficulty with getting DNS answers on your domains." I had downloaded the tool, so I tested my inside DNS servers just for grins. Passed with flying colors -- I had used Centos 7 in those servers, updated on a regularly scheduled basis, so of course it flew with flying colors. (Or do you prefer colours?) From valdis.kletnieks at vt.edu Fri Jan 25 02:33:35 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 24 Jan 2019 21:33:35 -0500 Subject: BGP Experiment In-Reply-To: References: Message-ID: <6092.1548383615@turing-police.cc.vt.edu> On Thu, 24 Jan 2019 04:00:27 +1100, Ben Cooper said: > You caused again a massive prefix spike/flap, That's twice now you've said that without any numbers or details. Care to explain what you mean by "massive" in a world where the IPv4 table has like 700K+ routes? And as percieved by what point(s) in the topology? Knowing where there are pockets of network admins shooting themselves in the foot drastically improves the ability of organizations like NetDotctors Without Borders to give proper aid where needed... From mehmet at akcin.net Fri Jan 25 07:45:53 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 24 Jan 2019 21:45:53 -1000 Subject: Los Angeles Meet Up Message-ID: Hey there We are (couple of NANOGers) planning a small get together in LA area(still deciding the date). If you are interested in meeting up with others from industry. Please feel free to drop me a message offlist. Thank you -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Fri Jan 25 07:58:52 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 25 Jan 2019 09:58:52 +0200 Subject: BGP Experiment In-Reply-To: <01a601d4b403$de7b2160$9b716420$@netconsultings.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> <01a601d4b403$de7b2160$9b716420$@netconsultings.com> Message-ID: On Thu, 24 Jan 2019 at 18:43, wrote: > We fight with that all the time, > I'd say that from the whole Design->Certify->Deploy->Verify->Monitor service lifecycle time budget, the service certification testing is almost half of it. > That's why I'm so interested in a model driven design and testing approach. This shop has 100% automated blackbox testing, and still they have to cherry-pick what to test. Do you have statistics how often you find show-stopper issues and how far into the test they were found? I expect this to be exponential curve, like upgrading box, getting your signalling protocols up, pushing one packet in each service you sell is easy and fast, I wonder will massive amount of work increase confidence significantly from that. The issues I tend to find in production are issues which are not trivial to recreate in lab, once we know what they are, which implies that finding them a-priori is bit naive expectation. So, assumptions: a) blackbox testing has exponentially diminishing returns, quickly you need to expand massively more efforts to gain slightly more confidence b) you can never say 'x works' you can only say 'i found way to confirm x is not broken in this very specific case', the way x will end up being broken may be very complex c) if recreating issues you know about is hard, then finding issues you don't know about is massively more difficult d) testing likely increases more your comfort to deploy than probability of success Hopefully we'll enter NOS future where we download NOS from github and compile it to our devices. Allowing whole community to contribute to unit testing and use-cases and to run minimal bug surface code in your environment. I see very little future in blackbox testing vendor NOS at operator site, beyond quick poke at lab. Seems like poor value. Rather have pessimistic deployment plan, lab => staging => 2-3 low risk site => 2-3 high risk site => slow roll up > I really need to have this ever growing library of test cases that the automat will churn through with very little human intervention, in order to reduce the testing from months to days or weeks at least. Lot of vendor, maybe all, accept your configuration and test them for releases. I think this is only viable solution vendors have for blackbox, gather configs from customers and test those, instead of try to guess what to test. I've done that with Cisco in two companies, unfortunately I can't really tell if it impacted quality, but I like to think it did. -- ++ytti From test12 at implix.com Thu Jan 24 22:51:13 2019 From: test12 at implix.com (Grzegorz Dabrowski) Date: Thu, 24 Jan 2019 23:51:13 +0100 Subject: Looking for contact from AS24218 Message-ID: Hello, I've already send to all address I could get from whois/web page and got nothing :(. Please be so kinde and write to me privately. Regards, -- Grzegorz Dabrowski From sbahnsen20 at gmail.com Fri Jan 25 04:47:40 2019 From: sbahnsen20 at gmail.com (Steven Bahnsen) Date: Fri, 25 Jan 2019 15:47:40 +1100 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS Message-ID: Hi, First time poster looking for some input on a debate and I apologise if I've done this completely wrong, but I don't think my colleague will be convinced until he hears it from this community. Granted I'm relatively green when it comes to networking, but it was my understand that other than BGP, the most widely used/implemented IGP would be OSPF. However, my colleague insists that I'm 100 percent wrong and that is IS-IS. I want to be clear, I'm not debating which protocol is better or worse, as they both have their strengths and weaknesses and ultimately it comes down to several factors based on a particular use-case on which routing protocol is the best way forward for a network. However in saying that, I believe that, when it comes to sheer numbers of where an IGP is implemented, OSPF is far more widely used in the world today, whether it be in small to medium to large businesses, Enterprise networks and even Service Provider networks (where as per my understanding, is where IS-IS really shines) I understand that this isn't really quantifiable, but I would like to get the opinions/experiences from this list and see what the outcome of this question is out of sheer curiosity. Thanks! Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Jan 25 14:37:42 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 25 Jan 2019 09:37:42 -0500 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: You’re probably right that there a lot more in service devices that are running OSPF. But IS-IS assuredly is involved in routing way more traffic volume. In the end , right tool for the job is all that matters. On Fri, Jan 25, 2019 at 09:17 Steven Bahnsen wrote: > Hi, > > First time poster looking for some input on a debate and I apologise if > I've > done this completely wrong, but I don't think my colleague will be > convinced > until he hears it from this community. > > Granted I'm relatively green when it comes to networking, but it was my > understand that other than BGP, the most widely used/implemented IGP > would be > OSPF. However, my colleague insists that I'm 100 percent wrong and that is > IS-IS. > > I want to be clear, I'm not debating which protocol is better or worse, as > they > both have their strengths and weaknesses and ultimately it comes down to > several > factors based on a particular use-case on which routing protocol is the > best way > forward for a network. > > However in saying that, I believe that, when it comes to sheer numbers of > where > an IGP is implemented, OSPF is far more widely used in the world today, > whether > it be in small to medium to large businesses, Enterprise networks and even > Service Provider networks (where as per my understanding, is where IS-IS > really > shines) > > I understand that this isn't really quantifiable, but I would like to get > the > opinions/experiences from this list and see what the outcome of this > question is > out of sheer curiosity. > > Thanks! > > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Fri Jan 25 14:44:51 2019 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 25 Jan 2019 14:44:51 +0000 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: On 25/01/2019 04:47, Steven Bahnsen wrote: > First time poster looking for some input on a debate This won't settle anything. You've just started the same old debate again, from the beginning. Again. :) There are almost certainly indexed threads of this mailing list with enough answers to this question to last a life time of arguments. (See also, c-nsp, probably j-nsp, UKNOF, etc.) -- Tom From mel at beckman.org Fri Jan 25 14:57:23 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 25 Jan 2019 14:57:23 +0000 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: , Message-ID: Why would you want to settle a pointless debate? :) -mel beckman > On Jan 25, 2019, at 6:45 AM, Tom Hill wrote: > >> On 25/01/2019 04:47, Steven Bahnsen wrote: >> First time poster looking for some input on a debate > > > This won't settle anything. You've just started the same old debate > again, from the beginning. Again. :) > > There are almost certainly indexed threads of this mailing list with > enough answers to this question to last a life time of arguments. (See > also, c-nsp, probably j-nsp, UKNOF, etc.) > > -- > Tom From saku at ytti.fi Fri Jan 25 15:28:54 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 25 Jan 2019 17:28:54 +0200 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: Q: why do we have to start this debate every other day? A: because i don't have time to start it every day On Fri, 25 Jan 2019 at 16:18, Steven Bahnsen wrote: > > Hi, > > First time poster looking for some input on a debate and I apologise if I've > done this completely wrong, but I don't think my colleague will be convinced > until he hears it from this community. > > Granted I'm relatively green when it comes to networking, but it was my > understand that other than BGP, the most widely used/implemented IGP would be > OSPF. However, my colleague insists that I'm 100 percent wrong and that is > IS-IS. > > I want to be clear, I'm not debating which protocol is better or worse, as they > both have their strengths and weaknesses and ultimately it comes down to several > factors based on a particular use-case on which routing protocol is the best way > forward for a network. > > However in saying that, I believe that, when it comes to sheer numbers of where > an IGP is implemented, OSPF is far more widely used in the world today, whether > it be in small to medium to large businesses, Enterprise networks and even > Service Provider networks (where as per my understanding, is where IS-IS really > shines) > > I understand that this isn't really quantifiable, but I would like to get the > opinions/experiences from this list and see what the outcome of this question is > out of sheer curiosity. > > Thanks! > > Steve > -- ++ytti From aaron1 at gvtc.com Fri Jan 25 15:36:10 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 25 Jan 2019 09:36:10 -0600 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: <000b01d4b4c3$b2efa820$18cef860$@gvtc.com> In my isp network of ~50,000 subscribers, I run about (200) mpls p/pe nodes in one ospf area with dual rr cluster for mp-ibgp type mpls overlay services. seems fine to me. -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at packetflux.com Fri Jan 25 14:45:07 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Fri, 25 Jan 2019 07:45:07 -0700 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: I'm personally aware of dozens and dozens of OSPF deployments, but not aware of a single IS-IS deployment. This is among smaller consumer ISPs, with typically up to around 10K customers. I'm sure a big reason for this is that IS-IS support isn't all that common in the lower end routing gear often used by these providers. On Fri, Jan 25, 2019, 7:16 AM Steven Bahnsen Hi, > > First time poster looking for some input on a debate and I apologise if > I've > done this completely wrong, but I don't think my colleague will be > convinced > until he hears it from this community. > > Granted I'm relatively green when it comes to networking, but it was my > understand that other than BGP, the most widely used/implemented IGP > would be > OSPF. However, my colleague insists that I'm 100 percent wrong and that is > IS-IS. > > I want to be clear, I'm not debating which protocol is better or worse, as > they > both have their strengths and weaknesses and ultimately it comes down to > several > factors based on a particular use-case on which routing protocol is the > best way > forward for a network. > > However in saying that, I believe that, when it comes to sheer numbers of > where > an IGP is implemented, OSPF is far more widely used in the world today, > whether > it be in small to medium to large businesses, Enterprise networks and even > Service Provider networks (where as per my understanding, is where IS-IS > really > shines) > > I understand that this isn't really quantifiable, but I would like to get > the > opinions/experiences from this list and see what the outcome of this > question is > out of sheer curiosity. > > Thanks! > > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Jan 25 18:03:28 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Jan 2019 04:03:28 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190125180328.64218C44B7@thyme.apnic.net> 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-stats at 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 26 Jan, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 735087 Prefixes after maximum aggregation (per Origin AS): 282856 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 353977 Total ASes present in the Internet Routing Table: 63043 Prefixes per ASN: 11.66 Origin-only ASes present in the Internet Routing Table: 54340 Origin ASes announcing only one prefix: 23554 Transit ASes present in the Internet Routing Table: 8703 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table: 21 Number of instances of unregistered ASNs: 23 Number of 32-bit ASNs allocated by the RIRs: 25565 Number of 32-bit ASNs visible in the Routing Table: 20801 Prefixes from 32-bit ASNs in the Routing Table: 90165 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 280 Number of addresses announced to Internet: 2842185859 Equivalent to 169 /8s, 104 /16s and 80 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.1 Total number of prefixes smaller than registry allocations: 246520 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200062 Total APNIC prefixes after maximum aggregation: 57154 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 197213 Unique aggregates announced from the APNIC address blocks: 81461 APNIC Region origin ASes present in the Internet Routing Table: 9401 APNIC Prefixes per ASN: 20.98 APNIC Region origin ASes announcing only one prefix: 2654 APNIC Region transit ASes present in the Internet Routing Table: 1385 Average APNIC Region AS path length visible: 4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4402 Number of APNIC addresses announced to Internet: 769479202 Equivalent to 45 /8s, 221 /16s and 82 /24s APNIC AS Blocks 4608-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: 217564 Total ARIN prefixes after maximum aggregation: 103205 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 216843 Unique aggregates announced from the ARIN address blocks: 103859 ARIN Region origin ASes present in the Internet Routing Table: 18333 ARIN Prefixes per ASN: 11.83 ARIN Region origin ASes announcing only one prefix: 6813 ARIN Region transit ASes present in the Internet Routing Table: 1849 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2556 Number of ARIN addresses announced to Internet: 1079577248 Equivalent to 64 /8s, 89 /16s and 10 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 201876 Total RIPE prefixes after maximum aggregation: 96105 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 198122 Unique aggregates announced from the RIPE address blocks: 117149 RIPE Region origin ASes present in the Internet Routing Table: 25785 RIPE Prefixes per ASN: 7.68 RIPE Region origin ASes announcing only one prefix: 11496 RIPE Region transit ASes present in the Internet Routing Table: 3619 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7780 Number of RIPE addresses announced to Internet: 716486080 Equivalent to 42 /8s, 180 /16s and 181 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 95321 Total LACNIC prefixes after maximum aggregation: 22183 LACNIC Deaggregation factor: 4.30 Prefixes being announced from the LACNIC address blocks: 96713 Unique aggregates announced from the LACNIC address blocks: 42119 LACNIC Region origin ASes present in the Internet Routing Table: 8009 LACNIC Prefixes per ASN: 12.08 LACNIC Region origin ASes announcing only one prefix: 2174 LACNIC Region transit ASes present in the Internet Routing Table: 1495 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 31 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5558 Number of LACNIC addresses announced to Internet: 173208064 Equivalent to 10 /8s, 82 /16s and 242 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 20242 Total AfriNIC prefixes after maximum aggregation: 4191 AfriNIC Deaggregation factor: 4.83 Prefixes being announced from the AfriNIC address blocks: 25916 Unique aggregates announced from the AfriNIC address blocks: 9144 AfriNIC Region origin ASes present in the Internet Routing Table: 1233 AfriNIC Prefixes per ASN: 21.02 AfriNIC Region origin ASes announcing only one prefix: 417 AfriNIC Region transit ASes present in the Internet Routing Table: 244 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 20 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 505 Number of AfriNIC addresses announced to Internet: 103030272 Equivalent to 6 /8s, 36 /16s and 30 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4594 526 522 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3048 1160 100 VIETEL-AS-AP Viettel Group, VN 45899 3000 1721 111 VNPT-AS-VN VNPT Corp, VN 4766 2811 11127 767 KIXS-AS-KR Korea Telecom, KR 9829 2749 1496 550 BSNL-NIB National Internet Backbone, IN 9808 2475 8699 26 CMNET-GD Guangdong Mobile Communication 9394 2406 4906 29 CTTNET China TieTong Telecommunications 4755 2145 438 183 TATACOMM-AS TATA Communications formerl 17974 2036 968 50 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3536 1322 87 SHAW - Shaw Communications Inc., CA 11492 3486 225 616 CABLEONE - CABLE ONE, INC., US 22773 3313 2980 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2621 5377 1003 AMAZON-02 - Amazon.com, Inc., US 16625 2272 1248 1714 AKAMAI-AS - Akamai Technologies, Inc., 20115 2153 2759 536 CHARTER-20115 - Charter Communications, 18566 2136 405 108 MEGAPATH5-US - MegaPath Corporation, US 30036 2122 356 114 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 5650 2089 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2071 5076 580 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5320 1628 138 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3277 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2625 561 1923 AKAMAI-ASN1, US 12389 2228 2220 631 ROSTELECOM-AS, RU 34984 2067 339 528 TELLCOM-AS, TR 9121 1685 1691 17 TTNET, TR 13188 1604 100 46 TRIOLAN, UA 9009 1309 144 735 M247, GB 8402 1305 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5532 3323 587 Uninet S.A. de C.V., MX 10620 3003 453 963 Telmex Colombia S.A., CO 11830 2683 371 60 Instituto Costarricense de Electricidad 6503 1583 449 55 Axtel, S.A.B. de C.V., MX 7303 1441 965 226 Telecom Argentina S.A., AR 6147 1271 377 29 Telefonica del Peru S.A.A., PE 28573 1181 2239 183 CLARO S.A., BR 3816 1029 511 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 932 144 67 Alestra, S. de R.L. de C.V., MX 18881 920 1114 28 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1145 393 21 LINKdotNET-AS, EG 37611 904 107 9 Afrihost, ZA 36992 800 1411 44 ETISALAT-MISR, EG 36903 797 401 139 MT-MPLS, MA 24835 684 634 21 RAYA-AS, EG 8452 629 1731 20 TE-AS TE-AS, EG 29571 485 70 13 ORANGE-COTE-IVOIRE, CI 37492 468 470 57 ORANGE-, TN 15399 425 45 11 WANANCHI-, KE 37342 418 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5532 3323 587 Uninet S.A. de C.V., MX 12479 5320 1628 138 UNI2-AS, ES 4538 4653 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4594 526 522 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3536 1322 87 SHAW - Shaw Communications Inc., CA 11492 3486 225 616 CABLEONE - CABLE ONE, INC., US 22773 3313 2980 174 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3277 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 7552 3048 1160 100 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5320 5182 UNI2-AS, ES 4538 4653 4579 ERX-CERNET-BKB China Education and Research Net 7545 4594 4072 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3536 3449 SHAW - Shaw Communications Inc., CA 8551 3277 3234 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 3313 3139 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3048 2948 VIETEL-AS-AP Viettel Group, VN 45899 3000 2889 VNPT-AS-VN VNPT Corp, VN 11492 3486 2870 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.64.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.220.96.0/19 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64141 UNALLOCATED 181.119.152.0/24 264619 Wireless Provider, AR Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.170.96.0/24 29916 AS-TIC - The Internet Company Limited Partnership, 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:36 /11:99 /12:292 /13:568 /14:1128 /15:1917 /16:13372 /17:7875 /18:13833 /19:25553 /20:39707 /21:46145 /22:91375 /23:74966 /24:415370 /25:918 /26:821 /27:865 /28:20 /29:6 /30:7 /31:0 /32:192 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4166 5320 UNI2-AS, ES 6327 3302 3536 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2758 3486 CABLEONE - CABLE ONE, INC., US 8551 2733 3277 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2551 3313 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2031 2136 MEGAPATH5-US - MegaPath Corporation, US 11830 2029 2683 Instituto Costarricense de Electricidad y Telec 30036 1868 2122 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1761 2089 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1613 2:897 4:23 5:2787 6:43 7:1 8:1174 12:1869 13:314 14:1866 15:37 16:2 17:219 18:59 20:49 23:2597 24:2461 25:2 27:2562 31:2044 32:92 35:35 36:832 37:3010 38:1609 39:288 40:122 41:3125 42:726 43:2001 44:139 45:6534 46:3214 47:248 49:1331 50:1087 51:321 52:1072 54:360 55:1 56:6 57:41 58:1716 59:1055 60:481 61:2076 62:2208 63:1807 64:5093 65:2199 66:4829 67:2685 68:1158 69:3476 70:1151 71:604 72:2287 74:2757 75:418 76:543 77:1727 78:1755 79:2313 80:1645 81:1432 82:1101 83:905 84:1084 85:2137 86:556 87:1550 88:985 89:2420 90:211 91:6559 92:1241 93:2433 94:2497 95:3215 96:917 97:349 98:941 99:169 100:87 101:1226 102:364 103:19892 104:3555 105:246 106:879 107:1816 108:695 109:3656 110:1649 111:1870 112:1404 113:1405 114:1150 115:1724 116:1653 117:1918 118:2186 119:1642 120:1044 121:1027 122:2359 123:1641 124:1408 125:1950 128:1227 129:677 130:523 131:1639 132:718 133:218 134:1047 135:230 136:547 137:680 138:1948 139:820 140:570 141:791 142:802 143:995 144:900 145:504 146:1248 147:798 148:1715 149:801 150:780 151:987 152:982 153:324 154:2420 155:966 156:1644 157:894 158:656 159:1907 160:1497 161:918 162:2672 163:771 164:1122 165:1574 166:438 167:1377 168:3259 169:870 170:4010 171:500 172:1071 173:2171 174:999 175:876 176:2299 177:4041 178:2564 179:1292 180:2088 181:2442 182:2688 183:1060 184:1142 185:14630 186:3701 187:2434 188:2955 189:2038 190:8354 191:1420 192:10058 193:6528 194:5338 195:4039 196:2926 197:1732 198:5719 199:5963 200:7325 201:5058 202:10143 203:10133 204:4616 205:3006 206:3303 207:3271 208:3948 209:4232 210:3925 211:1985 212:3056 213:2843 214:1081 215:52 216:5985 217:2193 218:916 219:573 220:1842 221:994 222:980 223:1432 End of report From randy at psg.com Fri Jan 25 18:32:42 2019 From: randy at psg.com (Randy Bush) Date: Fri, 25 Jan 2019 10:32:42 -0800 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: there's an old saying, is-is is deployed in few networks, just some of the world's largest ones. there might be a reason for that. personally, i prefer emacs. randy From beecher at beecher.cc Fri Jan 25 18:37:14 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 25 Jan 2019 13:37:14 -0500 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: Next thing we know someone is going to start pumping up EIGRP. On Fri, Jan 25, 2019 at 1:34 PM Randy Bush wrote: > there's an old saying, is-is is deployed in few networks, just some of > the world's largest ones. there might be a reason for that. > > personally, i prefer emacs. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Jan 25 18:40:37 2019 From: randy at psg.com (Randy Bush) Date: Fri, 25 Jan 2019 10:40:37 -0800 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: > Next thing we know someone is going to start pumping up EIGRP. > >> there's an old saying, is-is is deployed in few networks, just some of >> the world's largest ones. there might be a reason for that. >> >> personally, i prefer emacs. idrp please randy From aaron1 at gvtc.com Fri Jan 25 19:37:22 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 25 Jan 2019 13:37:22 -0600 Subject: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS In-Reply-To: References: Message-ID: <002601d4b4e5$64fa9040$2eefb0c0$@gvtc.com> Nah, statics everywhere. That way only I can fix it. ...sometimes... lol -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Friday, January 25, 2019 12:41 PM To: Tom Beecher Cc: North American Network Operators' Group Subject: Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS > Next thing we know someone is going to start pumping up EIGRP. > >> there's an old saying, is-is is deployed in few networks, just some of >> the world's largest ones. there might be a reason for that. >> >> personally, i prefer emacs. idrp please randy From jheitz at cisco.com Fri Jan 25 22:13:44 2019 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Fri, 25 Jan 2019 22:13:44 +0000 Subject: BGP Experiment Message-ID: It does, Ytti. And not just in testing. In feature development too. Often in design discussions, someone pipes up: "someone does bla bla, Let's not break it". One I remember from years ago was setting two route reflectors as clients of each other and thinking route reflection wasn't designed for that. It's being aware of such customer "creativity" that keeps us on our toes. Regards, Jakob. -----Original Message----- From: Saku Ytti Lot of vendor, maybe all, accept your configuration and test them for releases. I think this is only viable solution vendors have for blackbox, gather configs from customers and test those, instead of try to guess what to test. I've done that with Cisco in two companies, unfortunately I can't really tell if it impacted quality, but I like to think it did. -- ++ytti From beecher at beecher.cc Fri Jan 25 22:31:15 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 25 Jan 2019 17:31:15 -0500 Subject: BGP Experiment In-Reply-To: References: Message-ID: If I understand this thread correctly, the test cause no actual change in the routing table size or route announcement. That was all a result of the incorrect behavior of the software. Instead of throwing rocks, how about some data instead. We can collaborate and better understand the whole thing so make it better and move on to the next thing. Yelling about "North America" when 4 of the 7 listed researchers on the test are NOT IN NORTH AMERICA doesn't really help anything. On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: > Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was > happening or why. > > Get a sandbox like every other researcher, as of now we have black holed > and filtered your whole ASN, and have reccomended others do the same. > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > >> NANOG, >> >> This is a reminder that this experiment will resume tomorrow >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> BGP attribute of type 0xff (reserved for development) between 14:00 >> and 14:15 GMT. >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: >> > >> > NANOG, >> > >> > We would like to inform you of an experiment to evaluate alternatives >> > for speeding up adoption of BGP route origin validation (research >> > paper with details [A]). >> > >> > Our plan is to announce prefix 184.164.224.0/24 with a valid >> > standards-compliant unassigned BGP attribute from routers operated by >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >> > development), and size 0x20 (256bits). >> > >> > Our collaborators recently ran an equivalent experiment with no >> > complaints or known issues [A], and so we do not anticipate any >> > arising. Back in 2010, an experiment using unassigned attributes by >> > RIPE and Duke University caused disruption in Internet routing due to >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >> > attributes have been assigned (BGPsec-path) and adopted (large >> > communities). We have successfully tested propagation of the >> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >> > 1.6.3. >> > >> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and >> > locations [E]). We will stop the experiment immediately in case any >> > issues arise. >> > >> > Although we do not expect the experiment to cause disruption, we >> > welcome feedback on its safety and especially on how to make it safer. >> > We can be reached at disco-experiment at googlegroups.com. >> > >> > Amir Herzberg, University of Connecticut >> > Ethan Katz-Bassett, Columbia University >> > Haya Shulman, Fraunhofer SIT >> > Ítalo Cunha, Universidade Federal de Minas Gerais >> > Michael Schapira, Hebrew University of Jerusalem >> > Tomas Hlavacek, Fraunhofer SIT >> > Yossi Gilad, MIT >> > >> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html >> > [B] http://peering.usc.edu >> > [C] https://goo.gl/AFR1Cn >> > [D] >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >> > [E] https://goo.gl/nJhmx1 >> > -- > Ben Cooper > Chief Executive Officer > PacketGG - Multicast > M(Telstra): 0410 411 301 > M(Optus): 0434 336 743 > E: ben at packet.gg & ben at multicast.net.au > W: https://packet.gg > W: https://multicast.net.au > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy_94108 at yahoo.com Fri Jan 25 23:14:39 2019 From: randy_94108 at yahoo.com (Randy) Date: Fri, 25 Jan 2019 23:14:39 +0000 (UTC) Subject: BGP Experiment In-Reply-To: References: Message-ID: <1746129068.1322209.1548458079333@mail.yahoo.com> OP is yet to clarify how a single /24 advertisement caused a "massive-prefix spike/flap"; in OP's words. The Experiment should continue. -Randy On Friday, January 25, 2019, 2:32:47 PM PST, Tom Beecher wrote: If I understand this thread correctly, the test cause no actual change in the routing table size or route announcement. That was all a result of the incorrect behavior of the software.  Instead of throwing rocks, how about some data instead. We can collaborate and better understand the whole thing so make it better and move on to the next thing. Yelling about "North America" when 4 of the 7 listed researchers on the test are NOT IN NORTH AMERICA doesn't really help anything.  On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: > Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet is not centered around NA (shock horror!) a number of operators in Asia and Australia go effected by your “expirment” and had no idea what was happening or why. > > Get a sandbox like every other researcher, as of now we have black holed and filtered your whole ASN, and have reccomended others do the same.  > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: >> NANOG, >> >> This is a reminder that this experiment will resume tomorrow >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> BGP attribute of type 0xff (reserved for development) between 14:00 >> and 14:15 GMT. >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: >>> >>> NANOG, >>> >>> We would like to inform you of an experiment to evaluate alternatives >>> for speeding up adoption of BGP route origin validation (research >>> paper with details [A]). >>> >>> Our plan is to announce prefix 184.164.224.0/24 with a valid >>> standards-compliant unassigned BGP attribute from routers operated by >>> the PEERING testbed [B, C]. The attribute will have flags 0xe0 >>> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >>> development), and size 0x20 (256bits). >>> >>> Our collaborators recently ran an equivalent experiment with no >>> complaints or known issues [A], and so we do not anticipate any >>> arising. Back in 2010, an experiment using unassigned attributes by >>> RIPE and Duke University caused disruption in Internet routing due to >>> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >>> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >>> attributes have been assigned (BGPsec-path) and adopted (large >>> communities). We have successfully tested propagation of the >>> announcements on Cisco IOS-based routers running versions 12.2(33)SRA >>> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >>> 1.6.3. >>> >>> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >>> predefined period of 15 minutes starting 14:30 GMT, from Monday to >>> Thursday, between the 7th and 22nd of January, 2019 (full schedule and >>> locations [E]). We will stop the experiment immediately in case any >>> issues arise. >>> >>> Although we do not expect the experiment to cause disruption, we >>> welcome feedback on its safety and especially on how to make it safer. >>> We can be reached at disco-experiment at googlegroups.com. >>> >>> Amir Herzberg, University of Connecticut >>> Ethan Katz-Bassett, Columbia University >>> Haya Shulman, Fraunhofer SIT >>> Ítalo Cunha, Universidade Federal de Minas Gerais >>> Michael Schapira, Hebrew University of Jerusalem >>> Tomas Hlavacek, Fraunhofer SIT >>> Yossi Gilad, MIT >>> >>> [A] https://conferences.sigcomm.org/hotnets/2018/program.html >>> [B] http://peering.usc.edu >>> [C] https://goo.gl/AFR1Cn >>> [D] https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >>> [E] https://goo.gl/nJhmx1 >> > -- > Ben Cooper > Chief Executive Officer > PacketGG - Multicast > M(Telstra): 0410 411 301 > M(Optus):  0434 336 743 > E: ben at packet.gg & ben at multicast.net.au > W: https://packet.gg > W: https://multicast.net.au > > > From ESundberg at nitelusa.com Sat Jan 26 00:29:45 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Sat, 26 Jan 2019 00:29:45 +0000 Subject: Quick Script to check the uptime of ASR920's Message-ID: All, I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. Output Format in CSV DeviceName, IP, Uptime in Days, OK/Warning I set my warning to 800 Days, you can change this in the code ASR920list.txt ------------- ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ Output [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, OK ASR920-4.CHI1, 192.168.21.6, 142, OK ________________________________ 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. From ESundberg at nitelusa.com Sat Jan 26 00:37:47 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Sat, 26 Jan 2019 00:37:47 +0000 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: References: Message-ID: Doh.. Sent this to the wrong list. :facepalm: Check out c-nsp if you want to find out about Cisco Bug CSCvk35460 on ASR920. Counters stop working at 889 days of uptime. -----Original Message----- From: NANOG On Behalf Of Erik Sundberg Sent: Friday, January 25, 2019 6:30 PM To: nanog at nanog.org Subject: Quick Script to check the uptime of ASR920's All, I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. Output Format in CSV DeviceName, IP, Uptime in Days, OK/Warning I set my warning to 800 Days, you can change this in the code ASR920list.txt ------------- ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ Output [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, OK ASR920-4.CHI1, 192.168.21.6, 142, OK ________________________________ 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. From mel at beckman.org Sat Jan 26 00:39:26 2019 From: mel at beckman.org (Mel Beckman) Date: Sat, 26 Jan 2019 00:39:26 +0000 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: References: Message-ID: Erik, That’s a nice little script. Thanks! So you want a warning if a router hasn’t been rebooted in a long time? Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty much ever. Usually I want to know if the uptime suddenly became less than the most recent uptime, indicting a possibly unplanned reboot. -mel > On Jan 25, 2019, at 4:29 PM, Erik Sundberg wrote: > > All, > > I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday > > Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime > It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. > > > Output Format in CSV > DeviceName, IP, Uptime in Days, OK/Warning > > I set my warning to 800 Days, you can change this in the code > > > ASR920list.txt > ------------- > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey > ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey > ~~~~snip you get the idea~~~~ > > > Output > > [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt > ASR920-1.SEA1, 192.168.28.1, 827, WARNING > ASR920-2.SEA1, 192.168.28.2, 827, WARNING > ASR920-2.ATL1, 192.168.23.2, 828, WARNING > ASR920-1.ATL1, 192.168.23.1, 813, WARNING > ASR920-1.CHI1, 192.168.21.3, 828, WARNING > ASR920-1.NYC1, 192.168.25.1, 787, OK > ASR920-2.CHI1, 192.168.21.4, 720, OK > ASR920-3.CHI1, 192.168.21.5, 720, OK > ASR920-1.DAL1, 192.168.26.3, 488, OK > ASR920-4.CHI1, 192.168.21.6, 142, OK > > > > ________________________________ > > 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. From ESundberg at nitelusa.com Sat Jan 26 00:44:07 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Sat, 26 Jan 2019 00:44:07 +0000 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: References: Message-ID: It was a script I created in regards to this thread below... Interface counters and some other things stop working after a Cisco ASR920 is up 889 days.... Fun Fun https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html -----Original Message----- From: Mel Beckman Sent: Friday, January 25, 2019 6:39 PM To: Erik Sundberg Cc: nanog at nanog.org Subject: Re: Quick Script to check the uptime of ASR920's Erik, That’s a nice little script. Thanks! So you want a warning if a router hasn’t been rebooted in a long time? Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty much ever. Usually I want to know if the uptime suddenly became less than the most recent uptime, indicting a possibly unplanned reboot. -mel > On Jan 25, 2019, at 4:29 PM, Erik Sundberg wrote: > > All, > > I just created a quick script to check the uptime of a ASR920 via SNMP > if you have a fairly long list of devices. It's a simple bash script > and snmpwalk version 2c. Figured I would share it with you. Happy > Friday > > Grab the code from GitHub: > https://github.com/esundberg/CiscoRouterUptime > It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. > > > Output Format in CSV > DeviceName, IP, Uptime in Days, OK/Warning > > I set my warning to 800 Days, you can change this in the code > > > ASR920list.txt > ------------- > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, > 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ > > > Output > > [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, > 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING > ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, > 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, > 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK > ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, > OK ASR920-4.CHI1, 192.168.21.6, 142, OK > > > > ________________________________ > > 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. From jhellenthal at dataix.net Sat Jan 26 01:21:03 2019 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 25 Jan 2019 19:21:03 -0600 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: References: Message-ID: Good stuff! Thanks for sharing this will come in handy. Quick note for those running it would be a little more portable by changing the shebang line to #!/bin/sh as bash on a lot of systems does not exist in /bin -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jan 25, 2019, at 18:44, Erik Sundberg wrote: > > It was a script I created in regards to this thread below... Interface counters and some other things stop working after a Cisco ASR920 is up 889 days.... Fun Fun > > https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html > > > -----Original Message----- > From: Mel Beckman > Sent: Friday, January 25, 2019 6:39 PM > To: Erik Sundberg > Cc: nanog at nanog.org > Subject: Re: Quick Script to check the uptime of ASR920's > > Erik, > > That’s a nice little script. Thanks! > > So you want a warning if a router hasn’t been rebooted in a long time? Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty much ever. Usually I want to know if the uptime suddenly became less than the most recent uptime, indicting a possibly unplanned reboot. > > -mel > >> On Jan 25, 2019, at 4:29 PM, Erik Sundberg wrote: >> >> All, >> >> I just created a quick script to check the uptime of a ASR920 via SNMP >> if you have a fairly long list of devices. It's a simple bash script >> and snmpwalk version 2c. Figured I would share it with you. Happy >> Friday >> >> Grab the code from GitHub: >> https://github.com/esundberg/CiscoRouterUptime >> It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. >> >> >> Output Format in CSV >> DeviceName, IP, Uptime in Days, OK/Warning >> >> I set my warning to 800 Days, you can change this in the code >> >> >> ASR920list.txt >> ------------- >> ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, >> 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ >> >> >> Output >> >> [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, >> 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING >> ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, >> 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, >> 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK >> ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, >> OK ASR920-4.CHI1, 192.168.21.6, 142, OK >> >> >> >> ________________________________ >> >> 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. From marktees at gmail.com Sat Jan 26 02:47:42 2019 From: marktees at gmail.com (Mark Tees) Date: Sat, 26 Jan 2019 12:47:42 +1000 Subject: BGP Experiment In-Reply-To: <1746129068.1322209.1548458079333@mail.yahoo.com> References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: I might be reading this wrong but it appears only one person has raised an issue and then not actually backed it up with data. Out of the eyes that have views inside the major networks did anyone see any issues? Surely cross posting this to other NOG lists is sufficienct. On Sat, 26 Jan 2019 at 09:15, Randy via NANOG wrote: > OP is yet to clarify how a single /24 advertisement caused a > "massive-prefix spike/flap"; in OP's words. > > The Experiment should continue. > -Randy > > > On Friday, January 25, 2019, 2:32:47 PM PST, Tom Beecher > wrote: > > If I understand this thread correctly, the test cause no actual change in > the routing table size or route announcement. That was all a result of the > incorrect behavior of the software. > > Instead of throwing rocks, how about some data instead. We can collaborate > and better understand the whole thing so make it better and move on to the > next thing. Yelling about "North America" when 4 of the 7 listed > researchers on the test are NOT IN NORTH AMERICA doesn't really help > anything. > > > > > > On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: > > Can you stop this? > > > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was > happening or why. > > > > Get a sandbox like every other researcher, as of now we have black holed > and filtered your whole ASN, and have reccomended others do the same. > > > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > >> NANOG, > >> > >> This is a reminder that this experiment will resume tomorrow > >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a > >> BGP attribute of type 0xff (reserved for development) between 14:00 > >> and 14:15 GMT. > >> > >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > >>> > >>> NANOG, > >>> > >>> We would like to inform you of an experiment to evaluate alternatives > >>> for speeding up adoption of BGP route origin validation (research > >>> paper with details [A]). > >>> > >>> Our plan is to announce prefix 184.164.224.0/24 with a valid > >>> standards-compliant unassigned BGP attribute from routers operated by > >>> the PEERING testbed [B, C]. The attribute will have flags 0xe0 > >>> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > >>> development), and size 0x20 (256bits). > >>> > >>> Our collaborators recently ran an equivalent experiment with no > >>> complaints or known issues [A], and so we do not anticipate any > >>> arising. Back in 2010, an experiment using unassigned attributes by > >>> RIPE and Duke University caused disruption in Internet routing due to > >>> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > >>> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > >>> attributes have been assigned (BGPsec-path) and adopted (large > >>> communities). We have successfully tested propagation of the > >>> announcements on Cisco IOS-based routers running versions 12.2(33)SRA > >>> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > >>> 1.6.3. > >>> > >>> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > >>> predefined period of 15 minutes starting 14:30 GMT, from Monday to > >>> Thursday, between the 7th and 22nd of January, 2019 (full schedule and > >>> locations [E]). We will stop the experiment immediately in case any > >>> issues arise. > >>> > >>> Although we do not expect the experiment to cause disruption, we > >>> welcome feedback on its safety and especially on how to make it safer. > >>> We can be reached at disco-experiment at googlegroups.com. > >>> > >>> Amir Herzberg, University of Connecticut > >>> Ethan Katz-Bassett, Columbia University > >>> Haya Shulman, Fraunhofer SIT > >>> Ítalo Cunha, Universidade Federal de Minas Gerais > >>> Michael Schapira, Hebrew University of Jerusalem > >>> Tomas Hlavacek, Fraunhofer SIT > >>> Yossi Gilad, MIT > >>> > >>> [A] https://conferences.sigcomm.org/hotnets/2018/program.html > >>> [B] http://peering.usc.edu > >>> [C] https://goo.gl/AFR1Cn > >>> [D] > https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > >>> [E] https://goo.gl/nJhmx1 > >> > > -- > > Ben Cooper > > Chief Executive Officer > > PacketGG - Multicast > > M(Telstra): 0410 411 301 > > M(Optus): 0434 336 743 > > E: ben at packet.gg & ben at multicast.net.au > > W: https://packet.gg > > W: https://multicast.net.au > > > > > > > -- Regards, Mark L. Tees -------------- next part -------------- An HTML attachment was scrubbed... URL: From marktees at gmail.com Sat Jan 26 07:24:19 2019 From: marktees at gmail.com (Mark Tees) Date: Sat, 26 Jan 2019 17:24:19 +1000 Subject: BGP Experiment In-Reply-To: References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: I did realise a little after this that it would be a no no to talk this security wise. On Sat, 26 Jan 2019 at 12:47, Mark Tees wrote: > I might be reading this wrong but it appears only one person has raised an > issue and then not actually backed it up with data. > > Out of the eyes that have views inside the major networks did anyone see > any issues? > > Surely cross posting this to other NOG lists is sufficienct. > > > On Sat, 26 Jan 2019 at 09:15, Randy via NANOG wrote: > >> OP is yet to clarify how a single /24 advertisement caused a >> "massive-prefix spike/flap"; in OP's words. >> >> The Experiment should continue. >> -Randy >> >> >> On Friday, January 25, 2019, 2:32:47 PM PST, Tom Beecher >> wrote: >> >> If I understand this thread correctly, the test cause no actual change in >> the routing table size or route announcement. That was all a result of the >> incorrect behavior of the software. >> >> Instead of throwing rocks, how about some data instead. We can >> collaborate and better understand the whole thing so make it better and >> move on to the next thing. Yelling about "North America" when 4 of the 7 >> listed researchers on the test are NOT IN NORTH AMERICA doesn't really help >> anything. >> >> >> >> >> >> On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: >> > Can you stop this? >> > >> > You caused again a massive prefix spike/flap, and as the internet is >> not centered around NA (shock horror!) a number of operators in Asia and >> Australia go effected by your “expirment” and had no idea what was >> happening or why. >> > >> > Get a sandbox like every other researcher, as of now we have black >> holed and filtered your whole ASN, and have reccomended others do the same. >> > >> > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: >> >> NANOG, >> >> >> >> This is a reminder that this experiment will resume tomorrow >> >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> >> BGP attribute of type 0xff (reserved for development) between 14:00 >> >> and 14:15 GMT. >> >> >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha >> wrote: >> >>> >> >>> NANOG, >> >>> >> >>> We would like to inform you of an experiment to evaluate alternatives >> >>> for speeding up adoption of BGP route origin validation (research >> >>> paper with details [A]). >> >>> >> >>> Our plan is to announce prefix 184.164.224.0/24 with a valid >> >>> standards-compliant unassigned BGP attribute from routers operated by >> >>> the PEERING testbed [B, C]. The attribute will have flags 0xe0 >> >>> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >> >>> development), and size 0x20 (256bits). >> >>> >> >>> Our collaborators recently ran an equivalent experiment with no >> >>> complaints or known issues [A], and so we do not anticipate any >> >>> arising. Back in 2010, an experiment using unassigned attributes by >> >>> RIPE and Duke University caused disruption in Internet routing due to >> >>> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >> >>> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >> >>> attributes have been assigned (BGPsec-path) and adopted (large >> >>> communities). We have successfully tested propagation of the >> >>> announcements on Cisco IOS-based routers running versions 12.2(33)SRA >> >>> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >> >>> 1.6.3. >> >>> >> >>> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >> >>> predefined period of 15 minutes starting 14:30 GMT, from Monday to >> >>> Thursday, between the 7th and 22nd of January, 2019 (full schedule and >> >>> locations [E]). We will stop the experiment immediately in case any >> >>> issues arise. >> >>> >> >>> Although we do not expect the experiment to cause disruption, we >> >>> welcome feedback on its safety and especially on how to make it safer. >> >>> We can be reached at disco-experiment at googlegroups.com. >> >>> >> >>> Amir Herzberg, University of Connecticut >> >>> Ethan Katz-Bassett, Columbia University >> >>> Haya Shulman, Fraunhofer SIT >> >>> Ítalo Cunha, Universidade Federal de Minas Gerais >> >>> Michael Schapira, Hebrew University of Jerusalem >> >>> Tomas Hlavacek, Fraunhofer SIT >> >>> Yossi Gilad, MIT >> >>> >> >>> [A] https://conferences.sigcomm.org/hotnets/2018/program.html >> >>> [B] http://peering.usc.edu >> >>> [C] https://goo.gl/AFR1Cn >> >>> [D] >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >> >>> [E] https://goo.gl/nJhmx1 >> >> >> > -- >> > Ben Cooper >> > Chief Executive Officer >> > PacketGG - Multicast >> > M(Telstra): 0410 411 301 >> > M(Optus): 0434 336 743 >> > E: ben at packet.gg & ben at multicast.net.au >> > W: https://packet.gg >> > W: https://multicast.net.au >> > >> > >> > >> > -- > Regards, > > Mark L. Tees > -- Regards, Mark L. Tees -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Jan 26 16:15:03 2019 From: randy at psg.com (Randy Bush) Date: Sat, 26 Jan 2019 08:15:03 -0800 Subject: BGP Experiment In-Reply-To: References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: i just want to make sure that folk are really in agreement with what i think i have been hearing from a lot of strident voices here. if you know of an out-of-spec vulnerability or bug in deployed router, switch, server, ... ops and researchers should exploit it as much as possible in order to encourage fixing of the hole. given the number of bugs/vulns, are you comfortable that this is going to scale well? and this is prudent when our primary responsibility is a running internet? just checkin' randy PS: if you think this, speak up so i can note to never hire or recommend you. PPS: Anant Shah, Romain Fontugne, Emile Aben, Cristel Pelsser, and Randy Bush; "Disco: Fast, Good, and Cheap Outage Detection"; TMA 2017 ^^^^^ :) From owen at delong.com Sat Jan 26 19:37:05 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Jan 2019 11:37:05 -0800 Subject: BGP Experiment In-Reply-To: References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: <42E5E5FA-19E8-4B4E-A468-0EAC5826F290@delong.com> I think that’s a bit of reductio ad absurdum from what has been said. I would prefer that researchers collaborate to: 1. Compile a list of lists that should be notified of such experiments in advance. Try to get the word out to as much of the community as possible through various NOGs and other relevant industry lists. 2. Use said list of lists to provide at least 7 days advance notice of such testing, ideally with links to the details of the vulnerability in question and known vulnerable and known good code bases for as many software/hardware platforms as feasible. (Ideally list unknowns and solicit feedback as well). 3. Provide contact information for reporting test-related problems, issues, affected software versions, etc. Ideally an email address for after-action reports of data and a phone number that will be monitored during active testing for emergent reports of test-related service disruptions. 4. Conduct the test for incrementally longer periods over time. e.g. start with a 15 minute test on the first try and then run 30, 60, and multi-hour tests on later dates after addressing any reported problems during earlier tests. I think such behavior would provide the best intersection of encouraging patching/fixing while also minimizing disruption and harm to innocent third parties. Owen > On Jan 26, 2019, at 8:15 AM, Randy Bush wrote: > > i just want to make sure that folk are really in agreement with what i > think i have been hearing from a lot of strident voices here. > > if you know of an out-of-spec vulnerability or bug in deployed router, > switch, server, ... ops and researchers should exploit it as much as > possible in order to encourage fixing of the hole. > > given the number of bugs/vulns, are you comfortable that this is going > to scale well? and this is prudent when our primary responsibility is a > running internet? > > just checkin' > > randy > > > PS: if you think this, speak up so i can note to never hire or recommend > you. > > PPS: Anant Shah, Romain Fontugne, Emile Aben, Cristel Pelsser, and Randy > Bush; "Disco: Fast, Good, and Cheap Outage Detection"; TMA 2017 > ^^^^^ :) From eric.kuhnke at gmail.com Sat Jan 26 20:29:11 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sat, 26 Jan 2019 12:29:11 -0800 Subject: BGP Experiment In-Reply-To: References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: I think a better question is, once a vulnerability has become widespread public knowledge, do you expect malicious actors, malware authors and intelligence agencies of autocratic nation-states to obey a gentlemens' agreement not to exploit something? There is not a great deal of venn diagram overlap between "organizations that will pay $2 million for a zero day remote exploit on the latest version of iOS" and "people who care about whether Randy Bush recommends them for a job". On Sat, Jan 26, 2019 at 8:16 AM Randy Bush wrote: > i just want to make sure that folk are really in agreement with what i > think i have been hearing from a lot of strident voices here. > > if you know of an out-of-spec vulnerability or bug in deployed router, > switch, server, ... ops and researchers should exploit it as much as > possible in order to encourage fixing of the hole. > > given the number of bugs/vulns, are you comfortable that this is going > to scale well? and this is prudent when our primary responsibility is a > running internet? > > just checkin' > > randy > > > PS: if you think this, speak up so i can note to never hire or recommend > you. > > PPS: Anant Shah, Romain Fontugne, Emile Aben, Cristel Pelsser, and Randy > Bush; "Disco: Fast, Good, and Cheap Outage Detection"; TMA 2017 > ^^^^^ :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Sat Jan 26 21:16:46 2019 From: nick at foobar.org (Nick Hilliard) Date: Sat, 26 Jan 2019 21:16:46 +0000 Subject: BGP Experiment In-Reply-To: References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: <48892983-3f4c-2ac6-0e6e-3e1a91434870@foobar.org> Randy Bush wrote on 26/01/2019 16:15: > if you know of an out-of-spec vulnerability or bug in deployed router, > switch, server, ... ops and researchers should exploit it as much as > possible in order to encourage fixing of the hole. It came out as "please continue", but the sentiment sounded less like malice / ignorance, and more like a lack of sympathy for people who leave equipment connected to the dfz which shouldn't be connected to the dfz. > given the number of bugs/vulns, are you comfortable that this is going > to scale well? and this is prudent when our primary responsibility is a > running internet? This isn't the first time that a malformed IANA BGP attribute implementation caused service loss, and it's unlikely to be the last time either. https://sempf.net/post/On-Testing1 Some time in the future, it will be acceptable to continue the DISCO experiment along its current lines because bgp stack authors will remember the time that attribute 255 caused things to explode and their code bases will be resilient to this problem. When this happens, will it be acceptable to announce prefixes with arbitrary unassigned attributes with random contents? Where does the boundary lie between what is and what is not acceptable? Do we assign a time limit after which it's considered generally acceptable to announce attributes or capabilities which are known to cause problems? If someone were to set up a beacon system which announced prefixes with unassigned attributes and garbage content, is that a useful community service or simply a nuisance? The research people acted correctly in stopping the experiment. They could engage with the IETF IDR working group to get a temporary attribute code point rather than using 255, and it would be interesting to see results from this. But I'm not convinced that it's feasible for the internet community to assert that any particular machination of bgp announcement is out of bounds in perpetuity - in the longer term, this will promote systemic infrastructural weakness rather than doing what we all aspire to, namely creating a more resilient internet. Nick From randy at psg.com Sat Jan 26 23:37:58 2019 From: randy at psg.com (Randy Bush) Date: Sat, 26 Jan 2019 15:37:58 -0800 Subject: BGP Experiment In-Reply-To: <48892983-3f4c-2ac6-0e6e-3e1a91434870@foobar.org> References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: > I think a better question is, once a vulnerability has become > widespread public knowledge, do you expect malicious actors, malware > authors and intelligence agencies of autocratic nation-states to obey > a gentlemens' agreement not to exploit something? false anology, or maybe just a subject switch. the 'attacker' was not a nation state nor intentionally malicious. it was a naïve researcher meaning no harm. in fact, i have co-authored with ítalo, and he is a very well meaning, and usually cautious, researcher. he just fell in with a crew with a rep for ops cluelessness that needed to demonstrate it once again. to nick's point. as nick knows, i am a naggumite; one of my few disagreements with dr postel. but there is a difference between writing protocol specs/code, and with sending packets on the global internet. rigor in the former, prudence in the latter. while it is tragicaly true that someone will be willing to load mrs schächter on the cattle car, it damned well ain't gonna be me. randy From valdis.kletnieks at vt.edu Sat Jan 26 23:48:31 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 26 Jan 2019 18:48:31 -0500 Subject: BGP Experiment In-Reply-To: <42E5E5FA-19E8-4B4E-A468-0EAC5826F290@delong.com> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <42E5E5FA-19E8-4B4E-A468-0EAC5826F290@delong.com> Message-ID: <28232.1548546511@turing-police.cc.vt.edu> On Sat, 26 Jan 2019 11:37:05 -0800, Owen DeLong said: > 1. Compile a list of lists that should be notified of such experiments in > advance. Try to get the word out to as much of the community > as possible through various NOGs and other relevant industry > lists. As we've discovered after many such events, the overlap between the people who read those lists and the people running outdated vulnerable software isn't very large. From owen at delong.com Sat Jan 26 23:56:53 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Jan 2019 16:56:53 -0700 Subject: BGP Experiment In-Reply-To: <28232.1548546511@turing-police.cc.vt.edu> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <42E5E5FA-19E8-4B4E-A468-0EAC5826F290@delong.com> <28232.1548546511@turing-police.cc.vt.edu> Message-ID: <823BE40E-BDCC-4AD5-992B-AD5FAACFCE70@delong.com> > On Jan 26, 2019, at 16:48, valdis.kletnieks at vt.edu wrote: > > On Sat, 26 Jan 2019 11:37:05 -0800, Owen DeLong said: >> 1. Compile a list of lists that should be notified of such experiments in >> advance. Try to get the word out to as much of the community >> as possible through various NOGs and other relevant industry >> lists. > > As we've discovered after many such events, the overlap between the people who > read those lists and the people running outdated vulnerable software isn't very > large. > > While this may be true, if you have a better suggestion for how to reach them, I’m all ears. Otherwise, doing the best we can to disseminate the information as widely as possible seems the most practicable approach currently available. Owen From randy at psg.com Sun Jan 27 00:01:38 2019 From: randy at psg.com (Randy Bush) Date: Sat, 26 Jan 2019 16:01:38 -0800 Subject: BGP Experiment In-Reply-To: <28232.1548546511@turing-police.cc.vt.edu> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <42E5E5FA-19E8-4B4E-A468-0EAC5826F290@delong.com> <28232.1548546511@turing-police.cc.vt.edu> Message-ID: > As we've discovered after many such events, the overlap between the > people who read those lists and the people running outdated vulnerable > software isn't very large. to steal from a reply to a private message: there are a jillion folk at the edges of the net running with low end gear, low margins, and 312 pressures. *knowingly* abusing them into an update a week is just not reasonable ops behavior. and, at the other extreme, big core isps have a pre-deployment test window of six or more months. the only win here is that public embarrassment does help to get the big vendors to give us a fix with which to start the lab test cycle. bug reports to tac seem not to. randy From william.allen.simpson at gmail.com Sun Jan 27 18:21:56 2019 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 27 Jan 2019 13:21:56 -0500 Subject: BGP Experiment In-Reply-To: References: <1746129068.1322209.1548458079333@mail.yahoo.com> Message-ID: <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> On 1/26/19 6:37 PM, Randy Bush wrote: > to nick's point. as nick knows, i am a naggumite; one of my few > disagreements with dr postel. but there is a difference between > writing protocol specs/code, and with sending packets on the global > internet. rigor in the former, prudence in the latter. > OK, Randy, you peaked my interest: what is a naggumite? Many of us disagreed with Jon Postel from time to time, but he usually understood the alternative points of view. From christoffer at netravnen.de Sun Jan 27 18:32:47 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Sun, 27 Jan 2019 19:32:47 +0100 Subject: [2019/01/27] Re: BGP Experiment In-Reply-To: <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> Message-ID: <47540e6d-f06b-a971-e42f-ab4c9fec0559@netravnen.de> On 27/01/2019 19:21, William Allen Simpson wrote: > OK, Randy, you peaked my interest: what is a naggumite? ... (scouring the internet) o https://www.nanog.org/mailinglist/mailarchives/old_archive/2006-01/msg00250.html o https://en.wikipedia.org/wiki/Erik_Naggum o https://www.dictionary.com/browse/-ite ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From juicewvu at gmail.com Fri Jan 25 22:41:51 2019 From: juicewvu at gmail.com (Josh Smith) Date: Fri, 25 Jan 2019 17:41:51 -0500 Subject: Comcast email contact Message-ID: Can someone from comcast email please contact me off-list. You all appear to be black holing email received from $DAYJOBS domain. Your support from indicates we are not blocked. Our logs indicate the mail is accepted for delivery but they never make it to users inboxes, or junk/spam folders. Thanks, Josh Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Sat Jan 26 01:06:41 2019 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Fri, 25 Jan 2019 20:06:41 -0500 Subject: Quick Script to check the uptime of ASR920's In-Reply-To: References: Message-ID: It's worth mentioning that's it's not limited to just the cosmetic issue of interface counters/snmp counters. - I've had multiple instances of 920 interfaces getting stuck in their previous operational state. Unplugging-replugging/shut/no-shut doesn't change anything. - The 920 fails to process traffic towards very specific IPs. That one is a pain to debug. You can reach the IP directly from the device but flows through the device are just dropped (also saw the same behavior on 903 with RSP3) - ARP under a BDI show up and are re-learned after a clear but traffic towards those IP do not work through or sourced from the 920. - One 920 started to show the above described symptoms, was rebooted and failed to back up. ISIS went up, cannot ping any of the P2P. That said, uptime should definitely be monitored through your central NMS-flavor system. ;) On Fri, Jan 25, 2019 at 7:45 PM Erik Sundberg wrote: > It was a script I created in regards to this thread below... Interface > counters and some other things stop working after a Cisco ASR920 is up 889 > days.... Fun Fun > > https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html > > > -----Original Message----- > From: Mel Beckman > Sent: Friday, January 25, 2019 6:39 PM > To: Erik Sundberg > Cc: nanog at nanog.org > Subject: Re: Quick Script to check the uptime of ASR920's > > Erik, > > That’s a nice little script. Thanks! > > So you want a warning if a router hasn’t been rebooted in a long time? > Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, > pretty much ever. Usually I want to know if the uptime suddenly became less > than the most recent uptime, indicting a possibly unplanned reboot. > > -mel > > > On Jan 25, 2019, at 4:29 PM, Erik Sundberg > wrote: > > > > All, > > > > I just created a quick script to check the uptime of a ASR920 via SNMP > > if you have a fairly long list of devices. It's a simple bash script > > and snmpwalk version 2c. Figured I would share it with you. Happy > > Friday > > > > Grab the code from GitHub: > > https://github.com/esundberg/CiscoRouterUptime > > It's a quick and dirty script and my first repo on github. Let me know > if there any issues with it. > > > > > > Output Format in CSV > > DeviceName, IP, Uptime in Days, OK/Warning > > > > I set my warning to 800 Days, you can change this in the code > > > > > > ASR920list.txt > > ------------- > > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, > > 192.168.28.2, SuperSecretSNMPKey ~~~~snip you get the idea~~~~ > > > > > > Output > > > > [user at Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, > > 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING > > ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, > > 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, > > 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK > > ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, > > OK ASR920-4.CHI1, 192.168.21.6, 142, OK > > > > > > > > ________________________________ > > > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.lists at gmail.com Sun Jan 27 16:06:38 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Sun, 27 Jan 2019 11:06:38 -0500 Subject: Process for deploying new BGP attributes (experimentally or otherwise) Message-ID: Following our recent attempts to experiment with potential use of BGP attributes, I would like to understand better the desired process for using new BGP attributes. As mentioned earlier, we investigate currently one usage of BGP attributes for improving BGP security - specifically, adoption of RPKI. I also have some future ideas on other ways BGP attributes may be useful to improve BGP security; and surely other applications, security or otherwise, may exist. So I think we need an acceptable process to do it. Indeed, while we aborted that experiment, I doubt that the right conclusion is that one should simply never use a new BGP attribute... And I even hope that the community would want us to complete our research, to see if the particular approach we evaluate may indeed be beneficial. I think that these sentiments were also expressed by many members of this community. So: - Is there some document discussing the desired (best practice) process? [if not, maybe such document should be written?] - We used unassigned attribute. Should one always assign an attribute before using it? That's a possibility, but has some `costs' - and may yet fail to prevent problems to some non-conforming networks. - Is there an agreed-upon list of the forums and mailing lists on which one should warn in advance about such planned announcements, and the details that should be included? Thanks, Amir -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Publications and projects: https://www.researchgate.net/profile/Amir_Herzberg/contributions Lecture notes in intro to cyber: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sun Jan 27 18:42:40 2019 From: randy at psg.com (Randy Bush) Date: Sun, 27 Jan 2019 10:42:40 -0800 Subject: BGP Experiment In-Reply-To: <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> Message-ID: > OK, Randy, you peaked my interest: what is a naggumite? erik naggum, an early and strong proponent of being strict. you've been around long enough you should remember erik. > Many of us disagreed with Jon Postel from time to time, but he usually > understood the alternative points of view. oh, i have been dealing with network cowboys (and yes, unsurprisingly pretty universally boys) for enough decades to mostly understand. but the lack of prudence and level of irresponsibility occasionally surprise me. randy From nick at foobar.org Sun Jan 27 21:32:15 2019 From: nick at foobar.org (Nick Hilliard) Date: Sun, 27 Jan 2019 21:32:15 +0000 Subject: BGP Experiment In-Reply-To: <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> Message-ID: William Allen Simpson wrote on 27/01/2019 18:21: > OK, Randy, you peaked my interest: what is a naggumite? http://naggum.no/worse-is-better.html a.k.a. "perfect is the enemy of good enough". Nick From nanog at ics-il.net Sun Jan 27 23:44:50 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 27 Jan 2019 17:44:50 -0600 (CST) Subject: Comcast email contact In-Reply-To: References: Message-ID: <1708638265.5478.1548632686264.JavaMail.mhammett@ThunderFuck> Please move this to the Mail Ops mailing list. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Josh Smith" To: nanog at nanog.org Sent: Friday, January 25, 2019 4:41:51 PM Subject: Comcast email contact Can someone from comcast email please contact me off-list. You all appear to be black holing email received from $DAYJOBS domain. Your support from indicates we are not blocked. Our logs indicate the mail is accepted for delivery but they never make it to users inboxes, or junk/spam folders. Thanks, Josh Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Mon Jan 28 11:14:48 2019 From: Brian at ampr.org (Brian Kantor) Date: Mon, 28 Jan 2019 03:14:48 -0800 Subject: BGP Experiment In-Reply-To: <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> References: <1746129068.1322209.1548458079333@mail.yahoo.com> <9a7f250b-ada8-a417-2b43-372b4f4710b0@gmail.com> Message-ID: <20190128111448.GA94037@meow.BKantor.net> On Sun, Jan 27, 2019 at 01:21:56PM -0500, William Allen Simpson wrote: > On 1/26/19 6:37 PM, Randy Bush wrote: > > to nick's point. as nick knows, i am a naggumite; one of my few > > disagreements with dr postel. but there is a difference between > > writing protocol specs/code, and with sending packets on the global > > internet. rigor in the former, prudence in the latter. > > > OK, Randy, you peaked my interest: what is a naggumite? > > Many of us disagreed with Jon Postel from time to time, but he > usually understood the alternative points of view. I fondly recall that Erik could be quite acerbic, as I think is well exemplified by this: "If I had to deal with you professionally, I would have told you to hold the onions and give me large fries." - Erik Naggum Unfortunately, I don't recall to whom he said that; I suppose I am lucky that it wasn't me. - Brian From Courtney_Smith at comcast.com Mon Jan 28 18:47:29 2019 From: Courtney_Smith at comcast.com (Smith, Courtney) Date: Mon, 28 Jan 2019 18:47:29 +0000 Subject: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24 Message-ID: Verizon (AS701) is currently originating 68.80.240.0/24. This is part of 68.80.0.0/13 allocated to Comcast (AS7922). We have reached out to Verizon to stop the announcement. Until that occurs, we request you block the 68.80.240.0/24 announcement. Thanks. route-views>show clock 18:35:15.335 UTC Mon Jan 28 2019 route-views>show ip bgp 68.80.240.0/24 longer-prefixes BGP table version is 34517149, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 68.80.240.0/24 203.62.252.83 0 1221 4637 701 i * 162.250.137.254 0 4901 6079 3257 701 i * 207.172.6.1 0 0 6079 3257 701 i * 202.232.0.2 0 2497 701 i * 208.51.134.254 0 0 3549 3356 701 i * 89.149.178.10 10 0 3257 701 i * 144.228.241.130 80 0 1239 701 i * 212.66.96.126 0 20912 174 701 i * 132.198.255.253 0 1351 6939 701 i * 207.172.6.20 0 0 6079 1299 701 i * 202.93.8.242 0 24441 3491 3491 701 i * 208.74.64.40 0 19214 3257 701 i * 195.208.112.161 0 3277 3267 1299 701 i *> 137.39.3.55 0 701 i * 134.222.87.1 18750 0 286 701 i * 203.181.248.168 0 7660 2516 701 i * 217.192.89.50 0 3303 3320 701 i * 114.31.199.1 0 4826 1299 701 i * 209.124.176.223 0 101 101 2914 701 i * 193.0.0.56 0 3333 1273 701 i * 91.218.184.60 0 0 49788 174 701 i * 37.139.139.0 0 57866 701 i * 94.142.247.3 0 0 8283 57866 701 i * 12.0.1.63 0 7018 701 i * 194.85.40.15 0 0 3267 1299 701 i * 162.251.163.2 0 53767 3257 701 i * 198.58.198.255 0 1403 1299 701 i * 198.58.198.254 0 1403 1299 701 i * 154.11.12.212 0 0 852 1299 701 i * 173.205.57.234 0 53364 3257 701 i * 206.24.210.80 0 3561 209 701 i * 140.192.8.16 0 54728 20130 6939 701 i * 64.71.137.241 0 6939 701 i route-views> -- Courtney Smith Network Engineer Comcast TPX http://as7922.peeringdb.com https://www.comcasttechnologysolutions.com From morrowc.lists at gmail.com Mon Jan 28 18:59:31 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 28 Jan 2019 10:59:31 -0800 Subject: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24 In-Reply-To: References: Message-ID: Guessing there's an awesome LOA in someone's file folder for this event. On Mon, Jan 28, 2019 at 10:48 AM Smith, Courtney wrote: > Verizon (AS701) is currently originating 68.80.240.0/24. This is part of > 68.80.0.0/13 allocated to Comcast (AS7922). We have reached out to > Verizon to stop the announcement. Until that occurs, we request you block > the 68.80.240.0/24 announcement. Thanks. > > route-views>show clock > 18:35:15.335 UTC Mon Jan 28 2019 > route-views>show ip bgp 68.80.240.0/24 longer-prefixes > BGP table version is 34517149, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale, m multipath, b backup-path, f > RT-Filter, > x best-external, a additional-path, c RIB-compressed, > Origin codes: i - IGP, e - EGP, ? - incomplete > RPKI validation codes: V valid, I invalid, N Not found > > Network Next Hop Metric LocPrf Weight Path > * 68.80.240.0/24 203.62.252.83 0 1221 4637 > 701 i > * 162.250.137.254 0 4901 6079 > 3257 701 i > * 207.172.6.1 0 0 6079 3257 > 701 i > * 202.232.0.2 0 2497 701 i > * 208.51.134.254 0 0 3549 3356 > 701 i > * 89.149.178.10 10 0 3257 701 i > * 144.228.241.130 80 0 1239 701 i > * 212.66.96.126 0 20912 174 > 701 i > * 132.198.255.253 0 1351 6939 > 701 i > * 207.172.6.20 0 0 6079 1299 > 701 i > * 202.93.8.242 0 24441 3491 > 3491 701 i > * 208.74.64.40 0 19214 3257 > 701 i > * 195.208.112.161 0 3277 3267 > 1299 701 i > *> 137.39.3.55 0 701 i > * 134.222.87.1 18750 0 286 701 i > * 203.181.248.168 0 7660 2516 > 701 i > * 217.192.89.50 0 3303 3320 > 701 i > * 114.31.199.1 0 4826 1299 > 701 i > * 209.124.176.223 0 101 101 2914 > 701 i > * 193.0.0.56 0 3333 1273 > 701 i > * 91.218.184.60 0 0 49788 174 > 701 i > * 37.139.139.0 0 57866 701 i > * 94.142.247.3 0 0 8283 57866 > 701 i > * 12.0.1.63 0 7018 701 i > * 194.85.40.15 0 0 3267 1299 > 701 i > * 162.251.163.2 0 53767 3257 > 701 i > * 198.58.198.255 0 1403 1299 > 701 i > * 198.58.198.254 0 1403 1299 > 701 i > * 154.11.12.212 0 0 852 1299 701 > i > * 173.205.57.234 0 53364 3257 > 701 i > * 206.24.210.80 0 3561 209 701 > i > * 140.192.8.16 0 54728 20130 > 6939 701 i > * 64.71.137.241 0 6939 701 i > route-views> > > -- > Courtney Smith > Network Engineer > Comcast TPX > http://as7922.peeringdb.com > https://www.comcasttechnologysolutions.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Mon Jan 28 19:08:09 2019 From: job at ntt.net (Job Snijders) Date: Mon, 28 Jan 2019 20:08:09 +0100 Subject: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24 In-Reply-To: References: Message-ID: <20190128190809.GE91214@hanna.meerval.net> Dear Courtney, (This suggestion does not address the immediate issue at hand) On Mon, Jan 28, 2019 at 06:47:29PM +0000, Smith, Courtney wrote: > Verizon (AS701) is currently originating 68.80.240.0/24. This is part > of 68.80.0.0/13 allocated to Comcast (AS7922). We have reached out to > Verizon to stop the announcement. Until that occurs, we request you > block the 68.80.240.0/24 announcement. Thanks. Can you create RPKI ROAs for the 68.80.0.0/13? That is the most unambiguous, programmatically verifiable statement Comcast can make about what the rouing intentions of its prefixes are. Kind regards, Job From me at anuragbhatia.com Mon Jan 28 20:34:44 2019 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 29 Jan 2019 02:04:44 +0530 Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Message-ID: I recently had an experience of getting them to participate at local IX in Mumbai for which I am volunteering and experience was overall bad. Long delays in discussion to finally the cross-connects. During the process, we were asked for providing "our end IP" even when they told us that they no intention to peer at the route server. Somehow the process was confusing peering at IX Vs PNI. Not sure for other locations but in India, they have a process where they expect IX operator to coordinate in setting up bilateral BGP sessions which I personally feel isn't fair in the world of peeringdb, website and email contacts! On Fri, Jan 25, 2019 at 1:45 AM Darin Steffl wrote: > We've been waiting since December 2017 with multiple followup. Their most > recent response said that February would probably be when they turn us up, > 15 months after our first request. > > On Thu, Jan 24, 2019, 1:46 PM Mike Hammett >> Let us know your success as well. I'll hold off following up on my >> requests until I see that other people are successful. I don't want to >> contribute to flooding them with requests. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ------------------------------ >> *From: *"Tom Beecher" >> *To: *"Jason Lixfeld" >> *Cc: *"North American Network Operators' Group" >> *Sent: *Thursday, January 24, 2019 1:38:51 PM >> *Subject: *Re: Amazon Peering >> >> Thanks Jason. I'll have my peering team take another crack at reaching >> out and see what happens. Appreciate it! >> >> On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld >> wrote: >> >>> We circled back with them yesterday on a request we made in late >>> November where at the time they said they wouldn’t be turned up until 2019 >>> due to holiday network change freeze. >>> >>> They responded within about 4 hours, thanked us for our patience and >>> understanding and said we should expect them to be turned up in about 6 >>> weeks, which is apparently their typical timing. >>> >>> On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: >>> >>> I hate to necro-thread , but has anyone seen any movement from Amazon on >>> this? I just got a Strongly Worded Message about it, and according to my >>> peering team , it's been radio silence for months. >>> >>> >>> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG >>> wrote: >>> >>>> This is a note I received on Oct18 when checking on a peering request >>>> submitted on Aug7.. >>>> >>>> “Apologies for the delays here. We have temporarily frozen IX peering >>>> as we revise some of our automation processes. I’m hopeful this will be >>>> unblocked by early November. Thank you for your continued patience.” >>>> >>>> On Nov 24, 2018, at 10:59, Darin Steffl >>>> wrote: >>>> >>>> It seems wasteful for Amazon to connect to an IX but then ignore >>>> peering requests for a year. >>>> >>>> They have 40G of connectivity but are unresponsive. I'll try emailing >>>> all the other contacts listed in peeringdb. >>>> >>>> Thanks >>>> >>>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >>> >>>>> I've e-mailed my contacts there a couple times on people's behalf. No >>>>> response yet. >>>>> >>>>> It seems like a lot of organizations need 1 more person in their >>>>> peering departments. >>>>> >>>>> >>>>> >>>>> ----- >>>>> Mike Hammett >>>>> Intelligent Computing Solutions >>>>> http://www.ics-il.com >>>>> >>>>> Midwest-IX >>>>> http://www.midwest-ix.com >>>>> >>>>> ------------------------------ >>>>> *From: *"Darin Steffl" >>>>> *To: *"North American Network Operators' Group" >>>>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>>>> *Subject: *Amazon Peering >>>>> >>>>> Hey all, >>>>> >>>>> Does anyone have a direct contact to get a peering session established >>>>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >>>>> this Sept and Nov with no response. >>>>> >>>>> I sent to peering at amazon.com and received one automated response back >>>>> so I know they received my email but nothing since. >>>>> >>>>> >>>>> >>>>> -- >>>>> Darin Steffl >>>>> Minnesota WiFi >>>>> www.mnwifi.com >>>>> 507-634-WiFi >>>>> Like us on Facebook >>>>> >>>>> >>>>> >>> >> -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Jan 28 21:25:14 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 28 Jan 2019 13:25:14 -0800 Subject: Since today is a day ending in "Y" it's route hijack day? (Excelcom - as24203 please call) Message-ID: Howdy! ExcelCom, you are being difficult to reach today AND you are originating prefixes which are not yours to originate: * 176.119.0.0/24 me 24203 I * 176.119.1.0/24 me 24203 I * 176.119.2.0/24 me 24203 I * 176.119.3.0/24 me 24203 I * 176.119.4.0/24 me 24203 I * 176.119.5.0/24 me 24203 I * 176.119.6.0/24 me 24203 I * 176.119.7.0/24 me 24203 I * 176.119.8.0/22 me 24203 I * 176.119.12.0/22 me 24203 I These prefixes are part of: inetnum: 176.119.0.0 - 176.119.15.255 netname: VSERVER-NET country: UA org: ORG-FGLP1-RIPE admin-c: LPG-RIPE tech-c: LPG-RIPE tech-c: VSRV-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: VSERVER-MNT mnt-routes: VSERVER-MNT mnt-domains: VSERVER-MNT created: 2012-06-06T09:08:16Z last-modified: 2017-06-06T13:41:24Z source: RIPE # Filtered sponsoring-org: ORG-ML410-RIPE Looking at IRR data for AS24203: $ ./bgpq3 AS24203 | grep 176 $ ./bgpq3 AS24203 | grep 140 ip prefix-list NN permit 140.213.0.0/16 but the proper owner does have this content in their IRR data: $ ./bgpq3 AS58271 | grep 176 ip prefix-list NN permit 176.119.0.0/20 ip prefix-list NN permit 176.119.0.0/21 ip prefix-list NN permit 176.119.0.0/22 ip prefix-list NN permit 176.119.0.0/24 ip prefix-list NN permit 176.119.1.0/24 ip prefix-list NN permit 176.119.2.0/24 ip prefix-list NN permit 176.119.3.0/24 ip prefix-list NN permit 176.119.4.0/24 ip prefix-list NN permit 176.119.5.0/24 ip prefix-list NN permit 176.119.6.0/24 ip prefix-list NN permit 176.119.7.0/24 ip prefix-list NN permit 176.119.8.0/22 ip prefix-list NN permit 176.119.12.0/22 Could you please stop breaking someone's internet? :) -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Courtney_Smith at comcast.com Mon Jan 28 21:28:05 2019 From: Courtney_Smith at comcast.com (Smith, Courtney) Date: Mon, 28 Jan 2019 21:28:05 +0000 Subject: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24 In-Reply-To: References: Message-ID: <97201952-D907-42DF-BEB4-29D78A7C1CF5@Cable.Comcast.com> Verizon has resolved the issue. Thanks everyone. On 1/28/19, 1:49 PM, "NANOG on behalf of Smith, Courtney" wrote: Verizon (AS701) is currently originating 68.80.240.0/24. This is part of 68.80.0.0/13 allocated to Comcast (AS7922). We have reached out to Verizon to stop the announcement. Until that occurs, we request you block the 68.80.240.0/24 announcement. Thanks. route-views>show clock 18:35:15.335 UTC Mon Jan 28 2019 route-views>show ip bgp 68.80.240.0/24 longer-prefixes BGP table version is 34517149, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 68.80.240.0/24 203.62.252.83 0 1221 4637 701 i * 162.250.137.254 0 4901 6079 3257 701 i * 207.172.6.1 0 0 6079 3257 701 i * 202.232.0.2 0 2497 701 i * 208.51.134.254 0 0 3549 3356 701 i * 89.149.178.10 10 0 3257 701 i * 144.228.241.130 80 0 1239 701 i * 212.66.96.126 0 20912 174 701 i * 132.198.255.253 0 1351 6939 701 i * 207.172.6.20 0 0 6079 1299 701 i * 202.93.8.242 0 24441 3491 3491 701 i * 208.74.64.40 0 19214 3257 701 i * 195.208.112.161 0 3277 3267 1299 701 i *> 137.39.3.55 0 701 i * 134.222.87.1 18750 0 286 701 i * 203.181.248.168 0 7660 2516 701 i * 217.192.89.50 0 3303 3320 701 i * 114.31.199.1 0 4826 1299 701 i * 209.124.176.223 0 101 101 2914 701 i * 193.0.0.56 0 3333 1273 701 i * 91.218.184.60 0 0 49788 174 701 i * 37.139.139.0 0 57866 701 i * 94.142.247.3 0 0 8283 57866 701 i * 12.0.1.63 0 7018 701 i * 194.85.40.15 0 0 3267 1299 701 i * 162.251.163.2 0 53767 3257 701 i * 198.58.198.255 0 1403 1299 701 i * 198.58.198.254 0 1403 1299 701 i * 154.11.12.212 0 0 852 1299 701 i * 173.205.57.234 0 53364 3257 701 i * 206.24.210.80 0 3561 209 701 i * 140.192.8.16 0 54728 20130 6939 701 i * 64.71.137.241 0 6939 701 i route-views> -- Courtney Smith Network Engineer Comcast TPX http://as7922.peeringdb.com https://www.comcasttechnologysolutions.com From Courtney_Smith at comcast.com Mon Jan 28 21:32:20 2019 From: Courtney_Smith at comcast.com (Smith, Courtney) Date: Mon, 28 Jan 2019 21:32:20 +0000 Subject: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24 Message-ID: On 1/28/19, 2:08 PM, "Job Snijders" wrote: Can you create RPKI ROAs for the 68.80.0.0/13? That is the most unambiguous, programmatically verifiable statement Comcast can make about what the rouing intentions of its prefixes are. Job, Working on plans for 2019. From beecher at beecher.cc Mon Jan 28 21:54:41 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 28 Jan 2019 16:54:41 -0500 Subject: Amazon Peering In-Reply-To: <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Message-ID: Mike- Definitely moving forward now. Someone from Amazon was working with my peering group and things started coming up this weekend, so it seems like they're catching up pretty good now. On Thu, Jan 24, 2019 at 2:45 PM Mike Hammett wrote: > Let us know your success as well. I'll hold off following up on my > requests until I see that other people are successful. I don't want to > contribute to flooding them with requests. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Tom Beecher" > *To: *"Jason Lixfeld" > *Cc: *"North American Network Operators' Group" > *Sent: *Thursday, January 24, 2019 1:38:51 PM > *Subject: *Re: Amazon Peering > > Thanks Jason. I'll have my peering team take another crack at reaching out > and see what happens. Appreciate it! > > On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld > wrote: > >> We circled back with them yesterday on a request we made in late November >> where at the time they said they wouldn’t be turned up until 2019 due to >> holiday network change freeze. >> >> They responded within about 4 hours, thanked us for our patience and >> understanding and said we should expect them to be turned up in about 6 >> weeks, which is apparently their typical timing. >> >> On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: >> >> I hate to necro-thread , but has anyone seen any movement from Amazon on >> this? I just got a Strongly Worded Message about it, and according to my >> peering team , it's been radio silence for months. >> >> >> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG >> wrote: >> >>> This is a note I received on Oct18 when checking on a peering request >>> submitted on Aug7.. >>> >>> “Apologies for the delays here. We have temporarily frozen IX peering as >>> we revise some of our automation processes. I’m hopeful this will be >>> unblocked by early November. Thank you for your continued patience.” >>> >>> On Nov 24, 2018, at 10:59, Darin Steffl wrote: >>> >>> It seems wasteful for Amazon to connect to an IX but then ignore peering >>> requests for a year. >>> >>> They have 40G of connectivity but are unresponsive. I'll try emailing >>> all the other contacts listed in peeringdb. >>> >>> Thanks >>> >>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >> >>>> I've e-mailed my contacts there a couple times on people's behalf. No >>>> response yet. >>>> >>>> It seems like a lot of organizations need 1 more person in their >>>> peering departments. >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> Midwest-IX >>>> http://www.midwest-ix.com >>>> >>>> ------------------------------ >>>> *From: *"Darin Steffl" >>>> *To: *"North American Network Operators' Group" >>>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>>> *Subject: *Amazon Peering >>>> >>>> Hey all, >>>> >>>> Does anyone have a direct contact to get a peering session established >>>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >>>> this Sept and Nov with no response. >>>> >>>> I sent to peering at amazon.com and received one automated response back >>>> so I know they received my email but nothing since. >>>> >>>> >>>> >>>> -- >>>> Darin Steffl >>>> Minnesota WiFi >>>> www.mnwifi.com >>>> 507-634-WiFi >>>> Like us on Facebook >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bswinnerton at gmail.com Mon Jan 28 23:32:45 2019 From: bswinnerton at gmail.com (Brooks Swinnerton) Date: Mon, 28 Jan 2019 18:32:45 -0500 Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Message-ID: I also saw sessions come up this weekend, no routes yet though. On Mon, Jan 28, 2019 at 4:56 PM Tom Beecher wrote: > Mike- > > Definitely moving forward now. Someone from Amazon was working with my > peering group and things started coming up this weekend, so it seems like > they're catching up pretty good now. > > On Thu, Jan 24, 2019 at 2:45 PM Mike Hammett wrote: > >> Let us know your success as well. I'll hold off following up on my >> requests until I see that other people are successful. I don't want to >> contribute to flooding them with requests. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ------------------------------ >> *From: *"Tom Beecher" >> *To: *"Jason Lixfeld" >> *Cc: *"North American Network Operators' Group" >> *Sent: *Thursday, January 24, 2019 1:38:51 PM >> *Subject: *Re: Amazon Peering >> >> Thanks Jason. I'll have my peering team take another crack at reaching >> out and see what happens. Appreciate it! >> >> On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld >> wrote: >> >>> We circled back with them yesterday on a request we made in late >>> November where at the time they said they wouldn’t be turned up until 2019 >>> due to holiday network change freeze. >>> >>> They responded within about 4 hours, thanked us for our patience and >>> understanding and said we should expect them to be turned up in about 6 >>> weeks, which is apparently their typical timing. >>> >>> On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: >>> >>> I hate to necro-thread , but has anyone seen any movement from Amazon on >>> this? I just got a Strongly Worded Message about it, and according to my >>> peering team , it's been radio silence for months. >>> >>> >>> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG >>> wrote: >>> >>>> This is a note I received on Oct18 when checking on a peering request >>>> submitted on Aug7.. >>>> >>>> “Apologies for the delays here. We have temporarily frozen IX peering >>>> as we revise some of our automation processes. I’m hopeful this will be >>>> unblocked by early November. Thank you for your continued patience.” >>>> >>>> On Nov 24, 2018, at 10:59, Darin Steffl >>>> wrote: >>>> >>>> It seems wasteful for Amazon to connect to an IX but then ignore >>>> peering requests for a year. >>>> >>>> They have 40G of connectivity but are unresponsive. I'll try emailing >>>> all the other contacts listed in peeringdb. >>>> >>>> Thanks >>>> >>>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >>> >>>>> I've e-mailed my contacts there a couple times on people's behalf. No >>>>> response yet. >>>>> >>>>> It seems like a lot of organizations need 1 more person in their >>>>> peering departments. >>>>> >>>>> >>>>> >>>>> ----- >>>>> Mike Hammett >>>>> Intelligent Computing Solutions >>>>> http://www.ics-il.com >>>>> >>>>> Midwest-IX >>>>> http://www.midwest-ix.com >>>>> >>>>> ------------------------------ >>>>> *From: *"Darin Steffl" >>>>> *To: *"North American Network Operators' Group" >>>>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>>>> *Subject: *Amazon Peering >>>>> >>>>> Hey all, >>>>> >>>>> Does anyone have a direct contact to get a peering session established >>>>> with Amazon at an IX? I sent a peering request Dec 2017 and two more times >>>>> this Sept and Nov with no response. >>>>> >>>>> I sent to peering at amazon.com and received one automated response back >>>>> so I know they received my email but nothing since. >>>>> >>>>> >>>>> >>>>> -- >>>>> Darin Steffl >>>>> Minnesota WiFi >>>>> www.mnwifi.com >>>>> 507-634-WiFi >>>>> Like us on Facebook >>>>> >>>>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.raymo at gmail.com Tue Jan 29 16:25:32 2019 From: brad.raymo at gmail.com (Bradley Raymo) Date: Tue, 29 Jan 2019 09:25:32 -0700 Subject: NANOG 75 Message-ID: NANOG Community, The NANOG 75 Agenda is published at http://www.cvent.com/d/1bqspy/16K and available as an iCal Feed . The Program Committee has worked closely with our speakers to develop a first-rate program and we encourage all attendees to enjoy the whole conference. As we review submitted content, minor changes to the agenda are possible and will be updated in the online feed. Thank you to the many members of our community who submitted interesting content for NANOG 75! Over 700 attendees have registered and the NANOG family looks forward to welcoming all of you to San Francisco. Useful Information - NANOG 75 General Information and Registration: http://www.cvent.com/d/1bqspy - NANOG 75 Agenda: http://www.cvent.com/d/1bqspy/16K - Hotel Room Block(s) Information: http://www.cvent.com/d/1bqspy/8K - Reminder, registration is required to participate in the NANOG 75 Hackathon: http://www.cvent.com/d/1bqspy/4K - A welcome message that will be sent to registered NANOG 75 attendees a week before the conference will provide more information on scheduled events and applications to help you to make the most of your time in San Francisco. Safe travels and see you soon. Sincerely, Brad Raymo NANOG PC -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaurisrm23 at hotmail.com Tue Jan 29 16:30:05 2019 From: amaurisrm23 at hotmail.com (Amauris Rodriguez Martinez) Date: Tue, 29 Jan 2019 16:30:05 +0000 Subject: AT&T Fiber Outage in Holmdel, NJ Message-ID: Did anybody here have fiber issues yesterday night about 9:30 pm? Best Regards, Amauris Get Outlook for iOS -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Jan 29 17:43:33 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 29 Jan 2019 09:43:33 -0800 Subject: AT&T Fiber Outage in Holmdel, NJ In-Reply-To: References: Message-ID: commercial or residential? I have not seen or heard anything about this but paged our AT&T contact asking if anything going on.. On Tue, Jan 29, 2019 at 9:11 AM Amauris Rodriguez Martinez < amaurisrm23 at hotmail.com> wrote: > Did anybody here have fiber issues yesterday night about 9:30 pm? > > Best Regards, > Amauris > > Get Outlook for iOS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Tue Jan 29 23:34:32 2019 From: warren at kumari.net (Warren Kumari) Date: Tue, 29 Jan 2019 18:34:32 -0500 Subject: =?UTF-8?Q?NIST_looking_for_comments_on_=22Secure_Interdomain_Tra?= =?UTF-8?Q?ffic_Exchange_=E2=80=93_BGP_Robustness_and_DDoS_Mitigation=3A_NIST_R?= =?UTF-8?Q?eleases_Draft_NIST_SP_800=2D189=22?= Message-ID: Hey all, NIST is looking for comments on "Secure Interdomain Traffic Exchange – BGP Robustness and DDoS Mitigation: NIST Releases Draft NIST SP 800-189" They recently extended the deadline for comments to March 15, 2019, and so it looks like they would really like feedback.... ----- From: NIST Computer Security Division Subject: Secure Interdomain Traffic Exchange – BGP Robustness and DDoS Mitigation: NIST Releases Draft NIST SP 800-189 NIST has released Draft NIST Special Publication (SP) 800-189, Secure Interdomain Traffic Exchange: BGP Robustness and DDoS Mitigation, which provides technical guidance and recommendations for deploying technologies that improve the security of interdomain traffic exchange. The document focuses on securing the interdomain routing control (i.e., Border Gateway Protocol) traffic as well as mitigating Distributed Denial of Service (DDoS) attacks. It is intended to guide information security officers and managers of federal enterprise networks. The guidance also applies to the network services of hosting providers (e.g., cloud-based applications and service hosting) and Internet Service Providers (ISPs) when they are used to support federal IT systems. The guidance will also be useful for enterprise and transit network operators and equipment vendors in general. A public comment period for this document is open until March 15, 2019. Email Comments to: sp800-189 at nist.gov Publication Details: https://csrc.nist.gov/publications/detail/sp/800-189/draft CSRC Update: https://csrc.nist.gov/news/2018/nist-releases-draft-sp-800-189-for-comment Warren. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kac at gmail.com Wed Jan 30 01:22:44 2019 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Tue, 29 Jan 2019 19:22:44 -0600 Subject: Call for Presentations - CHI-NOG 09 (May 23rd) Message-ID: CHI-NOG 09 - (Chicago Network Operators Group) May 23rd, 2019, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration and providing networking opportunities. CHI-NOG will be hosting its ninth annual conference on May 23rd, 2019 in downtown Chicago. For more information on the conference please see event's page ( http://chinog.org/chi-nog-09/). The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with the focus on the following topics: * Network Automation / DevOps / CI-CD * Edge Computing and Networking * Interconnection/Peering * 5G Mobile * Open Networking * Overlay Networking Technologies * Low Latency Networks/Financial Networks * Network Security / DDoS * Academic Research in Networking and Related Infrastructure Fields. * Internet Monitoring * AI in Network Analytics * Advanced BGP/MPLS Technologies * Optical Networking/Data Center Interconnect * Content Delivery Networks (CDNs) * Software Defined Networking (SDN) * Network Traffic Engineering (TE) * Data Center Fabric * Tutorials Session Format Each presentation is 30 minutes, which includes a question and answer time. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. Key Dates 3/25/2019 - Presentation Abstract Submission Deadline 4/02/2019 - Program Committee's Selection Decision 4/15/2019 - Full Presentation Slides Submission Deadline 5/23/2019 - Conference Submission Please submit presentation’s abstract proposal by filling out the submission form at http://chinog.org/chi-nog-09/abstract-submission/ . Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. All accepted speakers will receive complimentary tickets to the conference. For past presentation please see the archives at http://chinog.org/presentation-archive/. The program committee is looking forward to your submission and attendance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Wed Jan 30 13:52:09 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Wed, 30 Jan 2019 08:52:09 -0500 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY Message-ID: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> Hi, In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. Thanks. From bryan at shout.net Wed Jan 30 14:03:02 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 30 Jan 2019 08:03:02 -0600 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> Message-ID: <53920e2a-3b19-7dcf-5fb8-6251f1d442df@shout.net> On 1/30/19 7:52 AM, Jason Lixfeld wrote: > Hi, > > In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. > > This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. > > The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. > > If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. > > I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. > > Thanks. > They're not the only ones ... out of all of our peers on that exchange, ~30% haven't updated as of this writing. I'm a little reluctant to pull our old address until penetration is a little higher. From amaurisrm23 at hotmail.com Wed Jan 30 00:38:04 2019 From: amaurisrm23 at hotmail.com (Amauris Rodriguez Martinez) Date: Wed, 30 Jan 2019 00:38:04 +0000 Subject: AT&T Fiber Outage in Holmdel, NJ In-Reply-To: References: , Message-ID: Hi Mehmet, Commercial; forgot to mention fiber issues related to AVPN service, specifically peering to ASN 13979. Best Regards, Amauris Get Outlook for iOS ________________________________ From: Mehmet Akcin Sent: Tuesday, January 29, 2019 12:43 To: Amauris Rodriguez Martinez Cc: NANOG Subject: Re: AT&T Fiber Outage in Holmdel, NJ commercial or residential? I have not seen or heard anything about this but paged our AT&T contact asking if anything going on.. On Tue, Jan 29, 2019 at 9:11 AM Amauris Rodriguez Martinez > wrote: Did anybody here have fiber issues yesterday night about 9:30 pm? Best Regards, Amauris Get Outlook for iOS -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at digitalocean.com Wed Jan 30 15:45:29 2019 From: luca at digitalocean.com (Luca Salvatore) Date: Wed, 30 Jan 2019 10:45:29 -0500 Subject: Amazon Peering In-Reply-To: References: <1966321065.11280.1543077528570.JavaMail.mhammett@ThunderFuck> <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Message-ID: Similar experiences here with Amazon. Initially had semi-regular responses from their peering team, they issued LOAs, I ordered the x-connects and then radio silence for months. At the point now where I'm disconnecting x-connects since it's a waste of money. On Tue, Jan 29, 2019 at 10:49 AM Brooks Swinnerton wrote: > I also saw sessions come up this weekend, no routes yet though. > > On Mon, Jan 28, 2019 at 4:56 PM Tom Beecher wrote: > >> Mike- >> >> Definitely moving forward now. Someone from Amazon was working with my >> peering group and things started coming up this weekend, so it seems like >> they're catching up pretty good now. >> >> On Thu, Jan 24, 2019 at 2:45 PM Mike Hammett wrote: >> >>> Let us know your success as well. I'll hold off following up on my >>> requests until I see that other people are successful. I don't want to >>> contribute to flooding them with requests. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ------------------------------ >>> *From: *"Tom Beecher" >>> *To: *"Jason Lixfeld" >>> *Cc: *"North American Network Operators' Group" >>> *Sent: *Thursday, January 24, 2019 1:38:51 PM >>> *Subject: *Re: Amazon Peering >>> >>> Thanks Jason. I'll have my peering team take another crack at reaching >>> out and see what happens. Appreciate it! >>> >>> On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld >>> wrote: >>> >>>> We circled back with them yesterday on a request we made in late >>>> November where at the time they said they wouldn’t be turned up until 2019 >>>> due to holiday network change freeze. >>>> >>>> They responded within about 4 hours, thanked us for our patience and >>>> understanding and said we should expect them to be turned up in about 6 >>>> weeks, which is apparently their typical timing. >>>> >>>> On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: >>>> >>>> I hate to necro-thread , but has anyone seen any movement from Amazon >>>> on this? I just got a Strongly Worded Message about it, and according to my >>>> peering team , it's been radio silence for months. >>>> >>>> >>>> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG >>>> wrote: >>>> >>>>> This is a note I received on Oct18 when checking on a peering request >>>>> submitted on Aug7.. >>>>> >>>>> “Apologies for the delays here. We have temporarily frozen IX peering >>>>> as we revise some of our automation processes. I’m hopeful this will be >>>>> unblocked by early November. Thank you for your continued patience.” >>>>> >>>>> On Nov 24, 2018, at 10:59, Darin Steffl >>>>> wrote: >>>>> >>>>> It seems wasteful for Amazon to connect to an IX but then ignore >>>>> peering requests for a year. >>>>> >>>>> They have 40G of connectivity but are unresponsive. I'll try emailing >>>>> all the other contacts listed in peeringdb. >>>>> >>>>> Thanks >>>>> >>>>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >>>> >>>>>> I've e-mailed my contacts there a couple times on people's behalf. No >>>>>> response yet. >>>>>> >>>>>> It seems like a lot of organizations need 1 more person in their >>>>>> peering departments. >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Mike Hammett >>>>>> Intelligent Computing Solutions >>>>>> http://www.ics-il.com >>>>>> >>>>>> Midwest-IX >>>>>> http://www.midwest-ix.com >>>>>> >>>>>> ------------------------------ >>>>>> *From: *"Darin Steffl" >>>>>> *To: *"North American Network Operators' Group" >>>>>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>>>>> *Subject: *Amazon Peering >>>>>> >>>>>> Hey all, >>>>>> >>>>>> Does anyone have a direct contact to get a peering session >>>>>> established with Amazon at an IX? I sent a peering request Dec 2017 and two >>>>>> more times this Sept and Nov with no response. >>>>>> >>>>>> I sent to peering at amazon.com and received one automated response >>>>>> back so I know they received my email but nothing since. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Darin Steffl >>>>>> Minnesota WiFi >>>>>> www.mnwifi.com >>>>>> 507-634-WiFi >>>>>> Like us on Facebook >>>>>> >>>>>> >>>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jan 30 16:36:21 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 30 Jan 2019 10:36:21 -0600 (CST) Subject: Amazon Peering In-Reply-To: References: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> Message-ID: <1128336028.1123.1548866177277.JavaMail.mhammett@ThunderFuck> Oh, you ordered cross connects for a PNI and they stopped responding mid-project? Isn't that nice! ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Luca Salvatore via NANOG" To: "North American Network Operators' Group" Sent: Wednesday, January 30, 2019 9:45:29 AM Subject: Re: Amazon Peering Similar experiences here with Amazon. Initially had semi-regular responses from their peering team, they issued LOAs, I ordered the x-connects and then radio silence for months. At the point now where I'm disconnecting x-connects since it's a waste of money. On Tue, Jan 29, 2019 at 10:49 AM Brooks Swinnerton < bswinnerton at gmail.com > wrote: I also saw sessions come up this weekend, no routes yet though. On Mon, Jan 28, 2019 at 4:56 PM Tom Beecher wrote:
Mike- Definitely moving forward now. Someone from Amazon was working with my peering group and things started coming up this weekend, so it seems like they're catching up pretty good now. On Thu, Jan 24, 2019 at 2:45 PM Mike Hammett < nanog at ics-il.net > wrote:
Let us know your success as well. I'll hold off following up on my requests until I see that other people are successful. I don't want to contribute to flooding them with requests. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Tom Beecher" To: "Jason Lixfeld" < jason+nanog at lixfeld.ca > Cc: "North American Network Operators' Group" < nanog at nanog.org > Sent: Thursday, January 24, 2019 1:38:51 PM Subject: Re: Amazon Peering Thanks Jason. I'll have my peering team take another crack at reaching out and see what happens. Appreciate it! On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld < jason+nanog at lixfeld.ca > wrote:
We circled back with them yesterday on a request we made in late November where at the time they said they wouldn’t be turned up until 2019 due to holiday network change freeze. They responded within about 4 hours, thanked us for our patience and understanding and said we should expect them to be turned up in about 6 weeks, which is apparently their typical timing.
On Jan 24, 2019, at 2:13 PM, Tom Beecher < beecher at beecher.cc > wrote: I hate to necro-thread , but has anyone seen any movement from Amazon on this? I just got a Strongly Worded Message about it, and according to my peering team , it's been radio silence for months. On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG < nanog at nanog.org > wrote:
This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” On Nov 24, 2018, at 10:59, Darin Steffl < darin.steffl at mnwifi.com > wrote:
It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. Thanks On Sat, Nov 24, 2018, 10:38 AM Mike Hammett < nanog at ics-il.net wrote:
I've e-mailed my contacts there a couple times on people's behalf. No response yet. It seems like a lot of organizations need 1 more person in their peering departments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Darin Steffl" < darin.steffl at mnwifi.com > To: "North American Network Operators' Group" < nanog at nanog.org > Sent: Friday, November 23, 2018 10:21:51 PM Subject: Amazon Peering Hey all, Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook
-------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jan 30 16:37:53 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 Jan 2019 18:37:53 +0200 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest Message-ID: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> For anyone running IP networks in the Midwest, are you having to do anything special to keep your networks up? For the data centres, is this cold front a chance to reduce air conditioning costs, or is it actually straining the infrastructure? I'm curious, from a +27-degree C summer's day here in Johannesburg. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jan 30 16:41:22 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 30 Jan 2019 10:41:22 -0600 (CST) Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> Message-ID: <1951380795.1178.1548866480720.JavaMail.mhammett@ThunderFuck> A lot of huge companies apparently find it tough to find the $75k to hire one more peering person. Not all, though. For many, everything just runs like clockwork. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Lixfeld" To: "North American Network Operators' Group" Sent: Wednesday, January 30, 2019 7:52:09 AM Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY Hi, In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Wed Jan 30 16:50:18 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 30 Jan 2019 16:50:18 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> Being a Minnesota native, I can tell you that while it is indeed cold, this is nothing new i the Great White North :) I am amaze a how consistently the media overplays the severity of Midwest cold weather as some kind of unique phenomenon. They amplify this by reporting the wind-chill factor, which is the “what it feels like” equivalent in a cold and windy environment. But equipment feels nothing, so windchill is irrelevant. For example, Minneapolis is -20F, but the news media instead reports “-60F wind chill”, which, while dramatic, is not meaningful for most purposes. I grew up in Minnesota with -30F and lower quite common, and we walked to school in those temperatures. You just have to dress well. Minneapolis is paved with tunnels and heated skyways to eliminate most outdoor walking downtown. As far as networks go, none of the ISPs I know of do anything different than anywhere else in the country. Everyone has backup power. It’s already common practice everywhere to exploit cooler winter ambient temperatures to reduce HVAC requirements, so that’s not new either. But it gets as hot in the Midwest in our summer as it is in SA for you now, so everyone must still build out HVAC capacity to cover the hottest days. -mel beckman On Jan 30, 2019, at 8:40 AM, Mark Tinka > wrote: For anyone running IP networks in the Midwest, are you having to do anything special to keep your networks up? For the data centres, is this cold front a chance to reduce air conditioning costs, or is it actually straining the infrastructure? I'm curious, from a +27-degree C summer's day here in Johannesburg. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Wed Jan 30 16:55:06 2019 From: bryan at shout.net (Bryan Holloway) Date: Wed, 30 Jan 2019 10:55:06 -0600 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> Message-ID: <89655a12-01d7-9823-bfda-c4d6abac057d@shout.net> Approximately 3 hrs ago we lost B-feed at Minneapolis Cologix. Apparently the local utility requested that they move one side to generator due to the weather and high-utilization, and the ATS failed. But we're up ... On 1/30/19 10:50 AM, Mel Beckman wrote: > Being a Minnesota native, I can tell you that while it is indeed cold, > this is nothing new i the Great White North :)  I am amaze a how > consistently the media overplays the severity of Midwest cold weather as > some kind of unique phenomenon. They amplify this by reporting the > wind-chill factor, which is the “what it feels like” equivalent in a > cold and windy environment. But equipment feels nothing, so windchill is > irrelevant. > > For example, Minneapolis is -20F, but the news media instead reports > “-60F wind chill”, which, while dramatic, is not meaningful for most > purposes. I grew up in Minnesota with -30F and lower quite common, and > we walked to school in those temperatures. You just have to dress well. > Minneapolis is paved with tunnels and heated skyways to eliminate most > outdoor walking downtown. > > As far as networks go, none of the ISPs I know of do anything different > than anywhere else in the country. Everyone has backup power. It’s > already common practice everywhere to exploit cooler winter ambient > temperatures to reduce HVAC requirements, so that’s not new either. But > it gets as hot in the Midwest in our summer as it is in SA for you now, > so everyone must still build out HVAC capacity to cover the hottest days. > >  -mel beckman > > On Jan 30, 2019, at 8:40 AM, Mark Tinka > wrote: > >> For anyone running IP networks in the Midwest, are you having to do >> anything special to keep your networks up? >> >> For the data centres, is this cold front a chance to reduce air >> conditioning costs, or is it actually straining the infrastructure? >> >> I'm curious, from a +27-degree C summer's day here in Johannesburg. >> >> Mark. From mehmet at akcin.net Wed Jan 30 17:02:36 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 30 Jan 2019 09:02:36 -0800 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> Message-ID: Pinged my contacts in each On Wed, Jan 30, 2019 at 05:52 Jason Lixfeld wrote: > Hi, > > In late October 2018, DE-CIX announced that they would be renumbering > their IPv4 address block in New York between 01-28-19 and 01-30-19. > > This was followed by numerous reminders in months, weeks and even days > leading up to the renumbering activity. > > The renumbering activity has come and gone, but LinkedIn, Amazon and > Akamai are still using the old IPs. > > If three months has gone by and the numerous reminders that have been sent > have resulted in these organizations still living on the old IP space, it > seems to me that there may be some sort of a disconnect between who > receives the notifications from IXPs and how they are filtered upstream. > > I’m hopeful that the eyeballs who read this list are some of those folks > who should have received the notifications from DE-CIX, or can at least > filter the info back downstream to whoever can perform the renumbering > activity. > > Thanks. > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Jan 30 17:03:31 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 30 Jan 2019 09:03:31 -0800 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <89655a12-01d7-9823-bfda-c4d6abac057d@shout.net> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <89655a12-01d7-9823-bfda-c4d6abac057d@shout.net> Message-ID: And here I always figured it was bespoke knit caps for all the packets in cold-weather climes? learn something new every day! (also, now I wonder what the people who told me they were too busy knitting caps are ACTUALLY doing??) On Wed, Jan 30, 2019 at 8:55 AM Bryan Holloway wrote: > Approximately 3 hrs ago we lost B-feed at Minneapolis Cologix. > > Apparently the local utility requested that they move one side to > generator due to the weather and high-utilization, and the ATS failed. > > But we're up ... > > > On 1/30/19 10:50 AM, Mel Beckman wrote: > > Being a Minnesota native, I can tell you that while it is indeed cold, > > this is nothing new i the Great White North :) I am amaze a how > > consistently the media overplays the severity of Midwest cold weather as > > some kind of unique phenomenon. They amplify this by reporting the > > wind-chill factor, which is the “what it feels like” equivalent in a > > cold and windy environment. But equipment feels nothing, so windchill is > > irrelevant. > > > > For example, Minneapolis is -20F, but the news media instead reports > > “-60F wind chill”, which, while dramatic, is not meaningful for most > > purposes. I grew up in Minnesota with -30F and lower quite common, and > > we walked to school in those temperatures. You just have to dress well. > > Minneapolis is paved with tunnels and heated skyways to eliminate most > > outdoor walking downtown. > > > > As far as networks go, none of the ISPs I know of do anything different > > than anywhere else in the country. Everyone has backup power. It’s > > already common practice everywhere to exploit cooler winter ambient > > temperatures to reduce HVAC requirements, so that’s not new either. But > > it gets as hot in the Midwest in our summer as it is in SA for you now, > > so everyone must still build out HVAC capacity to cover the hottest days. > > > > -mel beckman > > > > On Jan 30, 2019, at 8:40 AM, Mark Tinka > > wrote: > > > >> For anyone running IP networks in the Midwest, are you having to do > >> anything special to keep your networks up? > >> > >> For the data centres, is this cold front a chance to reduce air > >> conditioning costs, or is it actually straining the infrastructure? > >> > >> I'm curious, from a +27-degree C summer's day here in Johannesburg. > >> > >> Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 30 17:04:54 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 30 Jan 2019 17:04:54 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EFA18E@MUNPRDMBXA1.medline.com> The main issue is infrastructure like power, cable damage, and heating/cooling systems. Power lines tend to go down because anything weak becomes brittle and any accident involving a pole tends to cause them to break rather than absorb impact. Also, conduits and manholes that normally might be above freezing underground can have standing water freeze breaking splice cases and such. Large chiller plants need to be run at higher temperatures and speeds to keep any outdoor components from freezing up. Of course, repairs on anything outdoors tend to take a lot longer to resolve. Anything that requires digging might be near impossible in these conditions. So far though in my area (Chicago) my carriers AT&T, Comcast, Cogent, and Level 3 all seem to be fine so far. Our current temp is -18. Wind chill reports at -50 to -60 depending where you are. Steven Naslund Chicago IL From: NANOG On Behalf Of Mark Tinka Sent: Wednesday, January 30, 2019 10:38 AM To: North American Network Operators' Group Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest For anyone running IP networks in the Midwest, are you having to do anything special to keep your networks up? For the data centres, is this cold front a chance to reduce air conditioning costs, or is it actually straining the infrastructure? I'm curious, from a +27-degree C summer's day here in Johannesburg. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed Jan 30 17:09:29 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 30 Jan 2019 12:09:29 -0500 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> Message-ID: To be fair, reporting the the wind chill factor is very meaningful for health and safety reasons almost everywhere so proper warning is given about people spending time outside. Minneapolis, and the bigger Canadian cities have those inside walkways and pedestrian pathways, but they're not that common elsewhere. I don't think Chicago does for example, and we don't have that here in Buffalo. Contrary to the rumors, 0F with -40F wind chills are NOT very common around here. People need to be warned to take this weather seriously. You might be used to it, but not everyone in a native that can say that. To the 'infrastructure' question, I think the biggest concerns would be power related. Although we have a DC in Buffalo that is cooled on ambient outside air that has the opposite problem ; it's TOO cold at the moment, so we are cycling most of the hot server exhaust back into the computer rooms to maintain temperatures. On Wed, Jan 30, 2019 at 11:52 AM Mel Beckman wrote: > Being a Minnesota native, I can tell you that while it is indeed cold, > this is nothing new i the Great White North :) I am amaze a how > consistently the media overplays the severity of Midwest cold weather as > some kind of unique phenomenon. They amplify this by reporting the > wind-chill factor, which is the “what it feels like” equivalent in a cold > and windy environment. But equipment feels nothing, so windchill is > irrelevant. > > For example, Minneapolis is -20F, but the news media instead reports “-60F > wind chill”, which, while dramatic, is not meaningful for most purposes. I > grew up in Minnesota with -30F and lower quite common, and we walked to > school in those temperatures. You just have to dress well. Minneapolis is > paved with tunnels and heated skyways to eliminate most outdoor walking > downtown. > > As far as networks go, none of the ISPs I know of do anything different > than anywhere else in the country. Everyone has backup power. It’s already > common practice everywhere to exploit cooler winter ambient temperatures to > reduce HVAC requirements, so that’s not new either. But it gets as hot in > the Midwest in our summer as it is in SA for you now, so everyone must > still build out HVAC capacity to cover the hottest days. > > -mel beckman > > On Jan 30, 2019, at 8:40 AM, Mark Tinka wrote: > > For anyone running IP networks in the Midwest, are you having to do > anything special to keep your networks up? > > For the data centres, is this cold front a chance to reduce air > conditioning costs, or is it actually straining the infrastructure? > > I'm curious, from a +27-degree C summer's day here in Johannesburg. > > Mark. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Jan 30 17:19:59 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 30 Jan 2019 12:19:59 -0500 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> Message-ID: <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> Akamai is working on doing our part. Apologies. Sent from my iCar > On Jan 30, 2019, at 12:02 PM, Mehmet Akcin wrote: > > Pinged my contacts in each > >> On Wed, Jan 30, 2019 at 05:52 Jason Lixfeld wrote: >> Hi, >> >> In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. >> >> This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. >> >> The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. >> >> If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. >> >> I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. >> >> Thanks. >> > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 30 17:24:10 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 30 Jan 2019 17:24:10 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> >To the 'infrastructure' question, I think the biggest concerns would >be power related. Although we have a DC in Buffalo that is cooled >on ambient outside air that has the opposite problem ; it's TOO cold >at the moment, so we are cycling most of the hot server exhaust >back into the computer rooms to maintain temperatures. Exactly what he said. We actually run cooling and supplemental heating in extreme cold. We need to keep the chiller pulling heat into itself and pumps moving on high to keep the outdoor components from freezing up. During the summer you might run close to or slightly below freezing on the coolant loops but in these conditions you cannot run that low a temp because things will freeze up before the coolant returns. We also have to keep the room reasonably warm (50F +). You also need to watch out for fast temp excursions to keep humidity under control. The wind speed does make some difference since it is like a fan on your evaporator pulling heat out of the cooling loops faster than still air will. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 30 17:37:10 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 30 Jan 2019 17:37:10 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EFA296@MUNPRDMBXA1.medline.com> >Exactly what he said. We actually run cooling and supplemental heating >in extreme cold. We need to keep the chiller pulling heat into itself and >pumps moving on high to keep the outdoor components from freezing >up. During the summer you might run close to or slightly below freezing >on the coolant loops but in these conditions you cannot run that low a >temp because things will freeze up before the coolant returns. We also >have to keep the room reasonably warm (50F +). You also need to watch >out for fast temp excursions to keep humidity under control. A good HVAC team is critical because we have noted that the building management systems often are not flexible enough to automatically deal with super extremes and require some human intervention to tell them to do things like run heat and cooling simultaneously. Other actions like closing down louvers on evaporators may or may not be automated depending on your systems. If any part of the system does fail in these conditions you have to move super quick or you could get serious damage fast. Our biggest monitoring points are flow rate/pressure (which could indicate a freeze up beginning or a pump failing), output and return temp on the loops. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From pz at wish.com Wed Jan 30 17:39:23 2019 From: pz at wish.com (Paul Zugnoni) Date: Wed, 30 Jan 2019 09:39:23 -0800 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> Message-ID: And apparently fire. I wasn’t going to chime in but one of my providers *just* alerted us to an electrical fire in a Minneapolis pop causing loads to failover to ups. Unknown whether weather conditions contributed to the incident. PZ On Wed, Jan 30, 2019 at 09:25 Naslund, Steve wrote: > >To the 'infrastructure' question, I think the biggest concerns would >be > power related. Although we have a DC in Buffalo that is cooled >on > ambient outside air that has the opposite problem ; it's TOO cold >at the > moment, so we are cycling most of the hot server exhaust >back into the > computer rooms to maintain temperatures. > > > > Exactly what he said. We actually run cooling and supplemental heating in > extreme cold. We need to keep the chiller pulling heat into itself and > pumps moving on high to keep the outdoor components from freezing up. > During the summer you might run close to or slightly below freezing on the > coolant loops but in these conditions you cannot run that low a temp > because things will freeze up before the coolant returns. We also have to > keep the room reasonably warm (50F +). You also need to watch out for fast > temp excursions to keep humidity under control. > > > > The wind speed does make some difference since it is like a fan on your > evaporator pulling heat out of the cooling loops faster than still air will. > > > > Steven Naslund > > Chicago IL > -- PZ Head of Datacenter and Network Infrastructure, Wish pz at wish.com +1-650-313-3458 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jan 30 17:42:55 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 30 Jan 2019 19:42:55 +0200 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA296@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40318EFA296@MUNPRDMBXA1.medline.com> Message-ID: <83d61822-54ee-28ce-4213-3945c353904e@seacom.mu> On 30/Jan/19 19:37, Naslund, Steve wrote: > >   > > A good HVAC team is critical because we have noted that the building > management systems often are not flexible enough to automatically deal > with super extremes and require some human intervention to tell them > to do things like run heat and cooling simultaneously.  Other actions > like closing down louvers on evaporators may or may not be automated > depending on your systems.  If any part of the system does fail in > these conditions you have to move super quick or you could get serious > damage fast.  Our biggest monitoring points are flow rate/pressure > (which could indicate a freeze up beginning or a pump failing), output > and return temp on the loops. > This was one of the things I was concerned about, fluids going smudgy or just simply freezing up... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 30 17:42:57 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 30 Jan 2019 17:42:57 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EFA2AC@MUNPRDMBXA1.medline.com> Ironically you don’t really save a lot of energy when it’s this cold because the loops are running at high speed and the humidification coils are working overtime to keep the RH up in the room. People think we can bring in all the outside cold we want but the issue then is humidity stability. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 30 17:56:17 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 30 Jan 2019 17:56:17 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EFA2C8@MUNPRDMBXA1.medline.com> >And apparently fire. I wasn’t going to chime in but one of my >providers *just* alerted us to an electrical fire in a Minneapolis pop >causing loads to failover to ups. Unknown whether weather >conditions contributed to the incident. Yes, in Chicago we will see an increase in home fires because heating systems are being pushed to their limits and people tend to do stupid things like run unattended space heaters and try to thaw frozen stuff in crazy ways. In a datacenter you might be pushing electrical loads while external electrical components are stressed with temperature. I have seen transformer fires caused by the oil inside not circulating correctly. You end up with hot and cold zones in them. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Wed Jan 30 18:10:11 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 30 Jan 2019 13:10:11 -0500 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA2C8@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40318EFA2C8@MUNPRDMBXA1.medline.com> Message-ID: Well said. The electrical load shifts, hydraulic systems, airflows constrained by ice cover, etc, etc, etc. All kinds of things being asked to do stuff outside or at the edge of specifications. Hug your local facilities guys when these things happen. (Or bring them booze.) On Wed, Jan 30, 2019 at 12:58 PM Naslund, Steve wrote: > >And apparently fire. I wasn’t going to chime in but one of my >providers > *just* alerted us to an electrical fire in a Minneapolis pop >causing > loads to failover to ups. Unknown whether weather >conditions contributed > to the incident. > > > > Yes, in Chicago we will see an increase in home fires because heating > systems are being pushed to their limits and people tend to do stupid > things like run unattended space heaters and try to thaw frozen stuff in > crazy ways. In a datacenter you might be pushing electrical loads while > external electrical components are stressed with temperature. I have seen > transformer fires caused by the oil inside not circulating correctly. You > end up with hot and cold zones in them. > > > > Steven Naslund > > Chicago IL > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at digitalocean.com Wed Jan 30 18:16:32 2019 From: luca at digitalocean.com (Luca Salvatore) Date: Wed, 30 Jan 2019 13:16:32 -0500 Subject: Amazon Peering In-Reply-To: <1128336028.1123.1548866177277.JavaMail.mhammett@ThunderFuck> References: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> <1128336028.1123.1548866177277.JavaMail.mhammett@ThunderFuck> Message-ID: Yup, super professional of them. On Wed, Jan 30, 2019 at 11:36 AM Mike Hammett wrote: > Oh, you ordered cross connects for a PNI and they stopped responding > mid-project? Isn't that nice! > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Luca Salvatore via NANOG" > *To: *"North American Network Operators' Group" > *Sent: *Wednesday, January 30, 2019 9:45:29 AM > *Subject: *Re: Amazon Peering > > Similar experiences here with Amazon. Initially had semi-regular > responses from their peering team, they issued LOAs, I ordered the > x-connects and then radio silence for months. > At the point now where I'm disconnecting x-connects since it's a waste of > money. > > On Tue, Jan 29, 2019 at 10:49 AM Brooks Swinnerton > wrote: > >> I also saw sessions come up this weekend, no routes yet though. >> >> On Mon, Jan 28, 2019 at 4:56 PM Tom Beecher wrote: >> >>> Mike- >>> >>> Definitely moving forward now. Someone from Amazon was working with my >>> peering group and things started coming up this weekend, so it seems like >>> they're catching up pretty good now. >>> >>> On Thu, Jan 24, 2019 at 2:45 PM Mike Hammett wrote: >>> >>>> Let us know your success as well. I'll hold off following up on my >>>> requests until I see that other people are successful. I don't want to >>>> contribute to flooding them with requests. >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> Midwest-IX >>>> http://www.midwest-ix.com >>>> >>>> ------------------------------ >>>> *From: *"Tom Beecher" >>>> *To: *"Jason Lixfeld" >>>> *Cc: *"North American Network Operators' Group" >>>> *Sent: *Thursday, January 24, 2019 1:38:51 PM >>>> *Subject: *Re: Amazon Peering >>>> >>>> Thanks Jason. I'll have my peering team take another crack at reaching >>>> out and see what happens. Appreciate it! >>>> >>>> On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld >>>> wrote: >>>> >>>>> We circled back with them yesterday on a request we made in late >>>>> November where at the time they said they wouldn’t be turned up until 2019 >>>>> due to holiday network change freeze. >>>>> >>>>> They responded within about 4 hours, thanked us for our patience and >>>>> understanding and said we should expect them to be turned up in about 6 >>>>> weeks, which is apparently their typical timing. >>>>> >>>>> On Jan 24, 2019, at 2:13 PM, Tom Beecher wrote: >>>>> >>>>> I hate to necro-thread , but has anyone seen any movement from Amazon >>>>> on this? I just got a Strongly Worded Message about it, and according to my >>>>> peering team , it's been radio silence for months. >>>>> >>>>> >>>>> On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG < >>>>> nanog at nanog.org> wrote: >>>>> >>>>>> This is a note I received on Oct18 when checking on a peering request >>>>>> submitted on Aug7.. >>>>>> >>>>>> “Apologies for the delays here. We have temporarily frozen IX peering >>>>>> as we revise some of our automation processes. I’m hopeful this will be >>>>>> unblocked by early November. Thank you for your continued patience.” >>>>>> >>>>>> On Nov 24, 2018, at 10:59, Darin Steffl >>>>>> wrote: >>>>>> >>>>>> It seems wasteful for Amazon to connect to an IX but then ignore >>>>>> peering requests for a year. >>>>>> >>>>>> They have 40G of connectivity but are unresponsive. I'll try emailing >>>>>> all the other contacts listed in peeringdb. >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Sat, Nov 24, 2018, 10:38 AM Mike Hammett >>>>> >>>>>>> I've e-mailed my contacts there a couple times on people's behalf. >>>>>>> No response yet. >>>>>>> >>>>>>> It seems like a lot of organizations need 1 more person in their >>>>>>> peering departments. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Mike Hammett >>>>>>> Intelligent Computing Solutions >>>>>>> http://www.ics-il.com >>>>>>> >>>>>>> Midwest-IX >>>>>>> http://www.midwest-ix.com >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From: *"Darin Steffl" >>>>>>> *To: *"North American Network Operators' Group" >>>>>>> *Sent: *Friday, November 23, 2018 10:21:51 PM >>>>>>> *Subject: *Amazon Peering >>>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> Does anyone have a direct contact to get a peering session >>>>>>> established with Amazon at an IX? I sent a peering request Dec 2017 and two >>>>>>> more times this Sept and Nov with no response. >>>>>>> >>>>>>> I sent to peering at amazon.com and received one automated response >>>>>>> back so I know they received my email but nothing since. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Darin Steffl >>>>>>> Minnesota WiFi >>>>>>> www.mnwifi.com >>>>>>> 507-634-WiFi >>>>>>> Like us on Facebook >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Jan 30 18:23:39 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 30 Jan 2019 18:23:39 +0000 Subject: Amazon Peering In-Reply-To: References: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> <1128336028.1123.1548866177277.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B40318EFA381@MUNPRDMBXA1.medline.com> AKA Too Big To Care. Happens a lot. Steven Naslund Chicago IL On Wed, Jan 30, 2019 at 11:36 AM Mike Hammett > wrote: Oh, you ordered cross connects for a PNI and they stopped responding mid-project? Isn't that nice! ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Luca Salvatore via NANOG" > To: "North American Network Operators' Group" > Sent: Wednesday, January 30, 2019 9:45:29 AM Subject: Re: Amazon Peering Similar experiences here with Amazon. Initially had semi-regular responses from their peering team, they issued LOAs, I ordered the x-connects and then radio silence for months. At the point now where I'm disconnecting x-connects since it's a waste of money. On Tue, Jan 29, 2019 at 10:49 AM Brooks Swinnerton > wrote: I also saw sessions come up this weekend, no routes yet though. On Mon, Jan 28, 2019 at 4:56 PM Tom Beecher > wrote: Mike- Definitely moving forward now. Someone from Amazon was working with my peering group and things started coming up this weekend, so it seems like they're catching up pretty good now. On Thu, Jan 24, 2019 at 2:45 PM Mike Hammett > wrote: Let us know your success as well. I'll hold off following up on my requests until I see that other people are successful. I don't want to contribute to flooding them with requests. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Tom Beecher" > To: "Jason Lixfeld" > Cc: "North American Network Operators' Group" > Sent: Thursday, January 24, 2019 1:38:51 PM Subject: Re: Amazon Peering Thanks Jason. I'll have my peering team take another crack at reaching out and see what happens. Appreciate it! On Thu, Jan 24, 2019 at 2:21 PM Jason Lixfeld > wrote: We circled back with them yesterday on a request we made in late November where at the time they said they wouldn’t be turned up until 2019 due to holiday network change freeze. They responded within about 4 hours, thanked us for our patience and understanding and said we should expect them to be turned up in about 6 weeks, which is apparently their typical timing. On Jan 24, 2019, at 2:13 PM, Tom Beecher > wrote: I hate to necro-thread , but has anyone seen any movement from Amazon on this? I just got a Strongly Worded Message about it, and according to my peering team , it's been radio silence for months. On Sat, Nov 24, 2018 at 12:32 PM JASON BOTHE via NANOG > wrote: This is a note I received on Oct18 when checking on a peering request submitted on Aug7.. “Apologies for the delays here. We have temporarily frozen IX peering as we revise some of our automation processes. I’m hopeful this will be unblocked by early November. Thank you for your continued patience.” On Nov 24, 2018, at 10:59, Darin Steffl > wrote: It seems wasteful for Amazon to connect to an IX but then ignore peering requests for a year. They have 40G of connectivity but are unresponsive. I'll try emailing all the other contacts listed in peeringdb. Thanks On Sat, Nov 24, 2018, 10:38 AM Mike Hammett wrote: I've e-mailed my contacts there a couple times on people's behalf. No response yet. It seems like a lot of organizations need 1 more person in their peering departments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Darin Steffl" > To: "North American Network Operators' Group" > Sent: Friday, November 23, 2018 10:21:51 PM Subject: Amazon Peering Hey all, Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. I sent to peering at amazon.com and received one automated response back so I know they received my email but nothing since. -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi [http://www.snoitulosten.com/wp-content/uploads/2010/01/facebook-small.jpg] Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From stankiewicz at njedge.net Wed Jan 30 18:23:41 2019 From: stankiewicz at njedge.net (James Stankiewicz) Date: Wed, 30 Jan 2019 13:23:41 -0500 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> Message-ID: Microsoft an Edgecast has not yet made there changes. On Wed, Jan 30, 2019 at 12:20 PM Jared Mauch wrote: > Akamai is working on doing our part. Apologies. > > Sent from my iCar > > On Jan 30, 2019, at 12:02 PM, Mehmet Akcin wrote: > > Pinged my contacts in each > > On Wed, Jan 30, 2019 at 05:52 Jason Lixfeld > wrote: > >> Hi, >> >> In late October 2018, DE-CIX announced that they would be renumbering >> their IPv4 address block in New York between 01-28-19 and 01-30-19. >> >> This was followed by numerous reminders in months, weeks and even days >> leading up to the renumbering activity. >> >> The renumbering activity has come and gone, but LinkedIn, Amazon and >> Akamai are still using the old IPs. >> >> If three months has gone by and the numerous reminders that have been >> sent have resulted in these organizations still living on the old IP space, >> it seems to me that there may be some sort of a disconnect between who >> receives the notifications from IXPs and how they are filtered upstream. >> >> I’m hopeful that the eyeballs who read this list are some of those folks >> who should have received the notifications from DE-CIX, or can at least >> filter the info back downstream to whoever can perform the renumbering >> activity. >> >> Thanks. >> >> -- > Mehmet > +1-424-298-1903 > > -- *Jim Stankiewicz* *Principal Network Architect* *NJEdge* *W:855.832.EDGE(3343)* *c:201.306.4409* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnovakovic at linkedin.com Wed Jan 30 16:47:26 2019 From: mnovakovic at linkedin.com (Marijana Novakovic) Date: Wed, 30 Jan 2019 16:47:26 +0000 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <1951380795.1178.1548866480720.JavaMail.mhammett@ThunderFuck> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca>, <1951380795.1178.1548866480720.JavaMail.mhammett@ThunderFuck> Message-ID: Greetings Jason, Thank you for your kind feedback, we have CM planned for today to do the needed change. Kind regards, Mara ________________________________ From: NANOG on behalf of Mike Hammett Sent: Wednesday, January 30, 2019 8:41 AM To: Jason Lixfeld Cc: North American Network Operators' Group Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY A lot of huge companies apparently find it tough to find the $75k to hire one more peering person. Not all, though. For many, everything just runs like clockwork. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Jason Lixfeld" To: "North American Network Operators' Group" Sent: Wednesday, January 30, 2019 7:52:09 AM Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY Hi, In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xxnog at ledeuns.net Wed Jan 30 18:35:03 2019 From: xxnog at ledeuns.net (Denis Fondras) Date: Wed, 30 Jan 2019 19:35:03 +0100 Subject: Amazon Peering In-Reply-To: References: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> <1128336028.1123.1548866177277.JavaMail.mhammett@ThunderFuck> Message-ID: <20190130183503.GK56439@carcass.ledeuns.net> > Yup, super professional of them. > Have you tried to order a port on DirectConnect to check if it was hassleless ? :p From beecher at beecher.cc Wed Jan 30 18:51:31 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 30 Jan 2019 13:51:31 -0500 Subject: Amazon Peering In-Reply-To: <20190130183503.GK56439@carcass.ledeuns.net> References: <19EC99C7-3E4E-49D4-9F3E-A46BEEF6C256@lixfeld.ca> <780618504.3614.1548359106764.JavaMail.mhammett@ThunderFuck> <1128336028.1123.1548866177277.JavaMail.mhammett@ThunderFuck> <20190130183503.GK56439@carcass.ledeuns.net> Message-ID: I'm sure ~ $20k/yr in time cost alone per 10G has nothing to do with that... :p Although to be fair, the individual from Amazon who my peering group has been working with after my first message has been really, really great. As with many things, the people are great, just not enough resources I'm sure. On Wed, Jan 30, 2019 at 1:39 PM Denis Fondras wrote: > > Yup, super professional of them. > > > > Have you tried to order a port on DirectConnect to check if it was > hassleless ? > :p > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.king at de-cix.net Wed Jan 30 22:05:55 2019 From: thomas.king at de-cix.net (Thomas King) Date: Wed, 30 Jan 2019 22:05:55 +0000 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> Message-ID: <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Hi all, Thanks for your support! This helps us getting all peers on the new IPv4 space. Our looking glass shows which peers already have changed the IP settings (see section “BGP session established”) and which peers are still working on it (see section “BGP sessions down”): https://lg.de-cix.net/routeservers/rs1_nyc_ipv4#sessions-up Best regards, Thomas From: NANOG on behalf of James Stankiewicz Date: Wednesday, 30. January 2019 at 19:32 To: Jared Mauch Cc: North American Network Operators' Group Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY Microsoft an Edgecast has not yet made there changes. On Wed, Jan 30, 2019 at 12:20 PM Jared Mauch wrote: Akamai is working on doing our part. Apologies. Sent from my iCar On Jan 30, 2019, at 12:02 PM, Mehmet Akcin wrote: Pinged my contacts in each On Wed, Jan 30, 2019 at 05:52 Jason Lixfeld wrote: Hi, In late October 2018, DE-CIX announced that they would be renumbering their IPv4 address block in New York between 01-28-19 and 01-30-19. This was followed by numerous reminders in months, weeks and even days leading up to the renumbering activity. The renumbering activity has come and gone, but LinkedIn, Amazon and Akamai are still using the old IPs. If three months has gone by and the numerous reminders that have been sent have resulted in these organizations still living on the old IP space, it seems to me that there may be some sort of a disconnect between who receives the notifications from IXPs and how they are filtered upstream. I’m hopeful that the eyeballs who read this list are some of those folks who should have received the notifications from DE-CIX, or can at least filter the info back downstream to whoever can perform the renumbering activity. Thanks. -- Mehmet +1-424-298-1903 -- Jim Stankiewicz Principal Network Architect NJEdge W:855.832.EDGE(3343) c:201.306.4409 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5353 bytes Desc: not available URL: From ren.provo at gmail.com Wed Jan 30 22:09:40 2019 From: ren.provo at gmail.com (Ren Provo) Date: Wed, 30 Jan 2019 17:09:40 -0500 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Message-ID: Hi Thomas, You probably should remove sessions with networks explicitly *not* participating in route servers versus displaying them on a global shame list. Cheers, -ren On Wed, Jan 30, 2019 at 5:06 PM Thomas King wrote: > Hi all, > > > > Thanks for your support! This helps us getting all peers on the new IPv4 > space. > > > > Our looking glass shows which peers already have changed the IP settings > (see section “BGP session established”) and which peers are still working > on it (see section “BGP sessions down”): > > https://lg.de-cix.net/routeservers/rs1_nyc_ipv4#sessions-up > > > > Best regards, > Thomas > > > > > > *From: *NANOG on behalf of James Stankiewicz < > stankiewicz at njedge.net> > *Date: *Wednesday, 30. January 2019 at 19:32 > *To: *Jared Mauch > *Cc: *North American Network Operators' Group > *Subject: *Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY > > > > Microsoft an Edgecast has not yet made there changes. > > > > On Wed, Jan 30, 2019 at 12:20 PM Jared Mauch > wrote: > > Akamai is working on doing our part. Apologies. > > Sent from my iCar > > > On Jan 30, 2019, at 12:02 PM, Mehmet Akcin wrote: > > Pinged my contacts in each > > > > On Wed, Jan 30, 2019 at 05:52 Jason Lixfeld > wrote: > > Hi, > > In late October 2018, DE-CIX announced that they would be renumbering > their IPv4 address block in New York between 01-28-19 and 01-30-19. > > This was followed by numerous reminders in months, weeks and even days > leading up to the renumbering activity. > > The renumbering activity has come and gone, but LinkedIn, Amazon and > Akamai are still using the old IPs. > > If three months has gone by and the numerous reminders that have been sent > have resulted in these organizations still living on the old IP space, it > seems to me that there may be some sort of a disconnect between who > receives the notifications from IXPs and how they are filtered upstream. > > I’m hopeful that the eyeballs who read this list are some of those folks > who should have received the notifications from DE-CIX, or can at least > filter the info back downstream to whoever can perform the renumbering > activity. > > Thanks. > > -- > > Mehmet > +1-424-298-1903 > > > > > -- > > *Jim Stankiewicz* > > *Principal Network Architect* > > *NJEdge* > > *W:855.832.EDGE(3343)* > > *c:201.306.4409* > > *[image: > https://docs.google.com/uc?export=download&id=0B15Cb24EwZVsOUhIa0lWbG9ZT2c&revid=0B15Cb24EwZVsdVB2SlJ3ekFEUllPRDZyMGZ5cUtkbko2bWQ0PQ]* > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Wed Jan 30 22:42:02 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 30 Jan 2019 17:42:02 -0500 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA2AC@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40318EFA2AC@MUNPRDMBXA1.medline.com> Message-ID: <23634.10298.290354.552306@gargle.gargle.HOWL> Re: Fire Also fire dept response. I've ridden with the Boston Fire Dept, extreme cold is a major PITA, hydrants freeze, you have to work in it going from the heat of the fire to sub-zero air temps over and over, all while getting soaking wet, and wind-chill is certainly a factor. There were always cautionary stories about some firefighter having a heart attack struggling to get a frozen hydrant open. Whether factual or not I think it makes a point, no water no firefighting in general. I could tell you about the fire boats in February...sometimes you need them. I just saw a news spot (I believe Chicago) where they had to raise to multiple alarms on a fairly simple tho working house fire just so they had enough firefighters to cycle them through a warming truck (I don't remember any warming truck in Boston tho you could go sit in a truck cab :-)) Which means thinner coverage for other areas. -- -Barry Shein Software Tool & Die | bzs at 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* From mpetach at netflight.com Wed Jan 30 23:29:13 2019 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 30 Jan 2019 15:29:13 -0800 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <89655a12-01d7-9823-bfda-c4d6abac057d@shout.net> Message-ID: On Wed, Jan 30, 2019 at 9:07 AM Christopher Morrow wrote: > And here I always figured it was bespoke knit caps for all the packets in > cold-weather climes? > learn something new every day! (also, now I wonder what the people who > told me they were too busy knitting caps are ACTUALLY doing??) > Unfortunately, they're knitting *DATA* caps. ;-P Sorry, couldn't resist. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Jan 30 23:36:18 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 31 Jan 2019 02:36:18 +0300 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Message-ID: On Thu, Jan 30, 2019 at 23:10 AM Ren Provo wrote: > You probably should remove sessions with networks > explicitly *not* participating in route servers versus > displaying them on a global shame list. And so it begins — yet another discussion on what does the word "responsibility" really mean. Given that e.g. the peering facility in Amazon, according to an adjacent NANOG ML thread, is in deep deep trouble since Nov 2018, just shutting down sessions with all of the entries in that shame list is likely to cause huge disruption and disappoinment. -- Töma From martijnschmidt at i3d.net Wed Jan 30 23:55:40 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Wed, 30 Jan 2019 23:55:40 +0000 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Message-ID: On 1/31/19 12:36 AM, Töma Gavrichenkov wrote: > On Thu, Jan 30, 2019 at 23:10 AM Ren Provo wrote: >> You probably should remove sessions with networks >> explicitly *not* participating in route servers versus >> displaying them on a global shame list. > And so it begins — yet another discussion on what does the word > "responsibility" really mean. > > Given that e.g. the peering facility in Amazon, according to an > adjacent NANOG ML thread, is in deep deep trouble since Nov 2018, just > shutting down sessions with all of the entries in that shame list is > likely to cause huge disruption and disappoinment. > > -- > Töma What triggered that part of the discussion is a logical fallacy along the lines of: if A is true, then B is true. B is true, therefore A is true. Here: all networks that didn't already change their peering IP are not yet connected to the updated route-server. Some networks are not connected to any route-server. Therefore, those networks did not yet change their peering IP. I think you can see what's wrong with that statement.. it does not follow. That has nothing to do with peering department resources, but everything to do with the chosen peering strategy. Best regards, Martijn From mpetach at netflight.com Thu Jan 31 01:22:25 2019 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 30 Jan 2019 17:22:25 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <20190124001038.GH98649@meow.BKantor.net> References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: On Wed, Jan 23, 2019 at 4:12 PM Brian Kantor wrote: > Quoting from the web site at https://dnsflagday.net/ > [...] > The current DNS is unnecessarily slow and suffers from inability > to deploy new features. To remediate these problems, vendors of > DNS software and also big public DNS providers are going to > remove certain workarounds on February 1st, 2019. > I would like to note that there is an entire segment of the population that does not interact with technology between sundown on Friday, all the way through Sunday morning. Choosing Friday as a day to carry out an operational change of this sort does not seem to have given thought that if things break, there is a possibility they will have to stay broken for at least a full day before the right people can be engaged to work on the issue. In the future, can we try to schedule such events with more consideration on which day the change will take place? I will also note that this weekend is the Superbowl in the US; one of the bigger advertising events of the year. Potentially breaking advertising systems that rely on DNS two days before a major, once-a-year advertising event is *also* somewhat inconsiderate. While I understand that no day will work for everyone, and at some point you just have to pick a day and go for it, I will note that picking the Friday before the Superbowl does seem like a very unfortunate random pick for a day on which to do it. Any chance this could wait until say the Tuesday *after* the Superbowl, when we aren't cutting an entire religion's worth of potential workers out of the workforce available to fix issues in case it turns out to be a bigger problem than is expected, and when we have less chance of annoying the vast army of football-loving fans of every sort? Thanks! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu Jan 31 01:32:17 2019 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 30 Jan 2019 20:32:17 -0500 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> Message-ID: <19454.1548898337@turing-police.cc.vt.edu> On Wed, 30 Jan 2019 23:55:40 +0000, "i3D.net - Martijn Schmidt" said: > Here: all networks that didn't already change their peering IP are not > yet connected to the updated route-server. Some networks are not > connected to any route-server. Therefore, those networks did not yet > change their peering IP. > > I think you can see what's wrong with that statement.. it does not > follow. That has nothing to do with peering department resources, but > everything to do with the chosen peering strategy. Under what conditions would somebody be present at the exchange and not talking to the route server *at all* before the IP change? From nanog at ics-il.net Thu Jan 31 01:34:41 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 30 Jan 2019 19:34:41 -0600 (CST) Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <19454.1548898337@turing-police.cc.vt.edu> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <19454.1548898337@turing-police.cc.vt.edu> Message-ID: <1697451090.1798.1548898479019.JavaMail.mhammett@ThunderFuck> Some companies just don't join route servers as a policy. It can be annoying if you want to talk to them, but I understand there can be various reasons why. It gets very annoying when the peering department isn't responsive to manual peering requests when they're not on the route server because then they might as well not be there at all, as far as you're concerned. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "valdis kletnieks" To: "i3D.net - Martijn Schmidt" Cc: "North American Network Operators' Group" Sent: Wednesday, January 30, 2019 7:32:17 PM Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY On Wed, 30 Jan 2019 23:55:40 +0000, "i3D.net - Martijn Schmidt" said: > Here: all networks that didn't already change their peering IP are not > yet connected to the updated route-server. Some networks are not > connected to any route-server. Therefore, those networks did not yet > change their peering IP. > > I think you can see what's wrong with that statement.. it does not > follow. That has nothing to do with peering department resources, but > everything to do with the chosen peering strategy. Under what conditions would somebody be present at the exchange and not talking to the route server *at all* before the IP change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimpop at domainmail.org Thu Jan 31 01:40:58 2019 From: jimpop at domainmail.org (Jim Popovitch) Date: Wed, 30 Jan 2019 20:40:58 -0500 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: <1548898858.1800.1.camel@domainmail.org> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: > Any chance this could wait until say the Tuesday  > *after* the Superbowl, when we aren't cutting an  > entire religion's worth of potential workers out of  > the workforce available to fix issues in case it  > turns out to be a bigger problem than is expected,  > and when we have less chance of annoying the  > vast army of football-loving fans of every sort?  IIRC, DNS Flag Day was announce way before last years Super Bowl... what did the people who aren't ready for DNS Flag Day do in the past 364 days that they need a few more days to get ready for? -Jim P. From morrowc.lists at gmail.com Thu Jan 31 01:55:26 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 30 Jan 2019 17:55:26 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <1548898858.1800.1.camel@domainmail.org> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> Message-ID: On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG wrote: > On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: > > Any chance this could wait until say the Tuesday > > *after* the Superbowl, when we aren't cutting an > > entire religion's worth of potential workers out of > > the workforce available to fix issues in case it > > turns out to be a bigger problem than is expected, > > and when we have less chance of annoying the > > vast army of football-loving fans of every sort? > > IIRC, DNS Flag Day was announce way before last years Super Bowl... > what did the people who aren't ready for DNS Flag Day do in the past > 364 days that they need a few more days to get ready for? > > Oh, so they had 365 days to plan the time of the event and still picked a friday for that event? https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays I see. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 31 02:07:58 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 31 Jan 2019 13:07:58 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> Message-ID: <5D57387B-EFA8-4EA0-91CE-D210D9E47805@isc.org> This basically affects sites using really old Windows DNS servers (Microsoft decided to make them only respond once with FORMERR so if that message is lost they appear to be dead until the timer clears) and those using firewalls that block EDNS queries. If you use such firewalls they are really doing nothing useful. Most of the other errors reported are benign as far as DNS flag day is concerned. Also apart from the public DNS resolvers people need to install updated software that has the work arounds removed. Mark -- Mark Andrews > On 31 Jan 2019, at 12:22, Matthew Petach wrote: > > > >> On Wed, Jan 23, 2019 at 4:12 PM Brian Kantor wrote: >> Quoting from the web site at https://dnsflagday.net/ > [...] >> The current DNS is unnecessarily slow and suffers from inability >> to deploy new features. To remediate these problems, vendors of >> DNS software and also big public DNS providers are going to >> remove certain workarounds on February 1st, 2019. > > > I would like to note that there is an entire > segment of the population that does not > interact with technology between sundown > on Friday, all the way through Sunday > morning. > > Choosing Friday as a day to carry out an > operational change of this sort does not > seem to have given thought that if things > break, there is a possibility they will have > to stay broken for at least a full day before > the right people can be engaged to work on > the issue. > > In the future, can we try to schedule such events > with more consideration on which day the change > will take place? > > I will also note that this weekend is the Superbowl > in the US; one of the bigger advertising events of the > year. Potentially breaking advertising systems that > rely on DNS two days before a major, once-a-year > advertising event is *also* somewhat inconsiderate. > > While I understand that no day will work for everyone, > and at some point you just have to pick a day and go > for it, I will note that picking the Friday before the > Superbowl does seem like a very unfortunate random > pick for a day on which to do it. > > Any chance this could wait until say the Tuesday > *after* the Superbowl, when we aren't cutting an > entire religion's worth of potential workers out of > the workforce available to fix issues in case it > turns out to be a bigger problem than is expected, > and when we have less chance of annoying the > vast army of football-loving fans of every sort? > > Thanks! > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimpop at domainmail.org Thu Jan 31 02:11:40 2019 From: jimpop at domainmail.org (Jim Popovitch) Date: Thu, 31 Jan 2019 02:11:40 +0000 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> Message-ID: <9A50C6D2-9ADE-4264-9977-621F098D9C9E@domainmail.org> On January 31, 2019 1:55:26 AM UTC, Christopher Morrow wrote: >On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG > >wrote: > >> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> > Any chance this could wait until say the Tuesday >> > *after* the Superbowl, when we aren't cutting an >> > entire religion's worth of potential workers out of >> > the workforce available to fix issues in case it >> > turns out to be a bigger problem than is expected, >> > and when we have less chance of annoying the >> > vast army of football-loving fans of every sort? >> >> IIRC, DNS Flag Day was announce way before last years Super Bowl... >> what did the people who aren't ready for DNS Flag Day do in the past >> 364 days that they need a few more days to get ready for? >> >> >Oh, so they had 365 days to plan the time of the event and still picked >a >friday for that event? > >https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays > >I see. Well, you are either ready or you're not ...doing it on a Tuesday morning is not going to make any difference at this point. -Jim P. From marka at isc.org Thu Jan 31 02:23:15 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 31 Jan 2019 13:23:15 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> Message-ID: <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> You do realise that when the day was chosen it was just the date after which new versions of name servers by the original group of Open Source DNS developers would not have the work arounds incorporated? For ISC that will be BIND 9.14.0 and no that will not be available Feb 1 but you can use the development version 9.13 which has had the code for a while now. Individual operators of resolvers will make their own decisions about when to deploy. -- Mark Andrews > On 31 Jan 2019, at 12:55, Christopher Morrow wrote: > > > >> On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG wrote: >> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> > Any chance this could wait until say the Tuesday >> > *after* the Superbowl, when we aren't cutting an >> > entire religion's worth of potential workers out of >> > the workforce available to fix issues in case it >> > turns out to be a bigger problem than is expected, >> > and when we have less chance of annoying the >> > vast army of football-loving fans of every sort? >> >> IIRC, DNS Flag Day was announce way before last years Super Bowl... >> what did the people who aren't ready for DNS Flag Day do in the past >> 364 days that they need a few more days to get ready for? >> > > Oh, so they had 365 days to plan the time of the event and still picked a friday for that event? > > https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays > > I see. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Jan 31 03:49:46 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 30 Jan 2019 19:49:46 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> Message-ID: On Wed, Jan 30, 2019 at 6:23 PM Mark Andrews wrote: > You do realise that when the day was chosen it was just the date after > which new versions of name servers by the original group of Open Source DNS > you do realize you are proposing to make a breaking change (breaking change to a global system) on a friday. delaying until the following monday would not have mattered to you, I'm sure it's going to matter to other folks though. thanks, -chris > developers would not have the work arounds incorporated? > > For ISC that will be BIND 9.14.0 and no that will not be available Feb 1 > but you can use the development version 9.13 which has had the code for a > while now. > > Individual operators of resolvers will make their own decisions about when > to deploy. > -- > Mark Andrews > > On 31 Jan 2019, at 12:55, Christopher Morrow > wrote: > > > > On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG > wrote: > >> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> > Any chance this could wait until say the Tuesday >> > *after* the Superbowl, when we aren't cutting an >> > entire religion's worth of potential workers out of >> > the workforce available to fix issues in case it >> > turns out to be a bigger problem than is expected, >> > and when we have less chance of annoying the >> > vast army of football-loving fans of every sort? >> >> IIRC, DNS Flag Day was announce way before last years Super Bowl... >> what did the people who aren't ready for DNS Flag Day do in the past >> 364 days that they need a few more days to get ready for? >> >> > Oh, so they had 365 days to plan the time of the event and still picked a > friday for that event? > > > https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays > > I see. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Jan 31 04:10:28 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 30 Jan 2019 21:10:28 -0700 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: Message-ID: <3ad7efd02d6ab74781c0ba598cf2c0f6@mail.dessus.com> The best time is usually a Wednesday at Noon or 11:00 in the impacted timezone. Of course, if the impact is worldwide then that would probably be UT1 :) --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher >Morrow >Sent: Wednesday, 30 January, 2019 18:55 >To: Jim Popovitch >Cc: nanog >Subject: Re: DNS Flag Day, Friday, Feb 1st, 2019 > > > >On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG > wrote: > > > On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: > > Any chance this could wait until say the Tuesday > > *after* the Superbowl, when we aren't cutting an > > entire religion's worth of potential workers out of > > the workforce available to fix issues in case it > > turns out to be a bigger problem than is expected, > > and when we have less chance of annoying the > > vast army of football-loving fans of every sort? > > IIRC, DNS Flag Day was announce way before last years Super >Bowl... > what did the people who aren't ready for DNS Flag Day do in the >past > 364 days that they need a few more days to get ready for? > > > > >Oh, so they had 365 days to plan the time of the event and still >picked a friday for that event? > >https://www.opsview.com/resources/system-administrator/blog/three- >reasons-why-not-make-major-it-changes-fridays > >I see. From mnovakovic at linkedin.com Thu Jan 31 04:16:27 2019 From: mnovakovic at linkedin.com (Marijana Novakovic) Date: Thu, 31 Jan 2019 04:16:27 +0000 Subject: Calling Jason Lixfeld @ DE-CIX NY Message-ID: Greetings Jason, Do you see your new IPv4 session UP at DE-CIX NY with LinkedIn? Thanks ! Kind regards, Mara -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Thu Jan 31 04:28:17 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 30 Jan 2019 20:28:17 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <3ad7efd02d6ab74781c0ba598cf2c0f6@mail.dessus.com> References: <3ad7efd02d6ab74781c0ba598cf2c0f6@mail.dessus.com> Message-ID: On Wed, Jan 30, 2019 at 8:10 PM Keith Medcalf wrote: > > The best time is usually a Wednesday at Noon or 11:00 in the impacted > timezone. Of course, if the impact is worldwide then that would probably > be UT1 :) that still sounds like: "not friday" right? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Thu Jan 31 04:32:01 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 30 Jan 2019 22:32:01 -0600 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> Message-ID: On Wed, Jan 30, 2019 at 9:51 PM Christopher Morrow wrote: > you do realize you are proposing to make a breaking change (breaking change to > a global system) on a friday. delaying until the following monday would not have There are reasons to prefer a Friday over other days as well, but the internet doesn't schedule around random participant's personal preferences. Besides, its a substantial misrepresentation of what the DNS Flag day is to describe it as a "breaking change" made on a certain date - changes won't finish in a week, changes won't finish in two weeks --- every day of the week may be affected until the gradual process of every OS and DNS vendor releasing and every end user upgrading finishes. Each software vendor and service provider will have their very own update schedules regarding on what exact date the next version release and every manager of a system with a DNS Resolver software installation will have their own choice on when they actually install the next update at their site. Just because all the major maintainers of DNS resolver software agree all releases after tomorrow will remove the workarounds for broken DNS servers/firewalls that silently discard queries does not mean every software vendor is shipping their new code to release on Feb 1, _and_ every end user is rushing to upgrade their DNS resolver to remove the workarounds. -- -JH From marka at isc.org Thu Jan 31 05:18:27 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 31 Jan 2019 16:18:27 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> Message-ID: The only ones that could potentially make a “breaking change” on the Feb 1 are Google, Cloudflare and Quad9. They are the public DNS recursive server operators that have committed to removing work arounds. Google has already stated publicly that it will be introducing changes gradually and I expect the other to also do so. Name server developers DO NOT have that power. Google, Cloudflare and Quad9 are needed so the collectively we don’t need to deal with “but it works with …”. That also the reason for the rest of the vendors doing it in unison. What is needed next is for infrastructure zone operators to down load the compliance tools and run them on the servers listed in their zones daily and then inform the owners of those delegations that their zones are on non-compliant servers and give them a dead line to fix them (120 days should be enough time). If the servers aren’t fixed by the dead line the delegation is removed until the servers are fixed or replaced with compliant ones. This will catch operators who install out-of-compliance servers and firewalls. The reaction so far by DNS server operators to DNS flag day shows that this is not actually unreasonable to require. The fixed code is out there for both name servers and firewalls. Mark > On 31 Jan 2019, at 2:49 pm, Christopher Morrow wrote: > > > > On Wed, Jan 30, 2019 at 6:23 PM Mark Andrews wrote: > You do realise that when the day was chosen it was just the date after which new versions of name servers by the original group of Open Source DNS > > you do realize you are proposing to make a breaking change (breaking change to a global system) on a friday. > delaying until the following monday would not have mattered to you, I'm sure it's going to matter to other folks though. > > thanks, > -chris > > developers would not have the work arounds incorporated? > > For ISC that will be BIND 9.14.0 and no that will not be available Feb 1 but you can use the development version 9.13 which has had the code for a while now. > > Individual operators of resolvers will make their own decisions about when to deploy. > -- > Mark Andrews > > On 31 Jan 2019, at 12:55, Christopher Morrow wrote: > >> >> >> On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG wrote: >> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> > Any chance this could wait until say the Tuesday >> > *after* the Superbowl, when we aren't cutting an >> > entire religion's worth of potential workers out of >> > the workforce available to fix issues in case it >> > turns out to be a bigger problem than is expected, >> > and when we have less chance of annoying the >> > vast army of football-loving fans of every sort? >> >> IIRC, DNS Flag Day was announce way before last years Super Bowl... >> what did the people who aren't ready for DNS Flag Day do in the past >> 364 days that they need a few more days to get ready for? >> >> >> Oh, so they had 365 days to plan the time of the event and still picked a friday for that event? >> >> https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays >> >> I see. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jan 31 06:54:43 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 31 Jan 2019 17:54:43 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> Message-ID: <2D74B248-557E-487B-9603-F66808766F84@isc.org> Don’t forget the reverse tree as well. > On 31 Jan 2019, at 5:40 pm, Hank Nussbacher wrote: > > On 31/01/2019 07:18, Mark Andrews wrote: > > There is some secret, silent block on my postings to NANOG that the admins have not yet discovered. In the interim can one of you please proxy to the list that people should not forget about testing their inverse as well - *.in-addr.arpa via https://ednscomp.isc.org/ednscomp > > Regards, > Hank -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From hank at interall.co.il Thu Jan 31 07:40:08 2019 From: hank at interall.co.il (hank at interall.co.il) Date: Thu, 31 Jan 2019 09:40:08 +0200 Subject: BGP Experiment Message-ID: <20190131094008.19034tn4uze9n13s@62.219.67.37> On 23/01/2019 19:40, Job Snijders wrote: I agree with Job. Continue the experiment and warn us in advance. -Hank > Dear Ben, all, > > I'm not sure this experiment should be canceled. On the public Internet > we MUST assume BGP speakers are compliant with the BGP-4 protocol. > Broken BGP-4 speakers are what they are: broken. They must be fixed, or > the operator must accept the consequences. > > "Get a sandbox like every other researcher" is not a fair statement, one > can also posit "Get a compliant BGP-4 implementation like every other > network operator". > > When bad guys explicitly seek to target these Asian and Australian > operators you reference (who apparently have not upgraded to the vendor > recommended release), using *valid* BGP updates, will a politely emailed > request help resolve the situation? Of course not! > > Stopping the experiment is only treating symptoms, the root cause must > be addressed: broken software. > > Kind regards, > > Job From thomas.king at de-cix.net Thu Jan 31 07:51:47 2019 From: thomas.king at de-cix.net (Thomas King) Date: Thu, 31 Jan 2019 07:51:47 +0000 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <19454.1548898337@turing-police.cc.vt.edu> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <19454.1548898337@turing-police.cc.vt.edu> Message-ID: <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> Hi Ren et al., Thanks for pointing out that some peers do not use the route servers. This group can be subdivided in a group of peers not sending any IP prefixes to the route servers while maintaining a route server BGP session, and a group of peers not even connecting to the route server. The latter do not show up in the "BGP session established" section even if they have applied the required IPv4 changes. Best regards, Thomas On 31.01.19, 02:32, "valdis.kletnieks at vt.edu" wrote: On Wed, 30 Jan 2019 23:55:40 +0000, "i3D.net - Martijn Schmidt" said: > Here: all networks that didn't already change their peering IP are not > yet connected to the updated route-server. Some networks are not > connected to any route-server. Therefore, those networks did not yet > change their peering IP. > > I think you can see what's wrong with that statement.. it does not > follow. That has nothing to do with peering department resources, but > everything to do with the chosen peering strategy. Under what conditions would somebody be present at the exchange and not talking to the route server *at all* before the IP change? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5353 bytes Desc: not available URL: From mark.tinka at seacom.mu Thu Jan 31 08:08:12 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 10:08:12 +0200 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> Message-ID: On 31/Jan/19 09:51, Thomas King wrote: > Hi Ren et al., > > Thanks for pointing out that some peers do not use the route servers. This group can be subdivided in a group of peers not sending any IP prefixes to the route servers while maintaining a route server BGP session, and a group of peers not even connecting to the route server. The latter do not show up in the "BGP session established" section even if they have applied the required IPv4 changes. I believe most exchange points maintain both route servers and route collectors. Generally, most peers will connect to the RS, but not all. As you mention, some may connect but not send any routes. However, I believe all peers will connect to the RC. Of course, I can envisage scenarios where even this could be selectively done. But the reasons for (not) connecting to the RC are very different from those for (not) connecting to the RS. Mark. From adamv0025 at netconsultings.com Thu Jan 31 09:16:55 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Thu, 31 Jan 2019 09:16:55 -0000 Subject: BGP Experiment In-Reply-To: References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> <01a601d4b403$de7b2160$9b716420$@netconsultings.com> Message-ID: <00df01d4b945$b68aaad0$23a00070$@netconsultings.com> > From: Saku Ytti > Sent: Friday, January 25, 2019 7:59 AM > > On Thu, 24 Jan 2019 at 18:43, wrote: > > > We fight with that all the time, > > I'd say that from the whole Design->Certify->Deploy->Verify->Monitor > service lifecycle time budget, the service certification testing is almost half of > it. > > That's why I'm so interested in a model driven design and testing approach. > > This shop has 100% automated blackbox testing, and still they have to cherry- > pick what to test. > Sure one tests only for the few specific current and near future use cases. > Do you have statistics how often you find show-stopper > issues and how far into the test they were found? > I don't keep those statistics, but running bug scrubs in order to determine the code for regression testing is usually good starting point to avoid show-stoppers, what is then found later on during the testing is usually patched -so yes you end up with a brand new code and several patches related to your use cases (PEs, Ps, etc..) > I expect this to be > exponential curve, like upgrading box, getting your signalling protocols up, > pushing one packet in each service you sell is easy and fast, I wonder will > massive amount of work increase confidence significantly from that. > Yes it will. > The > issues I tend to find in production are issues which are not trivial to recreate > in lab, once we know what they are, which implies that finding them a-priori > is bit naive expectation. So, assumptions: > This is because you did your due diligence during the testing. Do you have statistics on the probability of these "complex" bugs occurrence? > Hopefully we'll enter NOS future where we download NOS from github and > compile it to our devices. Allowing whole community to contribute to unit > testing and use-cases and to run minimal bug surface code in your > environment. > Not there yet, but you can compile your own routing protocols and run those on vendor OS. > I see very little future in blackbox testing vendor NOS at operator site, > beyond quick poke at lab. Seems like poor value. Rather have pessimistic > deployment plan, lab => staging => 2-3 low risk site => > 2-3 high risk site => slow roll up > Yes that's also a possibility -one of the strong arguments for massive disaggregation at the edge, to reduce the fallout of a potential critical failure. Depends on the shop really. > > I really need to have this ever growing library of test cases that the automat > will churn through with very little human intervention, in order to reduce the > testing from months to days or weeks at least. > > Lot of vendor, maybe all, accept your configuration and test them for > releases. I think this is only viable solution vendors have for blackbox, gather > configs from customers and test those, instead of try to guess what to test. > I've done that with Cisco in two companies, unfortunately I can't really tell if it > impacted quality, but I like to think it did. > Did that with juniper partners and now directly with Juniper. The thing is though they are using our test plan... adam From saku at ytti.fi Thu Jan 31 09:23:01 2019 From: saku at ytti.fi (Saku Ytti) Date: Thu, 31 Jan 2019 11:23:01 +0200 Subject: BGP Experiment In-Reply-To: <00df01d4b945$b68aaad0$23a00070$@netconsultings.com> References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> <01a601d4b403$de7b2160$9b716420$@netconsultings.com> <00df01d4b945$b68aaad0$23a00070$@netconsultings.com> Message-ID: Hey, > This is because you did your due diligence during the testing. > Do you have statistics on the probability of these "complex" bugs occurrence? No. I wish I had and I hope to make change on this. Try to translate how good investment test is, how many customer outages it has saved etc. I suspect simple bugs are found by vendor, complex bugs are not economic to find. And testing is more proof of work than business case. -- ++ytti From nanog at radu-adrian.feurdean.net Thu Jan 31 09:25:29 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 31 Jan 2019 04:25:29 -0500 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> Message-ID: <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > You do realise that when the day was chosen it was just the date after > which new versions of name servers by the original group of Open Source > DNS developers would not have the work arounds incorporated? I think it's pretty safe to say that the "DNS Flag day" is more like a date of "end of support" rather than an "service termination". My guess is that some uncompliant servers will be still running long after that date... -- R-A.F. From nanog at studio442.com.au Thu Jan 31 10:04:45 2019 From: nanog at studio442.com.au (Julien Goodwin) Date: Thu, 31 Jan 2019 21:04:45 +1100 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> Message-ID: <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> On 31/1/19 7:08 pm, Mark Tinka wrote: > I believe most exchange points maintain both route servers and route > collectors. > > Generally, most peers will connect to the RS, but not all. As you > mention, some may connect but not send any routes. > > However, I believe all peers will connect to the RC. Of course, I can > envisage scenarios where even this could be selectively done. But the > reasons for (not) connecting to the RC are very different from those for > (not) connecting to the RS. Back when I looked more deeply at this (mid-2014 when I was redoing the AS15169 policy around this area) I saw things rather differently, and my impression is little has changed since. Even in exchanges that strongly encourage their use route collectors were much less connected to than route servers, and few exchanges had them in the first place. Part of the problem with advertising on route servers is many clients, including networks that should know better often treat those routes as a higher priority than is sensible, in some cases equal or higher than a PNI link in the same city. Yes we could have used prepends, but that's not necessarily effective and affects everyone for the actions of a few, and is why the routes AS15169 advertised on route servers reduced back then. From marka at isc.org Thu Jan 31 11:15:08 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 31 Jan 2019 22:15:08 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> Message-ID: <711AA33B-3BBB-4F9B-80D5-7FC52A72D65D@isc.org> -- Mark Andrews > On 31 Jan 2019, at 20:25, Radu-Adrian Feurdean wrote: > > > >> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: >> You do realise that when the day was chosen it was just the date after >> which new versions of name servers by the original group of Open Source >> DNS developers would not have the work arounds incorporated? > > I think it's pretty safe to say that the "DNS Flag day" is more like a date of "end of support" rather than an "service termination". My guess is that some uncompliant servers will be still running long after that date... > > -- > R-A.F. From mpetach at netflight.com Thu Jan 31 11:59:24 2019 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 31 Jan 2019 03:59:24 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> Message-ID: On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean < nanog at radu-adrian.feurdean.net wrote: > > > On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > > You do realise that when the day was chosen it was just the date after > > which new versions of name servers by the original group of Open Source > > DNS developers would not have the work arounds incorporated? > > I think it's pretty safe to say that the "DNS Flag day" is more like a > date of "end of support" rather than an "service termination". My guess is > that some uncompliant servers will be still running long after that date... > > -- > R-A.F. > (resending from correct address) Right. The concern is that it's *also* the date when all the major recursive lookup servers are changing their behaviour. New software availability date? Awesome, go for it. Google, Cloudflare, Quad9 all changing their codebase/response behaviour on a Friday before a major sporting and advertising event? Not sounding like a really great idea from this side of the table. Are we certain that the changes on the part of the big four recursive DNS operators won't cause downstream issues? As someone noted earlier, this mainly affects products from a specific company, Microsoft, and L7 load balancers like A10s. I'm going to hope legal teams from each of the major recursive providers were consulted ahead of time to vet the effort, and ensure there were no concerns about collusion or anticompetitive practices, right? I'm fine with rolling out software that stops supporting bad behaviour. What I find to be concerning is when supposedly competing entities all band together in a pact that largely holds the rest of the world hostage to their arbitrary timeline. Perhaps it's time to create a new recursive resolver service that explicitly *is not* part of the cabal... Matt (hoping and praying this weekend will go smoothly) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jan 31 12:20:42 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 14:20:42 +0200 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> Message-ID: On 31/Jan/19 12:04, Julien Goodwin wrote: > Even in exchanges that strongly encourage their use route collectors > were much less connected to than route servers, and few exchanges had > them in the first place. We, for example, connect to RS's more selectively. We are more liberal about RC's since they do not have an impact on our forwarding paradigm, and it helps the exchange point know what's happening across their fabric. But yes, I do imagine that interest level of connecting to either an RS or RC could vary, particularly the larger of a network you are. > > Part of the problem with advertising on route servers is many clients, > including networks that should know better often treat those routes as a > higher priority than is sensible, in some cases equal or higher than a > PNI link in the same city. Well, there are a number of peers that do not have a linear peering relationship for all routes available at an exchange point, i.e., they don't see those routes both via the RS and bi-lateral sessions. For many networks, RS is the true source and bi-lateral sessions are not even considered. We may not always peer with an RS, but we will always have bi-lateral sessions... even when we have sessions to the RS. Mark. From nanog at ics-il.net Thu Jan 31 12:59:33 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Jan 2019 06:59:33 -0600 (CST) Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> Message-ID: <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> Do people not know how to use local pref and MED to prefer PNI over route server? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: nanog at nanog.org Sent: Thursday, January 31, 2019 6:20:42 AM Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY On 31/Jan/19 12:04, Julien Goodwin wrote: > Even in exchanges that strongly encourage their use route collectors > were much less connected to than route servers, and few exchanges had > them in the first place. We, for example, connect to RS's more selectively. We are more liberal about RC's since they do not have an impact on our forwarding paradigm, and it helps the exchange point know what's happening across their fabric. But yes, I do imagine that interest level of connecting to either an RS or RC could vary, particularly the larger of a network you are. > > Part of the problem with advertising on route servers is many clients, > including networks that should know better often treat those routes as a > higher priority than is sensible, in some cases equal or higher than a > PNI link in the same city. Well, there are a number of peers that do not have a linear peering relationship for all routes available at an exchange point, i.e., they don't see those routes both via the RS and bi-lateral sessions. For many networks, RS is the true source and bi-lateral sessions are not even considered. We may not always peer with an RS, but we will always have bi-lateral sessions... even when we have sessions to the RS. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jan 31 13:09:54 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 15:09:54 +0200 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> Message-ID: <858063d9-68d2-f3fc-8adf-06b28a391261@seacom.mu> On 31/Jan/19 14:59, Mike Hammett wrote: > Do people not know how to use local pref and MED to prefer PNI over > route server? We don't particularly care how the routes are learned. Routes are routes. Our motivation for or against peering with an RS is granular policy control, and the level of trust we can put in the stability of the same over time. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Thu Jan 31 13:43:32 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 31 Jan 2019 07:43:32 -0600 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> Message-ID: On Thu, Jan 31, 2019 at 6:01 AM Matthew Petach wrote: > Google, Cloudflare, Quad9 all changing their codebase/response behaviour on a Friday before a major sporting and advertising event? > Not sounding like a really great idea from this side of the table. If your DNS zone is hosted on Google or Cloudflare's servers, then you should have nothing to worry about, other than your end users having a broken firewall in between their DNS resolver and the internet, and then updating their resolver software.... Actually, none of those providers announced detailed plans, at least yet; and maybe they won't even bother announcing. they could update their software yesterday if they wanted, or they could wait until next week, and it would still be "On or Around Feb 1, 2019." The 'Flag Day' is not a specific moment at which all providers necessarily push a big red button at the same instant to remove their workaround for broken DNS servers discarding queries. > Are we certain that the changes on the part of the big four recursive DNS operators won't cause downstream issues? Not downstream issues. They will break resolution of the domains which have authoritative DNS servers that discard or ignore DNS queries which comply with all the original DNS standards but contain EDNS attributes. The common cause for this was Authoritative DNS servers placed behind 3rd party Firewalls that tried to "inspect" DNS traffic and discard queries and responses with "unknown" properties or sizes larger than 512 --- there may also be an esoteric DNS proxy/ balancer implementation with bugs, or some broken authoritative server implementations running software that was more than 10 years past End of Support at this point. If your authoritative DNS service sits behind such a broken device or on such broken DNS server, then clients already have troubles resolving your domains, and some time after the DNS Flag day, it will likely stop working altogether. > As someone noted earlier, this mainly affects products from a specific company, Microsoft, and L7 load balancers like A10s. I'm going to hope legal teams from each of the major recursive providers were consulted ahead of time to vet the effort, and ensure there were no concerns about collusion or anticompetitive practices, right? I wouldn't be too concerned. The operators of a recursive DNS service very likely won't have an agreement giving them a duty to Microsoft, A10, etc; If you have a software or service that you expect to interoperate with DNS resolvers, then its on you to make sure your implementation of the software or service complies with the agreed standards regarding its processing of compliant messages. -- -JH From nanog at ics-il.net Thu Jan 31 13:54:18 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Jan 2019 07:54:18 -0600 (CST) Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <858063d9-68d2-f3fc-8adf-06b28a391261@seacom.mu> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> <858063d9-68d2-f3fc-8adf-06b28a391261@seacom.mu> Message-ID: <899873934.1985.1548942858062.JavaMail.mhammett@ThunderFuck> Not all routes are created equal. If you have a PNI and an IX connection of equal capacity, obviously the IX connection will fill up first given that there is more opportunity there. Also, there are more moving parts in an IX (and accompanying route servers), thus more to go wrong. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, January 31, 2019 7:09:54 AM Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY On 31/Jan/19 14:59, Mike Hammett wrote: Do people not know how to use local pref and MED to prefer PNI over route server? We don't particularly care how the routes are learned. Routes are routes. Our motivation for or against peering with an RS is granular policy control, and the level of trust we can put in the stability of the same over time. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jan 31 14:14:44 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 16:14:44 +0200 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <899873934.1985.1548942858062.JavaMail.mhammett@ThunderFuck> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <19454.1548898337@turing-police.cc.vt.edu> <850D5922-4DF0-4CF8-A273-1E1732CA4169@de-cix.net> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> <858063d9-68d2-f3fc-8adf-06b28a391261@seacom.mu> <899873934.1985.1548942858062.JavaMail.mhammett@ThunderFuck> Message-ID: <7fb6797b-16f0-7bfd-7861-169dd784a532@seacom.mu> On 31/Jan/19 15:54, Mike Hammett wrote: > Not all routes are created equal. If you have a PNI and an IX > connection of equal capacity, obviously the IX connection will fill up > first given that there is more opportunity there. I think you meant to say not all "paths" are equal. Routes are routes. Where they lead to is another matter. The presence of a PNI does not preclude good governance of an exchange point link. If you are going to (willingly or otherwise) ignore the health of your public peering links over your private ones (or vice versa), then I wish upon you all the hell you'll face that comes with taking that position. Our policy is simple - 50% utilized, you upgrade. Doesn't matter what type of link it is; WDM Transport, IP, peering (public or private), Metro, core backbone, protection paths, e.t.c. Choosing to let your public peering links run hot because your "major" peers are taken care of by the private links is irresponsible. Do a lot of networks do it; hell yes, and for reasons you'd not think are obvious. > Also, there are more moving parts in an IX (and accompanying route > servers), thus more to go wrong. Agreed, but that's not the crux of this thread (even though it's one of the reasons we do not relay solely on RS's). Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 31 14:15:59 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 01:15:59 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> Message-ID: <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> > On 31 Jan 2019, at 10:59 pm, Matthew Petach wrote: > > > > On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean > > On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > > You do realise that when the day was chosen it was just the date after > > which new versions of name servers by the original group of Open Source > > DNS developers would not have the work arounds incorporated? > > I think it's pretty safe to say that the "DNS Flag day" is more like a date of "end of support" rather than an "service termination". My guess is that some uncompliant servers will be still running long after that date... > > -- > R-A.F. > > > (resending from correct address) > > Right. > > The concern is that it's *also* the date when all the major recursive lookup servers are changing their behaviour. > > New software availability date? > Awesome, go for it. > > Google, Cloudflare, Quad9 all changing their codebase/response behaviour on a Friday before a major sporting and advertising event? > > Not sounding like a really great idea from this side of the table. > > Are we certain that the changes on the part of the big four recursive DNS operators won't cause downstream issues? > > As someone noted earlier, this mainly affects products from a specific company, Microsoft, and L7 load balancers like A10s. I'm going to hope legal teams from each of the major recursive providers were consulted ahead of time to vet the effort, and ensure there were no concerns about collusion or anticompetitive practices, right? > > I'm fine with rolling out software that stops supporting bad behaviour. > > What I find to be concerning is when supposedly competing entities all band together in a pact that largely holds the rest of the world hostage to their arbitrary timeline. > > Perhaps it's time to create a new recursive resolver service that explicitly *is not* part of the cabal... > > Matt > (hoping and praying this weekend will go smoothly) So you are worrying about sites running Windows DNS from prior to Windows Server 2003 (this is where Microsoft added EDNS support) and sites that have a firewall that blocks all EDNS queries. The large recursive server farms don’t do DNS COOKIE so you don’t need to worry about that. Those Windows servers work most of the time even with a DNS servers that don’t fall back to plain DNS on timeout. And if you have installed a firewall that blocks EDNS you have shot yourself in the foot. We actually have a hard time finding zones where all the servers are broken enough to not work with servers that don’t fallback to plain DNS on timeout. We can find zones where some of the servers are like that, but there is usually one or more servers that do respond correctly. Of the datasets I’ve looked at that 1 in 10,000 to 1 in 100,000 zones will have problems with updated servers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From list at satchell.net Thu Jan 31 14:21:46 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 31 Jan 2019 06:21:46 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> Message-ID: <674fbb87-06dd-93f3-0b5b-f3681c9fc83b@satchell.net> After reading through the thread, this reminds me of the Y2K flap, that turned into a non-event. My checks of authoritative DNS servers for my domains show no issues now. From nanog at ics-il.net Thu Jan 31 14:22:21 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Jan 2019 08:22:21 -0600 (CST) Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <7fb6797b-16f0-7bfd-7861-169dd784a532@seacom.mu> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> <858063d9-68d2-f3fc-8adf-06b28a391261@seacom.mu> <899873934.1985.1548942858062.JavaMail.mhammett@ThunderFuck> <7fb6797b-16f0-7bfd-7861-169dd784a532@seacom.mu> Message-ID: <1805095629.2161.1548944539686.JavaMail.mhammett@ThunderFuck> A prefix is a prefix. A route is a prefix plus a next-hop. Your next hop for your PNI is different than your IX. I don't believe I advocated running IX links hot. Financially, as an IX operator, I'd prefer that people ran all their bits over an IX and that all links were best kept below 10% utilization. ;-) Obviously I know that's not good engineering or fiscally responsible on the network's behalf. Just going to the extreme to support my point. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, January 31, 2019 8:14:44 AM Subject: Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY On 31/Jan/19 15:54, Mike Hammett wrote: Not all routes are created equal. If you have a PNI and an IX connection of equal capacity, obviously the IX connection will fill up first given that there is more opportunity there. I think you meant to say not all "paths" are equal. Routes are routes. Where they lead to is another matter. The presence of a PNI does not preclude good governance of an exchange point link. If you are going to (willingly or otherwise) ignore the health of your public peering links over your private ones (or vice versa), then I wish upon you all the hell you'll face that comes with taking that position. Our policy is simple - 50% utilized, you upgrade. Doesn't matter what type of link it is; WDM Transport, IP, peering (public or private), Metro, core backbone, protection paths, e.t.c. Choosing to let your public peering links run hot because your "major" peers are taken care of by the private links is irresponsible. Do a lot of networks do it; hell yes, and for reasons you'd not think are obvious.
Also, there are more moving parts in an IX (and accompanying route servers), thus more to go wrong.
Agreed, but that's not the crux of this thread (even though it's one of the reasons we do not relay solely on RS's). Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jan 31 14:26:23 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 16:26:23 +0200 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <1805095629.2161.1548944539686.JavaMail.mhammett@ThunderFuck> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <93ce567f-3ec5-b91a-fb7e-f4775daa925a@studio442.com.au> <1499479334.1957.1548939569456.JavaMail.mhammett@ThunderFuck> <858063d9-68d2-f3fc-8adf-06b28a391261@seacom.mu> <899873934.1985.1548942858062.JavaMail.mhammett@ThunderFuck> <7fb6797b-16f0-7bfd-7861-169dd784a532@seacom.mu> <1805095629.2161.1548944539686.JavaMail.mhammett@ThunderFuck> Message-ID: <74c285ee-363a-d045-1c01-da6ce0a61d46@seacom.mu> On 31/Jan/19 16:22, Mike Hammett wrote: > A prefix is a prefix. A route is a prefix plus a next-hop. Your next > hop for your PNI is different than your IX. And for me, it doesn't matter as long as I am maintaining both my public link sand PNI's properly. If my peers are not, I'm happy to take the longer path to reach them until they are sufficiently incentivized to fix that. At the very least, there won't be packet loss :-). Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Thu Jan 31 14:31:57 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 01:31:57 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <674fbb87-06dd-93f3-0b5b-f3681c9fc83b@satchell.net> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <674fbb87-06dd-93f3-0b5b-f3681c9fc83b@satchell.net> Message-ID: > On 1 Feb 2019, at 1:21 am, Stephen Satchell wrote: > > After reading through the thread, this reminds me of the Y2K flap, that > turned into a non-event. My checks of authoritative DNS servers for my > domains show no issues now. As did I, but if we didn’t try and give lots of notice people would have complained. That said a lot of servers have been fixed that where not fully compliant and firewalls that unnecessarily blocked well formed EDNS packets with one or more of the extension mechanism present have been turned off. The authoritative DNS server space is much cleaner now and we the data to show it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From David.Hiers at cdk.com Thu Jan 31 14:37:23 2019 From: David.Hiers at cdk.com (Hiers, David) Date: Thu, 31 Jan 2019 14:37:23 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <9578293AE169674F9A048B2BC9A081B40318EFA2AC@MUNPRDMBXA1.medline.com> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> <91D1AB79-83EF-4835-991C-0D0899F30EC4@beckman.org> <9578293AE169674F9A048B2BC9A081B40318EFA257@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40318EFA2AC@MUNPRDMBXA1.medline.com> Message-ID: Excessive cold killed us once when the air exit vents froze shut. From: NANOG [mailto:nanog-bounces+david.hiers=cdk.com at nanog.org] On Behalf Of Naslund, Steve Sent: Wednesday, January 30, 2019 9:43 AM To: nanog at nanog.org Subject: RE: Effects of Cold Front on Internet Infrastructure - U.S. Midwest Ironically you don’t really save a lot of energy when it’s this cold because the loops are running at high speed and the humidification coils are working overtime to keep the RH up in the room. People think we can bring in all the outside cold we want but the issue then is humidity stability. Steven Naslund Chicago IL ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stahr at mailbag.com Thu Jan 31 16:32:01 2019 From: stahr at mailbag.com (James Stahr) Date: Thu, 31 Jan 2019 10:32:01 -0600 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> Message-ID: On 2019-01-31 08:15, Mark Andrews wrote: > We actually have a hard time finding zones where all the servers are > broken enough to not work with servers that don’t fallback to plain > DNS on timeout. We can find zones where some of the servers are like > that, but there is usually one or more servers that do respond > correctly. > > Of the datasets I’ve looked at that 1 in 10,000 to 1 in 100,000 zones > will have problems with updated servers. > I think the advertised testing tool may be flawed as blocking TCP/53 is enough to receive a STOP from the dnsflagday web site. It's been my (possibly flawed) understanding that TCP/53 is an option for clients but primarily it is a mechanism for the *server* to request the client communicate using TCP/53 instead - this could be due to UDP response size, anti-spoofing controls, etc... So is the tool right in saying that TCP/53 is a absolute requirement of ENDS0 support for "DNS Flag Day"? If so, do we expect a dramatic increases in TCP/53 requests over UDP/53 queries? Or is the tool flawed in its' claim that the DNS Flag Day changes *require* TCP/53 in order to resolve ones domain? Based upon my reading, the big concern is a edns=timeout result (from the ISC tool) not a edns512tcp=timeout. While I applaud the effort, the message and delivery could have been better. My first read on DNS Flag Day was that this was going to be the day new software versions were to be released which deprecated EDNS0 fallback measures so the adoption would be a gradual process by updating the latest versions of several DNS servers, only to find out that many resolvers used by end users use will be upgrading on Feb 1rst. Now, it sounds like the rollout schedule is on their timetable and could happen over the next several weeks and months. So really not a Flag "Day" now is it? I guess that's also why the date being on a Friday also isn't really a concern... Finally, why has no one stepped up to setup an updated resolver prior to Feb 1rst for actual testing? Or are there instructions on how one could setup their own resolver setup prior to Feb 1rst? No offense, but I'm not jumping to a brand new train of code just to enforce DNS Flag Day but I might choose enforce now under *existing* code bases rather than waiting for everyone else using Cloudflare/Google/OpenDNS as resolver may see me after Feb 1rst? If anyone has such instructions, post them - or put them on dnsflagday.net for anyone else wanting to adopt/test. Just some thoughts... -- -James From owen at delong.com Thu Jan 31 16:42:09 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Jan 2019 08:42:09 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <1548898858.1800.1.camel@domainmail.org> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> Message-ID: <93FC658F-1F96-44CB-ADFE-E623FD605767@delong.com> > On Jan 30, 2019, at 17:40 , Jim Popovitch via NANOG wrote: > > On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> Any chance this could wait until say the Tuesday >> *after* the Superbowl, when we aren't cutting an >> entire religion's worth of potential workers out of >> the workforce available to fix issues in case it >> turns out to be a bigger problem than is expected, >> and when we have less chance of annoying the >> vast army of football-loving fans of every sort? > > IIRC, DNS Flag Day was announce way before last years Super Bowl... > what did the people who aren't ready for DNS Flag Day do in the past > 364 days that they need a few more days to get ready for? > > -Jim P. Consider this… Sometimes you are responsible for fielding the calls and explaining problems that occur on systems that aren’t entirely within your control. A business class ISP, for example, would have a hard time proactively fixing all of their customer’s DNS resolvers and clients. Nonetheless, you can be assured that their call center will get the calls when the behavior of DNS changes in a way that negatively impacts some fraction of those clients. In my estimation, the most likely impact of this event will be on the enterprise, not the ISP or residential communities. The ISP community is either aware of and/or dealt with it in the normal course of business or they have had their head so deep in the sand that I don’t have much sympathy for what happens to them. The residential end user doesn’t run name servers for the most part, so, unlikely to be much impact there. The ones that do (such as myself) are likely technical enough and likely sufficiently involved in the ISP community to have heard about this issue and taken appropriate action. In my experience, enterprise IT, OTOH, is widely variable in its attentiveness to changes on the internet until after they have occurred. Network focused enterprises (e.g. Akamai, DropBox, etc.) are unlikely to be impacted. Other kinds of enterprises for whom the internet is more of a utility than a core function, OTOH, may have less awareness ahead of time (e.g. Chevron, GM, your local dive shop, the bodega on the corner, etc.). The larger enterprises probably have someone paying some attention. I suspect most of the casualties in this event will be in the Small to Medium business community. Owen From fkittred at gwi.net Wed Jan 30 23:05:26 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 30 Jan 2019 18:05:26 -0500 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: Cold changes the transmission characteristics of fiber. At one point we were renting some old dark fiber from the local telephone company in northern Maine. When it would get below -15%-degree F the dB would get bad enough that the link using that fiber would stop working. The telephone company was selling us dark fiber because regulation required them to. They refused to give us another fiber nor inspect/repair. They took the position they were required to sell us fiber, not working fiber. On Wed, Jan 30, 2019 at 11:41 AM Mark Tinka wrote: > For anyone running IP networks in the Midwest, are you having to do > anything special to keep your networks up? > > For the data centres, is this cold front a chance to reduce air > conditioning costs, or is it actually straining the infrastructure? > > I'm curious, from a +27-degree C summer's day here in Johannesburg. > > Mark. > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncariaga at gmail.com Thu Jan 31 15:39:54 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Thu, 31 Jan 2019 23:39:54 +0800 Subject: Latency between Dallas and west coast Message-ID: I would like to know if anyone here maintains average latency ranges between Dallas and Internet Exchanges at the west coast? Is it normal to have around 192ms to 200ms between the two points? Thanks in advance -nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jan 31 16:53:41 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 31 Jan 2019 10:53:41 -0600 (CST) Subject: Latency between Dallas and west coast In-Reply-To: References: Message-ID: <268707779.2369.1548953620041.JavaMail.mhammett@ThunderFuck> It's 180 ms from Dallas to Djibouti, so no, that much latency to the west coast of the US is not normal. http://he.net/layer2/ ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nathanael Catangay Cariaga" To: nanog at nanog.org Sent: Thursday, January 31, 2019 9:39:54 AM Subject: Latency between Dallas and west coast I would like to know if anyone here maintains average latency ranges between Dallas and Internet Exchanges at the west coast? Is it normal to have around 192ms to 200ms between the two points? Thanks in advance -nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jan 31 17:00:48 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Jan 2019 09:00:48 -0800 Subject: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY In-Reply-To: <19454.1548898337@turing-police.cc.vt.edu> References: <45EADB17-FB9A-4322-ACB8-706BFC3B7CA8@lixfeld.ca> <49946B28-449B-489B-ABCC-039E75906D77@puck.nether.net> <526D3DE0-0214-4D10-AAAD-72A3692F3375@de-cix.net> <19454.1548898337@turing-police.cc.vt.edu> Message-ID: <02A8057C-7D26-4F04-AE49-BBA6F8858196@delong.com> > On Jan 30, 2019, at 17:32 , valdis.kletnieks at vt.edu wrote: > > On Wed, 30 Jan 2019 23:55:40 +0000, "i3D.net - Martijn Schmidt" said: > >> Here: all networks that didn't already change their peering IP are not >> yet connected to the updated route-server. Some networks are not >> connected to any route-server. Therefore, those networks did not yet >> change their peering IP. >> >> I think you can see what's wrong with that statement.. it does not >> follow. That has nothing to do with peering department resources, but >> everything to do with the chosen peering strategy. > > Under what conditions would somebody be present at the exchange and > not talking to the route server *at all* before the IP change? Route servers are a double-edged sword for many networks. There are a number of reasons that one might choose not to peer with route servers at an exchange point, even if you are willing to peer with every single individual peer at the exchange. It would be difficult for me to go into specific details without violating NDAs from former employers, but it really doesn’t take all that much imagination. Consider the following questions: 1. What information does one get from a direct peering that is removed by a route server? 2. How does the AS PATH change if you are peering with a route server? 3. What tools are available for measuring results of individual peering sessions vs. sorting out individual next-hops learned from a common peering session? Owen From mark.tinka at seacom.mu Thu Jan 31 17:04:40 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 19:04:40 +0200 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> Message-ID: <2e963381-9963-925c-7fb2-4961b22753df@seacom.mu> On 31/Jan/19 18:32, James Stahr wrote: > > I think the advertised testing tool may be flawed as blocking TCP/53 > is enough to receive a STOP from the dnsflagday web site.  It's been > my (possibly flawed) understanding that TCP/53 is an option for > clients but primarily it is a mechanism for the *server* to request > the client communicate using TCP/53 instead - this could be due to UDP > response size, anti-spoofing controls, etc... On a similar note, we tested for all our self-hosted zones OK 2 weeks ago. However, in previous days, the summary result said "NO GOOD, THINGS WILL BE SLOW COME FLAG DAY". The detailed test showed IPv4 tested perfect, but IPv6 probes timed out. The issue turned out to be an internal IPv6 routing/forwarding issue for our service within Century Link's (Level(3)'s) network. CL finally fixed that issue today and the flag day test tool is happy again. Some of our partners/customers were concerned our name servers were not ready, based purely on the summary result of the test tool. Perhaps adding some intelligence about whether the issue is the name server or the transport may be helpful. Mark. From mysidia at gmail.com Thu Jan 31 17:06:25 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 31 Jan 2019 11:06:25 -0600 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> Message-ID: On Thu, Jan 31, 2019 at 10:33 AM James Stahr wrote: [snip] > So is the tool right in saying that TCP/53 is a absolute requirement of > ENDS0 support for "DNS Flag Day"? If so, do we expect a dramatic > increases in TCP/53 requests over UDP/53 queries? Or is the tool flawed [snip] Their test tool will obviously alert on more error conditions than what the Flag Day is specifically about -- One or more of your DNS servers not responding [OR] TCP/53 not working are still broken configurations, But the brokenness is unrelated to what the flag day is about - In the first case, better safe than sorry, I suppose: Inability to complete one or more of the tests because of brokenness definitely means that things are broken. TCP/53 is a fairly strong requirement, except if you are supporting an authoritative-only server with no record labels that could result in a >512byte response, plus no DNSSEC-secured zones, and even then the AXFR protocol for replication to secondary servers calls for TCP. EDNS support is not required. Authoritative servers that don't support EDNS and are also compliant with the original DNS standard continue to work after the workarounds are removed. The relevant standard does not allow for silently ignoring requests that contain the EDNS option; patching the bug in a broken server does not necessarily entail the larger task of adding EDNS support -- achieving consistence compliance with either the DNS standard before EDNS, or the DNS standard after EDNS, is the requirement. There are two ways for a DNS server to relay the DNS responses larger than 512 bytes.... 1. The server replies with a truncated message with the truncate bit set, and the client connects to you over TCP to make the DNS request, OR The client provided the EDNS option with a larger packet size, and you support that, so you send a large UDP reply instead. A DNS server must support the first of these methods (The second is preferable but optional, and support for the first method over TCP is mandatory) if you could ever be required to handle a DNS message whose reply is larger than 512 bytes: All recursive resolvers fall into this category, and with DNSSEC + IPv6, many common queries will result in an answer longer than the original 512 byte limit of UDP. -- -JH From mark.tinka at seacom.mu Thu Jan 31 17:08:06 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Jan 2019 19:08:06 +0200 Subject: Latency between Dallas and west coast In-Reply-To: <268707779.2369.1548953620041.JavaMail.mhammett@ThunderFuck> References: <268707779.2369.1548953620041.JavaMail.mhammett@ThunderFuck> Message-ID: On 31/Jan/19 18:53, Mike Hammett wrote: > It's 180 ms from Dallas to Djibouti, so no, that much latency to the > west coast of the US is not normal. Or from Gaborone to Frankfurt, which is some 184ms. Short of long re-route paths or congested, high packet loss links, I'd not expect the latency between any 2 points in the U.S. to hit 200ms. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Jan 31 17:36:56 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 31 Jan 2019 12:36:56 -0500 Subject: Latency between Dallas and west coast In-Reply-To: References: <268707779.2369.1548953620041.JavaMail.mhammett@ThunderFuck> Message-ID: NYC to LA is in the high 60ms range, so no, 200ms from Dallas to US west coast is not expected. On Thu, Jan 31, 2019 at 12:14 PM Mark Tinka wrote: > > > On 31/Jan/19 18:53, Mike Hammett wrote: > > It's 180 ms from Dallas to Djibouti, so no, that much latency to the west > coast of the US is not normal. > > > Or from Gaborone to Frankfurt, which is some 184ms. > > Short of long re-route paths or congested, high packet loss links, I'd not > expect the latency between any 2 points in the U.S. to hit 200ms. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncariaga at gmail.com Thu Jan 31 17:40:53 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Fri, 1 Feb 2019 01:40:53 +0800 Subject: Latency between Dallas and west coast In-Reply-To: References: <268707779.2369.1548953620041.JavaMail.mhammett@ThunderFuck> Message-ID: thank you all for the responses. i guess i would have to discuss this with our provider. On Fri, Feb 1, 2019, 1:39 AM Tom Beecher NYC to LA is in the high 60ms range, so no, 200ms from Dallas to US west > coast is not expected. > > > > > On Thu, Jan 31, 2019 at 12:14 PM Mark Tinka wrote: > >> >> >> On 31/Jan/19 18:53, Mike Hammett wrote: >> >> It's 180 ms from Dallas to Djibouti, so no, that much latency to the west >> coast of the US is not normal. >> >> >> Or from Gaborone to Frankfurt, which is some 184ms. >> >> Short of long re-route paths or congested, high packet loss links, I'd >> not expect the latency between any 2 points in the U.S. to hit 200ms. >> >> Mark. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu Jan 31 18:26:27 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 31 Jan 2019 18:26:27 +0000 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: Fletcher, I don’t think that’s true. I find no specs on fiber dB loss being a function of ambient temperature. I do find fiber optic application data sheets for extreme temperature applications of -500F and +500F (spacecraft). You’d think if temperature affected fiber transmission characteristics, they’d see it in space. What you likely were seeing was connector loss, owing either to improper installation, incorrect materials, or unheated regen enclosures. Insertion loss (IL) failures, for instance, in the cold are a direct result of cable termination component shrinkage. That’s why regen and patch enclosures need to be heated as well as cooled. All fiber termination components have stated temperature limits. As temperatures approach -40F, the thermoplastic components in a cable's breakout, jacketing, and fiber fanout sections shrink more than the optical glass. Ruggedized connectors help somewhat, but the rule is that you can’t let optical connectors and assemblies get really cold (or really hot). A typical spec for a single-mode OSP connector is: Operating -30C (-22F) to +60C (+140F) The range for the corresponding Single Mode fiber is: Operating -55C (-67F) to +70C (+158F) Storage -60C (-76F) to +70C (+158F) Installation -30C (-22F) to +50C (+122F) All professional outside plant engineers know these requirements. So if you’re seeing failures, somebody is breaking a rule. -mel On Jan 30, 2019, at 3:05 PM, Fletcher Kittredge > wrote: Cold changes the transmission characteristics of fiber. At one point we were renting some old dark fiber from the local telephone company in northern Maine. When it would get below -15%-degree F the dB would get bad enough that the link using that fiber would stop working. The telephone company was selling us dark fiber because regulation required them to. They refused to give us another fiber nor inspect/repair. They took the position they were required to sell us fiber, not working fiber. On Wed, Jan 30, 2019 at 11:41 AM Mark Tinka > wrote: For anyone running IP networks in the Midwest, are you having to do anything special to keep your networks up? For the data centres, is this cold front a chance to reduce air conditioning costs, or is it actually straining the infrastructure? I'm curious, from a +27-degree C summer's day here in Johannesburg. Mark. -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jan 31 18:56:05 2019 From: randy at psg.com (Randy Bush) Date: Thu, 31 Jan 2019 10:56:05 -0800 Subject: BGP Experiment In-Reply-To: References: <39754390-827e-1094-5486-447c5151ac47@netravnen.de> <47265889-3CDE-431E-8022-AA9DAC56599C@neko.id.au> <20190123190146.GA74032@mis10.towardex.com> <019301d4b3fc$6ec769c0$4c563d40$@netconsultings.com> <01a601d4b403$de7b2160$9b716420$@netconsultings.com> <00df01d4b945$b68aaad0$23a00070$@netconsultings.com> Message-ID: > I suspect simple bugs are found by vendor, complex bugs are not > economic to find. the running internet is complex and has a horrifying number of special cases compounded by kiddies being clever. no one, independent of resource requirements, could build a lab to the scale needed to test. and then there is ewd's famous quote about testing. randy From jbothe at me.com Thu Jan 31 19:00:33 2019 From: jbothe at me.com (JASON BOTHE) Date: Fri, 1 Feb 2019 06:00:33 +1100 Subject: Latency between Dallas and west coast In-Reply-To: References: <268707779.2369.1548953620041.JavaMail.mhammett@ThunderFuck> Message-ID: <109D9740-1E5C-4587-A35C-E32CBDBDFF2E@me.com> Hi Nathan My current rtd from DA6 to SV1 is 38ms and from DRT Houston to LA1 is 30ms Jason > On Feb 1, 2019, at 04:40, Nathanael Catangay Cariaga wrote: > > thank you all for the responses. i guess i would have to discuss this with our provider. > >> On Fri, Feb 1, 2019, 1:39 AM Tom Beecher > NYC to LA is in the high 60ms range, so no, 200ms from Dallas to US west coast is not expected. >> >> >> >> >>> On Thu, Jan 31, 2019 at 12:14 PM Mark Tinka wrote: >>> >>> >>> On 31/Jan/19 18:53, Mike Hammett wrote: >>> >>>> It's 180 ms from Dallas to Djibouti, so no, that much latency to the west coast of the US is not normal. >>> >>> Or from Gaborone to Frankfurt, which is some 184ms. >>> >>> Short of long re-route paths or congested, high packet loss links, I'd not expect the latency between any 2 points in the U.S. to hit 200ms. >>> >>> Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roel.parijs at gmail.com Thu Jan 31 19:28:11 2019 From: roel.parijs at gmail.com (Roel Parijs) Date: Thu, 31 Jan 2019 20:28:11 +0100 Subject: RTBH no_export Message-ID: Hello NANOG, To minimize the impact of DDoS, I have setup RTBH. For our own customers, we can set the RTBH community ourselves towards our transit suppliers and this works well. For our BGP customers the problem is more complex. Our BGP customers can send us the RTBH community, and we will drop the traffic at our borders. Since we're only running a small network, we don't have the capacity to deal with large attacks. If we would be able to forward (and maybe alter it) this RTBH community towards our upstream providers, the impact on our network would be limited. However, the RFC states that an announcement tagged with the blackhole community should get the no_advertise or no_export community. What is your opinion on this ? Thanks in advance Roel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Colin-lists at highspeedcrow.ca Thu Jan 31 19:43:11 2019 From: Colin-lists at highspeedcrow.ca (Colin Stanners (lists)) Date: Thu, 31 Jan 2019 13:43:11 -0600 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: <258aa01d4b99d$32c03b90$9840b2b0$@highspeedcrow.ca> Out here in Manitoba we use unheated/no-electricity OSP fiber patch panel pedestals in some locations, those work without issue down to the occasional -40. Note that that’s using all high-quality components. For Fletcher’s case, it’s also possible that: -there had been water intrusion in a splice case or cable on the way – but then that tends to cause complete failure, either on the first occasion or not long after, and not repeating temperature-dependent fade. -there’s a bad fusion splice on the way whose characteristics are affected by temperature. My first step in such a case would be to OTDR the line (renting an OTDR if we were a company that didn’t own one) to see approximately where the issue is and to get an idea what kind of issue it is – Fletcher, I guess that your company did not do so at that time? From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mel Beckman Sent: Thursday, January 31, 2019 12:26 PM To: Fletcher Kittredge Cc: North American Network Operators' Group Subject: Re: Effects of Cold Front on Internet Infrastructure - U.S. Midwest Fletcher, I don’t think that’s true. I find no specs on fiber dB loss being a function of ambient temperature. I do find fiber optic application data sheets for extreme temperature applications of -500F and +500F (spacecraft). You’d think if temperature affected fiber transmission characteristics, they’d see it in space. What you likely were seeing was connector loss, owing either to improper installation, incorrect materials, or unheated regen enclosures. Insertion loss (IL) failures, for instance, in the cold are a direct result of cable termination component shrinkage. That’s why regen and patch enclosures need to be heated as well as cooled. All fiber termination components have stated temperature limits. As temperatures approach -40F, the thermoplastic components in a cable's breakout, jacketing, and fiber fanout sections shrink more than the optical glass. Ruggedized connectors help somewhat, but the rule is that you can’t let optical connectors and assemblies get really cold (or really hot). A typical spec for a single-mode OSP connector is: Operating -30C (-22F) to +60C (+140F) The range for the corresponding Single Mode fiber is: Operating -55C (-67F) to +70C (+158F) Storage -60C (-76F) to +70C (+158F) Installation -30C (-22F) to +50C (+122F) All professional outside plant engineers know these requirements. So if you’re seeing failures, somebody is breaking a rule. -mel On Jan 30, 2019, at 3:05 PM, Fletcher Kittredge > wrote: Cold changes the transmission characteristics of fiber. At one point we were renting some old dark fiber from the local telephone company in northern Maine. When it would get below -15%-degree F the dB would get bad enough that the link using that fiber would stop working. The telephone company was selling us dark fiber because regulation required them to. They refused to give us another fiber nor inspect/repair. They took the position they were required to sell us fiber, not working fiber. On Wed, Jan 30, 2019 at 11:41 AM Mark Tinka > wrote: For anyone running IP networks in the Midwest, are you having to do anything special to keep your networks up? For the data centres, is this cold front a chance to reduce air conditioning costs, or is it actually straining the infrastructure? I'm curious, from a +27-degree C summer's day here in Johannesburg. Mark. -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at bromirski.net Thu Jan 31 20:17:18 2019 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Thu, 31 Jan 2019 21:17:18 +0100 Subject: RTBH no_export In-Reply-To: References: Message-ID: <44E1FDF2-471E-4DCD-B5D3-B4FD289E3789@bromirski.net> > On 31 Jan 2019, at 20:28, Roel Parijs wrote: > > Hello NANOG, > > To minimize the impact of DDoS, I have setup RTBH. > For our own customers, we can set the RTBH community ourselves towards our transit suppliers and this works well. > > For our BGP customers the problem is more complex. Our BGP customers can send us the RTBH community, and we will drop the traffic at our borders. Since we're only running a small network, we don't have the capacity to deal with large attacks. If we would be able to forward (and maybe alter it) this RTBH community towards our upstream providers, the impact on our network would be limited. However, the RFC states that an announcement tagged with the blackhole community should get the no_advertise or no_export community. > > What is your opinion on this ? Community agreed between you and your peer is one thing, the other is community agreed with your upstreams. If in addition you own the customer IP space, it’s even less of a problem. And… if you upstreams agree to signal RTBH with you, it’s added bonus for them - they’re stopping the flood at their own edges thanks to you. win-win-win-drop ;) — ./ From nick at foobar.org Thu Jan 31 20:17:24 2019 From: nick at foobar.org (Nick Hilliard) Date: Thu, 31 Jan 2019 20:17:24 +0000 Subject: RTBH no_export In-Reply-To: References: Message-ID: <4d5a6847-1b08-ac79-9600-a04aa7856cc5@foobar.org> Roel Parijs wrote on 31/01/2019 19:28: > What is your opinion on this ? you should implement a different community for upstream blackholing. This should be stripped at your upstream links and replaced with the provider's RTBH community. Your provider will then handle export restrictions as they see fit. Nick From theodore at ciscodude.net Thu Jan 31 20:21:20 2019 From: theodore at ciscodude.net (Theodore Baschak) Date: Thu, 31 Jan 2019 14:21:20 -0600 Subject: RTBH no_export In-Reply-To: References: Message-ID: <39954B9C-6DA6-427F-8CBB-7CD6408FD6D3@ciscodude.net> > On Jan 31, 2019, at 1:28 PM, Roel Parijs wrote: > > For our BGP customers the problem is more complex. Our BGP customers can send us the RTBH community, and we will drop the traffic at our borders. Since we're only running a small network, we don't have the capacity to deal with large attacks. If we would be able to forward (and maybe alter it) this RTBH community towards our upstream providers, the impact on our network would be limited. However, the RFC states that an announcement tagged with the blackhole community should get the no_advertise or no_export community. > > What is your opinion on this ? > In RFC7999 section 3.2 the first paragraph talks about what you're mentioning, NO_EXPORT and/or NO_ADVERTISE. It uses the word SHOULD. SHOULD has special meaning in RFCs, its not MUST. Its also not MAY. RFC2119 talks about the way these words should be interpreted. In the next paragraph it says that extreme caution should be used when "purposefully propagating IP prefixes tagged with the BLACKHOLE community outside the local routing domain, unless policy explicitly aims at doing just that." So if your local routing policy is to propagate those blackholes on to your upstreams (and its mutually agreed and they're configured to accept them), then it can be done. Nothing technical in the RFC stopping that. Theo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Thu Jan 31 20:29:26 2019 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 31 Jan 2019 12:29:26 -0800 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> Message-ID: <85a311c7814801da22b9388ed240653b@dougbarton.us> On 2019-01-31 08:32, James Stahr wrote: > I think the advertised testing tool may be flawed as blocking TCP/53 > is enough to receive a STOP from the dnsflagday web site. It's been > my (possibly flawed) understanding that TCP/53 is an option for > clients but primarily it is a mechanism for the *server* to request > the client communicate using TCP/53 instead - this could be due to UDP > response size, anti-spoofing controls, etc... That understanding is flawed, but understandable given how deeply ingrained this misinformation has become in the zeitgeist. Sections 4.2 and 4.2.2 of 1035 clearly state that TCP is an expected channel, not optional. This is relevant operationally for two reasons. First while most folks make an effort to keep answers under 512 bytes for response time reasons, you cannot guarantee that someone, somewhere in your org won't add a record that overflows. Also, you are guaranteed to overflow at some point once you roll out DNSSEC. I've even seen seemingly mundane things like SRV records overflow 512 bytes. The other reason it's relevant operationally is that there are more and more experimental projects in development now that involve using TCP, even without the need for truncation, as a way to have more assurance that a response is not spoofed. There are also efforts under way to evaluate whether "pipelining" DNS requests to servers that you are already sending a lot of requests to is ultimately more efficient than UDP at high volumes. So, like lack of EDNS compliance, lack of TCP "compliance" here is going to be a limiting factor for the growth of new features, at minimum; and could result in actual breakage. hope this helps, Doug From michel.py at tsisemi.com Thu Jan 31 20:33:59 2019 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 31 Jan 2019 20:33:59 +0000 Subject: RTBH no_export In-Reply-To: References: Message-ID: <9bdb4d3fa92b41c5ba0024b39c5d1695@CRA114.am.necel.com> > Roel Parijs wrote: > To minimize the impact of DDoS, I have setup RTBH. For our own customers, we can set the RTBH community ourselves towards our transit suppliers and > this works well. For our BGP customers the problem is more complex. Our BGP customers can send us the RTBH community, and we will drop the traffic > at our borders. Since we're only running a small network, we don't have the capacity to deal with large attacks. If we would be able to forward (and maybe > alter it) this RTBH community towards our upstream providers, the impact on our network would be limited. However, the RFC states that an announcement > tagged with the blackhole community should get the no_advertise or no_export community. I think the RFC is flexible enough; it's more about what you have agreed with your upstream(s) in terms of what they will accept as blackholes routes. Many upstreams will accept a destination-based blackhole if the prefix belongs to you, but accepting blackholes for other prefixes or accepting source-based blackholes requires a lot of trust. It's more a political issue than a technical one, as I see it. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From marka at isc.org Thu Jan 31 21:10:55 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 08:10:55 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> Message-ID: > On 1 Feb 2019, at 3:32 am, James Stahr wrote: > > On 2019-01-31 08:15, Mark Andrews wrote: > >> We actually have a hard time finding zones where all the servers are >> broken enough to not work with servers that don’t fallback to plain >> DNS on timeout. We can find zones where some of the servers are like >> that, but there is usually one or more servers that do respond >> correctly. >> Of the datasets I’ve looked at that 1 in 10,000 to 1 in 100,000 zones >> will have problems with updated servers. > > I think the advertised testing tool may be flawed as blocking TCP/53 is enough to receive a STOP from the dnsflagday web site. It's been my (possibly flawed) understanding that TCP/53 is an option for clients but primarily it is a mechanism for the *server* to request the client communicate using TCP/53 instead - this could be due to UDP response size, anti-spoofing controls, etc… DNS is defined to be both TCP and UDP. Blocking TCP has no real security benefit and comes from the MYTH that TCP is ONLY used for zone transfers. Way too many times people have blocked TCP then have those same servers return TC=1 which say USE TCP as the answer is TOO LARGE TO FIT IN UDP. Foot, Gun, Shoot. If you have a DNSSEC zone then TCP is effectively MANDATORY as clients still need to be able to get answers from behind a firewall that is enforcing a 512 byte limit. If you are running a recursive server TCP is effectively MANDATORY as you have no control over the RRset size. Lots of referrals REQUIRE TCP as the GLUE records are not OPTIONAL in a referral. Yes, BIND has been setting TC=1 on referrals for MANY years now when it is required, it should be setting it on many more. So if you want WORKING DNS you do not block TCP. Other DNS vendors also set TC=1 on some referrals. This means if you are hosting third party content then TCP is effectively MANDATORY as you have no content control. RFC 1123 said that DNS/TCP is a SHOULD where SHOULD is defined as * "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. I’ve yet to see anyone who has TCP blocked actually know all the places in the DNS protocol where doing so will cause things to break. None of them have done the necessary homework to actually exercise the SHOULD. There are lots of lemmings when it comes to DNS practices. All implementations of DNS are REQUIRED to support DNS/TCP. The DNS flag day site flags servers without TCP as broken which they *are*. Whether it should be red or orange is a matter for debate. A referral that in bigger than 512 bytes without involving DNSSEC. [beetle:~/git/bind9] marka% dig example.net @a.root-servers.net ; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> example.net @a.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54567 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;example.net. IN A ;; AUTHORITY SECTION: net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 m.gtld-servers.net. 172800 IN A 192.55.83.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30 ;; Query time: 375 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Fri Feb 01 07:54:44 AEDT 2019 ;; MSG SIZE rcvd: 833 [beetle:~/git/bind9] marka% > So is the tool right in saying that TCP/53 is a absolute requirement of ENDS0 support for "DNS Flag Day"? If so, do we expect a dramatic increases in TCP/53 requests over UDP/53 queries? Or is the tool flawed in its' claim that the DNS Flag Day changes *require* TCP/53 in order to resolve ones domain? Based upon my reading, the big concern is a edns=timeout result (from the ISC tool) not a edns512tcp=timeout. > > > While I applaud the effort, the message and delivery could have been better. My first read on DNS Flag Day was that this was going to be the day new software versions were to be released which deprecated EDNS0 fallback measures so the adoption would be a gradual process by updating the latest versions of several DNS servers, only to find out that many resolvers used by end users use will be upgrading on Feb 1rst. Now, it sounds like the rollout schedule is on their timetable and could happen over the next several weeks and months. So really not a Flag "Day" now is it? I guess that's also why the date being on a Friday also isn't really a concern... > > Finally, why has no one stepped up to setup an updated resolver prior to Feb 1rst for actual testing? Or are there instructions on how one could setup their own resolver setup prior to Feb 1rst? No offense, but I'm not jumping to a brand new train of code just to enforce DNS Flag Day but I might choose enforce now under *existing* code bases rather than waiting for everyone else using Cloudflare/Google/OpenDNS as resolver may see me after Feb 1rst? If anyone has such instructions, post them - or put them on dnsflagday.net for anyone else wanting to adopt/test. Just some thoughts… From the DNS flag day site: DNS resolver operators On or around Feb 1st, 2019, major open source resolver vendors will release updates that will stop accommodating non-standard responses. This change will affect authoritative servers which do not comply either with the original DNS standard from 1987 (RFC1035) or the newer EDNS standards from 1999 (RFC2671 and RFC6891). Major public DNS resolver operators listed below are also removing accommodations so this change will also impact Internet users and providers who use these public DNS services. Sites hosted on incompatible authoritative servers may become unreachable through updated resolvers. The web form above diagnostic tool may be helpful while investigating problems with a particular domain. Domains which repeatedly fail the test above have problems with either their DNS software or their firewall configuration and cannot be fixed by DNS resolver operators. The following versions of DNS resolvers will not accommodate EDNS non-compliant responses: • BIND 9.13.3 (development) and 9.14.0 (production) • Knot Resolver has already implemented stricter EDNS handling in all current versions • PowerDNS Recursor 4.2.0 • Unbound 1.9.0 Now BIND 9.13.3 became public on 2018-09-19 and the Knot Resolver are already public. You can lookup PowerDNS and Unbound to see if they are public. > -- > -James -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jan 31 21:19:12 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 08:19:12 +1100 Subject: DNS Flag Day, Friday, Feb 1st, 2019 In-Reply-To: <2e963381-9963-925c-7fb2-4961b22753df@seacom.mu> References: <20190124001038.GH98649@meow.BKantor.net> <1548898858.1800.1.camel@domainmail.org> <8343ABDC-0960-4713-9745-7F044727EFDE@isc.org> <415344f6-2b68-4196-862e-b4ef911e208a@www.fastmail.com> <91AA52B4-0068-452A-8370-EA605F2900AB@isc.org> <2e963381-9963-925c-7fb2-4961b22753df@seacom.mu> Message-ID: <9E46C8B6-41A4-4DB7-830C-499AEFF0B734@isc.org> TIMEOUT is TIMEOUT. The whole point of flag day is that you can’t tell whether TIMEOUT is broken routing, packet loss or badly configured firewall. The DNS flag day site assumes the latter as does the old resolver code. We are moving to a state where resolvers assume the former. You get a report with Red or Orange. Red reports have things which need to be fixed NOW be it a routing issue or packet loss or a badly configured firewall. Mark > On 1 Feb 2019, at 4:04 am, Mark Tinka wrote: > > > > On 31/Jan/19 18:32, James Stahr wrote: > >> >> I think the advertised testing tool may be flawed as blocking TCP/53 >> is enough to receive a STOP from the dnsflagday web site. It's been >> my (possibly flawed) understanding that TCP/53 is an option for >> clients but primarily it is a mechanism for the *server* to request >> the client communicate using TCP/53 instead - this could be due to UDP >> response size, anti-spoofing controls, etc... > > On a similar note, we tested for all our self-hosted zones OK 2 weeks > ago. However, in previous days, the summary result said "NO GOOD, THINGS > WILL BE SLOW COME FLAG DAY". The detailed test showed IPv4 tested > perfect, but IPv6 probes timed out. > > The issue turned out to be an internal IPv6 routing/forwarding issue for > our service within Century Link's (Level(3)'s) network. CL finally fixed > that issue today and the flag day test tool is happy again. > > Some of our partners/customers were concerned our name servers were not > ready, based purely on the summary result of the test tool. Perhaps > adding some intelligence about whether the issue is the name server or > the transport may be helpful. > > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Jan 31 22:29:32 2019 From: marka at isc.org (Mark Andrews) Date: Fri, 1 Feb 2019 09:29:32 +1100 Subject: Google you have a problem. Message-ID: <70277A54-8FC6-4CF5-896D-C281ABB59260@isc.org> [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi looking up www.google.com connecting to www.google.com:443 SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet Authority G3 requesting https://www.google.com/jsapi fetch: https://www.google.com/jsapi: Bad Gateway [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi * Trying 2607:f8b0:4007:80e::2004... * TCP_NODELAY set * Trying 172.217.14.100... * TCP_NODELAY set * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Jan 15 13:15:00 2019 GMT * expire date: Apr 9 13:15:00 2019 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. > GET /jsapi HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.63.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Content-Length: 0 < Date: Thu, 31 Jan 2019 22:20:34 GMT < Content-Type: text/html; charset=UTF-8 < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" < * Connection #0 to host www.google.com left intact [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi * Trying 172.217.14.100... * TCP_NODELAY set * Connected to www.google.com (172.217.14.100) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Jan 15 13:15:00 2019 GMT * expire date: Apr 9 13:15:00 2019 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. > GET /jsapi HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.63.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Content-Length: 0 < Date: Thu, 31 Jan 2019 22:24:43 GMT < Content-Type: text/html; charset=UTF-8 < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" < * Connection #0 to host www.google.com left intact [beetle:~/git/bind9] marka% traceroute 172.217.14.100 traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte packets 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms 2 * * * 3 * * * 4 59.154.18.232 (59.154.18.232) 13.710 ms hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 ms 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms 108.170.247.59 (108.170.247.59) 14.167 ms 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms 74.125.252.75 (74.125.252.75) 149.363 ms 11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms 149.593 ms [beetle:~/git/bind9] marka% -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fkittred at gwi.net Thu Jan 31 20:21:58 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Thu, 31 Jan 2019 15:21:58 -0500 Subject: Effects of Cold Front on Internet Infrastructure - U.S. Midwest In-Reply-To: References: <7c223f18-01d8-8e86-b417-c69ddcb4159f@seacom.mu> Message-ID: Mel; You are absolutely right. I should have been more specific in my description of the problem. On Thu, Jan 31, 2019 at 1:27 PM Mel Beckman wrote: > Fletcher, > > I don’t think that’s true. I find no specs on fiber dB loss being a > function of ambient temperature. I do find fiber optic application data > sheets for extreme temperature applications of -500F and +500F > (spacecraft). You’d think if temperature affected fiber transmission > characteristics, they’d see it in space. > > What you likely were seeing was connector loss, owing either to improper > installation, incorrect materials, or unheated regen enclosures. > > Insertion loss (IL) failures, for instance, in the cold are a direct > result of cable termination component shrinkage. That’s why regen and patch > enclosures need to be heated as well as cooled. > > All fiber termination components have stated temperature limits. As > temperatures approach -40F, the thermoplastic components in a > cable's breakout, jacketing, and fiber fanout sections shrink more than the > optical glass. Ruggedized connectors help somewhat, but the rule is that > you can’t let optical connectors and assemblies get really cold (or really > hot). > > A typical spec for a single-mode OSP connector is: > > Operating -30C (-22F) to +60C (+140F) > > The range for the corresponding Single Mode fiber is: > > Operating -55C (-67F) to +70C (+158F) > Storage -60C (-76F) to +70C (+158F) > Installation -30C (-22F) to +50C (+122F) > > All professional outside plant engineers know these requirements. So if > you’re seeing failures, somebody is breaking a rule. > > -mel > > > On Jan 30, 2019, at 3:05 PM, Fletcher Kittredge wrote: > > > Cold changes the transmission characteristics of fiber. At one point we > were renting some old dark fiber from the local telephone company in > northern Maine. When it would get below -15%-degree F the dB would get bad > enough that the link using that fiber would stop working. The telephone > company was selling us dark fiber because regulation required them to. They > refused to give us another fiber nor inspect/repair. They took the position > they were required to sell us fiber, not working fiber. > > > On Wed, Jan 30, 2019 at 11:41 AM Mark Tinka wrote: > >> For anyone running IP networks in the Midwest, are you having to do >> anything special to keep your networks up? >> >> For the data centres, is this cold front a chance to reduce air >> conditioning costs, or is it actually straining the infrastructure? >> >> I'm curious, from a +27-degree C summer's day here in Johannesburg. >> >> Mark. >> > > > -- > Fletcher Kittredge > GWI > 207-602-1134 > www.gwi.net > > > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rob.Wcislo at gtt.net Thu Jan 31 23:27:01 2019 From: Rob.Wcislo at gtt.net (Rob Wcislo) Date: Thu, 31 Jan 2019 23:27:01 +0000 Subject: Waves between Buffalo and Manhattan Message-ID: <12E5EB73CE4D43DF.4083313D-80F9-4DFD-9A52-E2B0C73AEDB8@mail.outlook.com> GTT has this route via legacy Hibernia [Image] Rob Wcislo VP, Sales GTT (954)305-2289 On Thu, Jan 31, 2019 at 11:00 AM -0500, wrote: GTT can sell waves between Buffalo-NYC bypassing Albany via Newark. From: NANOG On Behalf Of Tom Beecher Sent: Friday, January 18, 2019 3:58 PM To: NANOG Mailing List Subject: Re: Waves between Buffalo and Manhattan If it's for the use case I suspect it would be for, Firstlight and Windstream should bring you closer to where you'll want to be on the Buffalo side. On Fri, Jan 18, 2019 at 1:38 PM Benjamin Hatton > wrote: The regional players in the area that may have something that would bypass Albany would be Firstlight (Formerly Finger Lakes Technology Group) and Uniti. Firstlight has more fiber in the area, and would be my choice over Uniti, I have services with both. Contact me off list if you want an introduction to a sales guy. On Fri, Jan 18, 2019 at 1:00 PM Mehmet Akcin > wrote: hi Jason https://dev.networkatlas.org shows Zayo, Windstream (and Earthlink) there. We are working with Charter , Level3/CL to load their fiber routes , but it will be there and you will be able to connect with the sales teams directly by clicking on a route. . In addition to that there are other small players in this region. Mehmet On Fri, Jan 18, 2019 at 9:49 AM Jason Lixfeld > wrote: Hello, Does anyone have knowledge of carriers who are able to deliver 10G or 100G waves between Buffalo and Manhattan that *do not* touch Albany? I know Zayo is one. I’m waiting to hear back from CenturyLink. I’ve reviewed networkatlas.org, to see if anything pops up there, but otherwise I’m coming up empty. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: