From Ryan.Hamel at quadranet.com Mon Oct 1 03:27:49 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Mon, 1 Oct 2018 03:27:49 +0000 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> Just like how all the email threads on NANOG are archived, all talks should be archived as well. Ryan Hamel From: NANOG On Behalf Of Krassimir Tzvetanov Sent: Sunday, September 30, 2018 3:31 PM To: Sam Oduor Cc: NANOG mailing list Subject: Re: NANOG Security Track: Route Security Sam, To ensure unimpeded information sharing and discussion, the Security Track will not be broadcast or recorded. I apologise for the inconvenience. Regards, Krassimir On Sun, Sep 30, 2018, 1:05 PM Sam Oduor > wrote: Hi Any online link available for remote participation or viewing ? On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov > wrote: Hello Everyone, I wanted to attract your attention to the Security Track this coming NANOG. We'll be meeting on Tuesday morning and the line up looks like this: * Andre Toonk - examples of hijacks, other ideas * Alexander Azimov - State of BGP Security * David Wishnick - ARIN TAL * Job Snijders - Routing security roadmap * Chris Morrow - So I need to start filtering routes from peers...' and 'hey guess who needs to update their IRR data?' Time permitting at the end of the time slot we'll have a panel and time for duscussion as well. Regards, Krassi -- Samson Oduor -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Mon Oct 1 03:41:20 2018 From: Brian at ampr.org (Brian Kantor) Date: Sun, 30 Sep 2018 20:41:20 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> References: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> Message-ID: <20181001034120.GA20069@meow.BKantor.net> > To ensure unimpeded information sharing and discussion, the > Security Track will not be broadcast or recorded. I fail to understand how making the presentations secret from all except those attending in person promotes information sharing. Could whoever made this seemingly contradictory decision explain the reasoning behind it? - Brian From jbothe at me.com Mon Oct 1 04:38:40 2018 From: jbothe at me.com (JASON BOTHE) Date: Sun, 30 Sep 2018 23:38:40 -0500 Subject: NANOG Security Track: Route Security In-Reply-To: <20181001034120.GA20069@meow.BKantor.net> References: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> <20181001034120.GA20069@meow.BKantor.net> Message-ID: Agreed, especially if they’re an active member of the organization and doesn’t seem to be synonymous with NANOGs Charter. Jason On Sep 30, 2018, at 22:41, Brian Kantor wrote: >> To ensure unimpeded information sharing and discussion, the >> Security Track will not be broadcast or recorded. > > I fail to understand how making the presentations secret from all > except those attending in person promotes information sharing. > Could whoever made this seemingly contradictory decision explain > the reasoning behind it? > - Brian > From job at ntt.net Mon Oct 1 04:51:07 2018 From: job at ntt.net (Job Snijders) Date: Sun, 30 Sep 2018 21:51:07 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: References: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> <20181001034120.GA20069@meow.BKantor.net> Message-ID: Hi all, Speaking as presenter in this track, I’d be fine with video recording and online distribution. In fact, I’d encourage it, I don’t assume any secrecy or confidentiality in this meeting. Perhaps for the NANOG74 meeting it is too late to organize video recording, but going forward I’m a proponent of recording everything. It creates more value for both the presenters and the global community. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Oct 1 07:17:25 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Oct 2018 03:17:25 -0400 Subject: NANOG Security Track: Route Security In-Reply-To: References: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> <20181001034120.GA20069@meow.BKantor.net> Message-ID: we could post our slides though, right? (I mean, per presenter, if that's your choice?) On Mon, Oct 1, 2018 at 12:52 AM Job Snijders wrote: > Hi all, > > Speaking as presenter in this track, I’d be fine with video recording and > online distribution. In fact, I’d encourage it, I don’t assume any secrecy > or confidentiality in this meeting. > > Perhaps for the NANOG74 meeting it is too late to organize video > recording, but going forward I’m a proponent of recording everything. It > creates more value for both the presenters and the global community. > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at nlnetlabs.nl Mon Oct 1 07:47:43 2018 From: alex at nlnetlabs.nl (Alex Band) Date: Mon, 1 Oct 2018 09:47:43 +0200 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> Message-ID: <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> Hello, To avoid any misunderstanding in this discussion going forward, I would like to reiterate that an RPKI ROA is a positive attestation. An unavailable, expired or invalid ROA will result in a BGP announcement with the status NotFound. The announcement will *not* become INVALID, thereby being dropped. Please read Section 5 of RFC 7115 that John linked carefully: Bush Best Current Practice [Page 7] RFC 7115 RPKI-Based Origin Validation Op January 2014 Announcements with NotFound origins should be preferred over those with Invalid origins. Announcements with Invalid origins SHOULD NOT be used, but may be used to meet special operational needs. In such circumstances, the announcement should have a lower preference than that given to Valid or NotFound. Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing. It is important to be aware of the impact of such an outage when considering questions of liability. Kind regards, Alex Band NLnet Labs > On 1 Oct 2018, at 01:21, John Curran wrote: > > Folks - > > Perhaps it would be helpful to confirm that we have common goals in the network operator community regarding RPKI, and then work from those goals on the necessary plans to achieve them. > > It appears that many network operators would like to improve the integrity of their network routing via RPKI deployment. The Regional Internet Registries (RIRs) have all worked to support RPKI services, and while there are different opinions among operators regarding the cost/benefit tradeoffs of RPKI Route Origin Validation (ROV), it is clear that we have to collectively work together now if we are ever to have overall RPKI deployment sufficient to create the network effects that will ensure compelling long-term value for its deployment. > > Let’s presume that we’ve achieved that very outcome at some point in future; i.e. we’re have an Internet where nearly all network operators are publishing Route Origin Authorizations (ROAs) via RIR RPKI services and are using RPKI data for route validation. It is reasonable to presume that over the next decade the Internet will become even more pervasive in everyday life, including being essential for many connected devices to function, and relied upon for everything from daily personal communication and conducting business to even more innovative uses such as payment & sale systems, delivery of medical care, etc. > > Recognizing that purpose of RPKI is improve integrity of routing, and not add undo fragility to the network, it is reasonable to expect that many network operators will take due care with the introduction of route validation into their network routing, including best practices such as falling back successfully in the event of unavailability of an RIR RPKI Certificate Authority (CA) and resulting cache timeouts. It is also reasonable expect that RIR RPKI CA services are provisioned with appropriate robustness of systems and controls that befit the highly network-critical nature of these services. > > Presuming we all share this common goal, the question that arises is whether we have a common vision regarding what should happen when something goes wrong in this wonderful RPKI-rich Internet of the future… More than anyone, network operators realize that even with excellent systems, procedures, and redundancy, outages can (and do) still occur. Hopefully, these are quite rare, and limited to occasions where Murphy’s Law has somehow resulted in nearly unimaginable patterns of coincident failures, but it would irresponsible to not consider the “what if” scenarios for RPKI failure and whether there is shared vision of the resulting consequences. > > In particular, it would be good to consider the case of an RIR RPKI CA system failure, one sufficient to result in widespread cache expirations for relying parties. Ideally, we will never have to see this scenario when RPKI is widely deployed, but it also not completely inconceivable that an RIR RPKI CA experience such an outage [1]. For network operators following reasonable deployment practices, an RIR RPKI CA outage should result in a fallback to unvalidated network routing data and no significant network impacts. However, it’s likely not a reasonable assumption that all network operators will have properly designed and implemented best practices in this regard, so there will very likely be some networks that experience significant impacts consequential to any RIR RPKI CA outage. Even if this is only 1 or 2 percent of network operators with such configuration issues, it will mean hundreds of ISP outages occurring simultaneously throughout the Internet and millions of customers (individuals and businesses) effected globally. While the Internet is the world’s largest cooperative endeavor, there inevitably will be many folks impacted of a RIR RPKI outage, including some asking (appropriately) the question of “who should bear responsibility” for the harm that they suffered. > > It is worth understanding what the network community believes is the most appropriate answer to this question, since a common outlook on this question can be used to guide implementation details to match. Additionally, a common understanding on this question will provide real insight into how the network community intends risk of the system to be distributed among the participants. > > There are several possible options worth considering: > > A) The most obvious answer for the party that should be held liable for the impacts that result from an RPKI CA failure would be the respective RIR that experienced the outage. This seems rather straightforward until one considers that the RIRs are providing these services specifically noting that they may not be (despite all precautions) available 100% percent of the time, and clearly documented expectations that those relying on RPKI CA information for routing origin validation should be fallback to routing with not validated state [2]. The impacted parties are those customers of ISPs that improperly handled the unavailability of RPKI data; thus escalating situation into a network-affecting outage. Under these circumstances, directing the claims from customers of all the improperly-configured ISP’s to the RIR completely ignores the responsibility of these ISPs to prepare for this precise eventuality, as was done by the fellow network operators. > > B) One of the more interesting theories on who should be held liable is that those who are publishing ROA’s are the appropriate responsible parties in the event of RPKI CA failure; one can achieve such a position on the logic that they consciously decided to use RPKA CA services and thus asserted globally that they would henceforth have validated routes – an RPKI CA failure is a case of their “vendor" (the RIR) letting them down on the publication. This also has equity issues, since those publishing ROA information don’t have a clear contributory role, and the damages accruing to them are coming from customers from those operators who failed their duty. > > C) Another potential answer for the party that should be responsible is that each of the ISPs that failed to appropriately configure their route validation and thus experience a network outage should be responsible for their own customers impacted as a result. In addition to keeping the liability proportional to the customers served, this encourages each such ISP to consider appropriate corrective measures. > > It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > [1] https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html > [2] https://www.rfc-editor.org/rfc/rfc7115.txt > > From mark.tinka at seacom.mu Mon Oct 1 08:18:38 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 1 Oct 2018 10:18:38 +0200 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> Message-ID: <3ef28c04-64a0-b141-10d6-73a8324bb6cf@seacom.mu> On 1/Oct/18 09:47, Alex Band wrote: > > Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing. Indeed, and this is on the basis that operators are not overzealous about aggressively acting against a "NotFound" RPKI state. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Oct 1 08:20:26 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 1 Oct 2018 10:20:26 +0200 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> Message-ID: <1ba8e559-13d9-1d73-5a50-82d1b85da2d4@seacom.mu> On 1/Oct/18 01:21, John Curran wrote: >   >   > > It is possible to architect the various legalities surrounding RPKI to > support any of the above outcomes, but it first requires a shared > understanding of what the network community believes is the correct > outcome.   There is likely some on the nanog mailing list who have a > view on this matter, so I pose the question of "who should be > responsible" for consequences of RPKI RIR CA failure to this list for > further discussion. John, in the instance where all RIR's transition to a single "All Resource" TA, what would, in your mind, be the (potential) liability considerations? Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Oct 1 08:26:08 2018 From: jcurran at arin.net (John Curran) Date: Mon, 1 Oct 2018 08:26:08 +0000 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> Message-ID: <000253A6-5470-49B6-B506-321714E2BF25@arin.net> On 1 Oct 2018, at 12:47 AM, Alex Band wrote: > > Hello, > > To avoid any misunderstanding in this discussion going forward, I would like to reiterate that an RPKI ROA is a positive attestation. An unavailable, expired or invalid ROA will result in a BGP announcement with the status NotFound. The announcement will *not* become INVALID, thereby being dropped. > > Please read Section 5 of RFC 7115 that John linked carefully: > ... > > Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing. Alex - Yes – ISPs who have configured RPKI route validation and are using it to preference routes should continue to utilize routes that are have NotFound status due to lack of RPKI repository data. As RFC 7115 notes - " Hence, an operator's policy should not be overly strict and should prefer Valid announcements; it should attach a lower preference to, but still use, NotFound announcements, and drop or give a very low preference to Invalid announcements. " Of course, this presumes correct routing configuration by the ISP when setting up RPKI route validation; while one would hope that the vast majority handle this situation correctly, there is no assurance that will be true without exception. If RPKI routing validation is widely deployed, tens of thousands of ISPs will be setting up such a configuration, with customer impact during an RPKI CA outage occurring for those who somehow failure to fall back to using NotFound routes. If only a small percentage get this wrong, it will still represent dozens of ISPs going dark as a result. > It is important to be aware of the impact of such an outage when considering questions of liability. Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR? Thanks! /John John Curran President and CEO ARIN From cjeker at diehard.n-r-g.com Mon Oct 1 08:30:31 2018 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Mon, 1 Oct 2018 10:30:31 +0200 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> Message-ID: <20181001083031.GA15078@diehard.n-r-g.com> On Mon, Oct 01, 2018 at 09:47:43AM +0200, Alex Band wrote: > Hello, > > To avoid any misunderstanding in this discussion going forward, I would > like to reiterate that an RPKI ROA is a positive attestation. An > unavailable, expired or invalid ROA will result in a BGP announcement > with the status NotFound. The announcement will *not* become INVALID, > thereby being dropped. > > Please read Section 5 of RFC 7115 that John linked carefully: > > Bush Best Current Practice [Page 7] > > RFC 7115 RPKI-Based Origin Validation Op January 2014 > > > Announcements with NotFound origins should be preferred over those > with Invalid origins. > > Announcements with Invalid origins SHOULD NOT be used, but may be > used to meet special operational needs. In such circumstances, the > announcement should have a lower preference than that given to Valid > or NotFound. > > Thus, a continued outage of an RPKI CA (or publication server) will > result in announcements with status NotFound. This means that the > prefixes held by this CA will no longer benefit from protection by the > RPKI. However, since only *invalid* announcements should be dropped, > this should not lead to large scale outages in routing. > > It is important to be aware of the impact of such an outage when > considering questions of liability. This depends if the prefix in question is covered by another ROA. Because in that case it is well possible that the prefix is marked INVALID. This is especially an issue if a partial failure of a publication server is taking out the more specifics but leaves a large covering ROA (maybe even one with origin AS 0). In the end from a security standpoint it is probably better to fail closed because the alternative is no RPKI and then hijacks become possible and MITM attacks or DNS spoofing can be done leaving every Internet user at risk. Also consider that not using best common practice to protect a service is also putting you at risk for liability charges. So ignoring RPKI because of possible liability concerns may as fire back at you. -- :wq Claudio From mark.tinka at seacom.mu Mon Oct 1 08:36:34 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 1 Oct 2018 10:36:34 +0200 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <000253A6-5470-49B6-B506-321714E2BF25@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> <000253A6-5470-49B6-B506-321714E2BF25@arin.net> Message-ID: On 1/Oct/18 10:26, John Curran wrote: > > Of course, this presumes correct routing configuration by the ISP when setting up RPKI route validation; while one would hope that the vast majority handle this situation correctly, there is no assurance that will be true without exception. If RPKI routing validation is widely deployed, tens of thousands of ISPs will be setting up such a configuration, with customer impact during an RPKI CA outage occurring for those who somehow failure to fall back to using NotFound routes. If only a small percentage get this wrong, it will still represent dozens of ISPs going dark as a result. It is equally important to understand how vendors have interpreted the RFC for default treatment of RPKI data. When we started testing IOS and IOS XE back in 2014/2015, we hit an issue where Cisco were automatically applying policy to RPKI state without configuration from the operator. This was fixed in later code, but goes to show that one should not assume that vendors are always doing the right thing, or at the very least, fully understand what their view on RPKI might be on the wider Internet, in real production. So before deploying network-wide, I encourage operators to test what their equipment will do when RPKI is enabled but without any manual policy applied. > Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR? Any equipment misconfigurations should be the responsibility of the operator. Responsibility for ROA's should lie with the resource holder, in ensuring that not only is the information true, but that also all announced prefixes are covered by a ROA. An RIR CA outage would, in my mind, be the responsibility of the RIR. But this comes back to my question of how this handled with an "all resource" TA. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl_gerh at gmx.at Mon Oct 1 08:55:33 2018 From: karl_gerh at gmx.at (Karl Gerhard) Date: Mon, 1 Oct 2018 10:55:33 +0200 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: Hello, I just wanted to mention that NANOG is being read all over the world - as far as I know this is the biggest english speaking "NOG" mailing list... in the world. Most of the readers here will never attend a NANOG meeting and a big part of those won't attend because they live on other parts of the planet. The topics seem very interesting and highly relevant for networks everywhere and I find it very unfortunate that there will be no recording. Best Regards from Europe Karl ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Krassimir Tzvetanov [mailto:maillists at krassi.biz] *Sent:* Mon, Oct 1, 2018 12:30 AM CEST *To:* Sam Oduor *Cc:* NANOG mailing list *Subject:* NANOG Security Track: Route Security > Sam, > > To ensure unimpeded information sharing and discussion, the Security Track will not be broadcast or recorded. > > I apologise for the inconvenience. > > Regards, > Krassimir > > > On Sun, Sep 30, 2018, 1:05 PM Sam Oduor > wrote: > > Hi > > Any online link available for remote participation or viewing ? > > On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov > wrote: > > Hello Everyone, > > I wanted to attract your attention to the Security Track this coming NANOG. We'll be meeting on Tuesday morning and the line up looks like this: > * Andre Toonk - examples of hijacks, other ideas > * Alexander Azimov - State of BGP Security > * David Wishnick - ARIN TAL > * Job Snijders - Routing security roadmap > * Chris Morrow - So I need to start filtering routes from peers...' and 'hey guess who needs to update their IRR data?' > > Time permitting at the end of the time slot we'll have a panel and time for duscussion as well. > > Regards, > Krassi > > > > -- > Samson Oduor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtk at depaul.edu Mon Oct 1 11:59:38 2018 From: jtk at depaul.edu (John Kristoff) Date: Mon, 1 Oct 2018 06:59:38 -0500 Subject: NANOG Security Track: Route Security In-Reply-To: <446f6ff668d94ad09b12570b293f35ab@XCASPRD01-DFT.dpu.depaul.edu> References: <446f6ff668d94ad09b12570b293f35ab@XCASPRD01-DFT.dpu.depaul.edu> Message-ID: <20181001065938.509e1d82@p50.localdomain> On Mon, 1 Oct 2018 03:27:49 +0000 Ryan Hamel wrote: > Just like how all the email threads on NANOG are archived, all talks > should be archived as well. Whether to record a session or not is up to the presenter and track coordinator. The security track, originally called the ISP Security BoF started by Barry Greene and Merike Kaeo was in part an outgrowth of the nsp-security community. The nsp-security was a closed, vetted community. In those days, they were not recorded mainly so participants could feel reasonably comfortable sharing amongst each other by having the discussions limited to those there in person. For many years later it was more or less a given that the security track wasn't recorded. However, that position has weakened slightly and I take some of the blame for that. The last two security tracks I led (67/68) were recorded and I think there was at least one before that I asked be recorded, but it ended up not being captured because the meeting coordinators thought I made a mistake. :-) I had taken an informal poll before the first time about this. There were about three people as I recall who preferred them not to be recorded, suggesting they would not go on mic and participate if they were. Maybe during the session another show of hands should be taken to see who wants them recorded or not in the future. John From netravnen at gmail.com Mon Oct 1 12:14:26 2018 From: netravnen at gmail.com (Netravnen) Date: Mon, 1 Oct 2018 14:14:26 +0200 Subject: NANOG Security Track: Route Security In-Reply-To: <20181001065938.509e1d82@p50.localdomain> References: <446f6ff668d94ad09b12570b293f35ab@XCASPRD01-DFT.dpu.depaul.edu> <20181001065938.509e1d82@p50.localdomain> Message-ID: On Mon, 1 Oct 2018 at 14:01, John Kristoff wrote: > > On Mon, 1 Oct 2018 03:27:49 +0000 > Ryan Hamel wrote: > > > Just like how all the email threads on NANOG are archived, all talks > > should be archived as well. > > Whether to record a session or not is up to the presenter and track > coordinator. I would prefer if NANOG would record sessions by default! (And allow presenters to opt-out if they really feel like it.) Other conferences I have had participated to in the past. Had the option of allowing opt-out of being recorded on stage. From jason+nanog at lixfeld.ca Mon Oct 1 12:23:22 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Mon, 1 Oct 2018 08:23:22 -0400 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> <000253A6-5470-49B6-B506-321714E2BF25@arin.net> Message-ID: > On Oct 1, 2018, at 4:36 AM, Mark Tinka wrote: > > On 1/Oct/18 10:26, John Curran wrote: > >> Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR? > > Any equipment misconfigurations should be the responsibility of the operator. ^^ > Responsibility for ROA's should lie with the resource holder, in ensuring that not only is the information true, but that also all announced prefixes are covered by a ROA. ^^ I need to swap out the wheels on my car. I think I know better than to read the manual to, say, understand how much torque I should apply to each bolt, or what pattern I should use when tightening the bolts. Or, I read the manual but decide it’s too hard to understand, and I don’t ask for help in clearing up some of the grey areas. I change the wheels anyway. In the end, it looks right. They roll. Meh. All good. Then the wheels fall off. There is absolutely no one to blame for any of that but me. In my view, I see no difference here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Oct 1 13:09:25 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 1 Oct 2018 15:09:25 +0200 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <17700308-E8CA-4CB3-AB7B-E3C68A92EBF2@nlnetlabs.nl> <000253A6-5470-49B6-B506-321714E2BF25@arin.net> Message-ID: On 1/Oct/18 14:23, Jason Lixfeld wrote: > > > I need to swap out the wheels on my car.  I think I know better than > to read the manual to, say, understand how much torque I should apply > to each bolt, or what pattern I should use when tightening the bolts. >  Or, I read the manual but decide it’s too hard to understand, and I > don’t ask for help in clearing up some of the grey areas. > > I change the wheels anyway.  In the end, it looks right.  They roll. >  Meh.  All good. > > Then the wheels fall off. > > There is absolutely no one to blame for any of that but me. > > In my view, I see no difference here. As with anything else operators need to be responsible for their networks when running them. If I want to participate in the BGP on the Internet, I need to learn how to run BGP. If my part of the BGP breaks my network or those of others because I did not school myself on BGP, it's no one else's fault but mine. I can't blame the IETF for this. There is plenty of text freely available on the Internet about RPKI. In fact, I'd go as far as saying all RIR's have been running RPKI workshops for years. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Oct 1 14:39:03 2018 From: jcurran at arin.net (John Curran) Date: Mon, 1 Oct 2018 14:39:03 +0000 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <1ba8e559-13d9-1d73-5a50-82d1b85da2d4@seacom.mu> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <1ba8e559-13d9-1d73-5a50-82d1b85da2d4@seacom.mu> Message-ID: On 1 Oct 2018, at 1:20 AM, Mark Tinka > wrote: On 1/Oct/18 01:21, John Curran wrote: It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion. John, in the instance where all RIR's transition to a single "All Resource" TA, what would, in your mind, be the (potential) liability considerations? Mark - If there were to be an RIR CA outage, it would not appear that the RIRs use of “All Resources” TAs would materially affect the resulting operational impact to the Internet. (As noted earlier, the impact would be predominantly proportional to the number of ISPs that fail to follow best practices in route processing and fall back properly when their received routes end up with status NotFound, i.e. no longer match against their cache of validate ROAs since the cache has expired) The “All Resources” TA used by each RIR done to avoiding CA invalidation due to overclaiming (as detailed in https://datatracker.ietf.org/doc/rfc8360) – it reduces the probability of a different and hopefully rare RPKI failure scenario (involving the possible accidental invalidation of an RIR CA) until such time as a slightly different RPKI validation algorithm can be deployed that would limit any such invalidation solely to the resources in the overlap. (That’s my high-level understanding of the situation; comments on this question from those closer to the actual network bits would be most welcome…) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Mon Oct 1 11:27:31 2018 From: noah at neo.co.tz (Noah) Date: Mon, 1 Oct 2018 14:27:31 +0300 Subject: NANOG Security Track: Route Security In-Reply-To: References: <856d63c611c0425196dd6163421a67a4@LAX-MBX01.quadranet.local> <20181001034120.GA20069@meow.BKantor.net> Message-ID: +1 On Mon, 1 Oct 2018 7:53 am Job Snijders, wrote: > Hi all, > > Speaking as presenter in this track, I’d be fine with video recording and > online distribution. In fact, I’d encourage it, I don’t assume any secrecy > or confidentiality in this meeting. > > Perhaps for the NANOG74 meeting it is too late to organize video > recording, but going forward I’m a proponent of recording everything. It > creates more value for both the presenters and the global community. > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Mon Oct 1 16:44:17 2018 From: nick at foobar.org (Nick Hilliard) Date: Mon, 1 Oct 2018 17:44:17 +0100 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> Message-ID: <4a0859b5-7e20-41b0-431c-d07fcbd830f7@foobar.org> John Curran wrote on 01/10/2018 00:21: > There is likely some on the nanog mailing list who have a view on this > matter, so I pose the question of "who should be responsible" for > consequences of RPKI RIR CA failure to this list for further discussion. other replies in this thread have assumed that RPKI CA failure modes are restricted to loss of availability, but there are others failure modes, for example: - fraud: rogue CA employee / external threat actor signs ROAs illegitimately - negligence: CA accidentally signs illegitimate ROAs due to e.g. software bug - force majeure: e.g. court orders CA to sign prefix with AS0, complicated by NIR RPKI delegation in jurisdictions which may have difficult relations with other parts of the world. These types of situations are well-trodden territory for other types of PKI CA, where users Otherwise, as other people have pointed out, catastrophic systems failure at the CA is designed to be fail-safe. I.e. if the CA goes away, ROAs will be evaluated as "unknown" and life will continue on. If people misconfigure their networks and do silly things with this specific failure mode, that's their problem. You can't stop people from aiming guns at their feet and pulling the trigger. Nick From sandy at tislabs.com Mon Oct 1 18:04:43 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Mon, 1 Oct 2018 14:04:43 -0400 Subject: question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT Message-ID: <812C4A01-3798-4134-97E5-F6EBDEA888FD@tislabs.com> DHS had a program called PREDICT that made information important for security research available. The follow on is called IMPACT. https://www.impactcybertrust.org The key note speaker said his data was available under PREDICT, perhaps he meant IMPACT. Internet Atlas does show up on the IMPACT site. The IMPACT program has announced (see their home page) that due to a lack of funding support, the IMPACT program would cease operation in Dec 2018. That “continued use of existing data will expire and your ability to request data through IMPACT will no longer exist”. Can someone ask the speaker (can’t find support for remote attendees) if he knows if any impact from IMPACT’s ceasing to operation on the ability to look at the data that he said was available through PREDICT? —Sandy Murphy, Parsons From sandy at tislabs.com Mon Oct 1 18:16:18 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Mon, 1 Oct 2018 14:16:18 -0400 Subject: question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT In-Reply-To: <812C4A01-3798-4134-97E5-F6EBDEA888FD@tislabs.com> References: <812C4A01-3798-4134-97E5-F6EBDEA888FD@tislabs.com> Message-ID: Thank you thank you thank you for the person who saw my question and relayed at the mike! —Sandy > On Oct 1, 2018, at 2:04 PM, Sandra Murphy wrote: > > DHS had a program called PREDICT that made information important for security research available. > > The follow on is called IMPACT. https://www.impactcybertrust.org > > The key note speaker said his data was available under PREDICT, perhaps he meant IMPACT. Internet Atlas does show up on the IMPACT site. > > The IMPACT program has announced (see their home page) that due to a lack of funding support, the IMPACT program would cease operation in Dec 2018. That “continued use of existing data will expire and your ability to request data through IMPACT will no longer exist”. > > Can someone ask the speaker (can’t find support for remote attendees) if he knows if any impact from IMPACT’s ceasing to operation on the ability to look at the data that he said was available through PREDICT? > > —Sandy Murphy, Parsons From surfer at mauigateway.com Mon Oct 1 18:17:19 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 1 Oct 2018 11:17:19 -0700 Subject: NANOG Security Track: Route Security Message-ID: <20181001111719.30BEDD44@m0117459.ppops.net> --- karl_gerh at gmx.at wrote: From: Karl Gerhard Most of the readers here will never attend a NANOG meeting and a big part of those won't attend because they live on other parts of the planet. -------------------------------------------------------- Yep, 21 years on the list and I still have not had the chance to attend. It's a looong way from Hawaii. :-) scott From rwoolleynanog at gmail.com Mon Oct 1 18:47:44 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Mon, 1 Oct 2018 14:47:44 -0400 Subject: NANOG Security Track: Route Security In-Reply-To: References: <446f6ff668d94ad09b12570b293f35ab@XCASPRD01-DFT.dpu.depaul.edu> <20181001065938.509e1d82@p50.localdomain> Message-ID: On Mon, Oct 1, 2018 at 8:16 AM Netravnen wrote: > > On Mon, 1 Oct 2018 at 14:01, John Kristoff wrote: > > > > On Mon, 1 Oct 2018 03:27:49 +0000 > > Ryan Hamel wrote: > > > > > Just like how all the email threads on NANOG are archived, all talks > > > should be archived as well. > > > > Whether to record a session or not is up to the presenter and track > > coordinator. > > I would prefer if NANOG would record sessions by default! (And allow > presenters to opt-out if they really feel like it.) > > Other conferences I have had participated to in the past. Had the > option of allowing opt-out of being recorded on stage. This is in fact how it works now at NANOG. As John points out, the decision is left up to the submitter, but almost all talks are webcast and recorded. (Historically, the security track has not been recorded.) Anyone is welcome to submit talks, including tracks, for consideration, and to make this choice as submitter. In this case, the track moderator believes that it's better that the the talk to not be recorded and so we are honoring that request. Aside from the security track and one other submission, the remainder of the 3-day program will be available for viewing and recorded. Regards, Ryan Woolley NANOG PC Chair From Ryan.Hamel at quadranet.com Mon Oct 1 18:59:05 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Mon, 1 Oct 2018 18:59:05 +0000 Subject: NANOG Security Track: Route Security In-Reply-To: References: <446f6ff668d94ad09b12570b293f35ab@XCASPRD01-DFT.dpu.depaul.edu> <20181001065938.509e1d82@p50.localdomain> Message-ID: <2691a356c1af45599e329f8a402961f7@LAX-MBX01.quadranet.local> Ryan, what does the track moderator have to do with the presenter? All I here is an excuse to do a disservice to fellow members of this community. Do you really want to have future meetings with everyone holding out their phones, cameras, or other recording devices, to spread the wealth of knowledge? That's crazy. Ryan Hamel -----Original Message----- From: NANOG On Behalf Of Ryan Woolley Sent: Monday, October 01, 2018 11:48 AM To: NANOG Subject: Re: NANOG Security Track: Route Security On Mon, Oct 1, 2018 at 8:16 AM Netravnen wrote: > > On Mon, 1 Oct 2018 at 14:01, John Kristoff wrote: > > > > On Mon, 1 Oct 2018 03:27:49 +0000 > > Ryan Hamel wrote: > > > > > Just like how all the email threads on NANOG are archived, all > > > talks should be archived as well. > > > > Whether to record a session or not is up to the presenter and track > > coordinator. > > I would prefer if NANOG would record sessions by default! (And allow > presenters to opt-out if they really feel like it.) > > Other conferences I have had participated to in the past. Had the > option of allowing opt-out of being recorded on stage. This is in fact how it works now at NANOG. As John points out, the decision is left up to the submitter, but almost all talks are webcast and recorded. (Historically, the security track has not been recorded.) Anyone is welcome to submit talks, including tracks, for consideration, and to make this choice as submitter. In this case, the track moderator believes that it's better that the the talk to not be recorded and so we are honoring that request. Aside from the security track and one other submission, the remainder of the 3-day program will be available for viewing and recorded. Regards, Ryan Woolley NANOG PC Chair From job at instituut.net Mon Oct 1 19:12:42 2018 From: job at instituut.net (Job Snijders) Date: Mon, 1 Oct 2018 12:12:42 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: <2691a356c1af45599e329f8a402961f7@LAX-MBX01.quadranet.local> References: <446f6ff668d94ad09b12570b293f35ab@XCASPRD01-DFT.dpu.depaul.edu> <20181001065938.509e1d82@p50.localdomain> <2691a356c1af45599e329f8a402961f7@LAX-MBX01.quadranet.local> Message-ID: Perhaps the moderator and the presenters for this track can figure out (off list!) if there is unanimous support to record the session and reconsider. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Oct 1 19:30:43 2018 From: jcurran at arin.net (John Curran) Date: Mon, 1 Oct 2018 19:30:43 +0000 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <4a0859b5-7e20-41b0-431c-d07fcbd830f7@foobar.org> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <4a0859b5-7e20-41b0-431c-d07fcbd830f7@foobar.org> Message-ID: <75ED1B3D-E5F8-444C-85E7-9FA2F17446AF@arin.net> On 1 Oct 2018, at 9:44 AM, Nick Hilliard wrote: > > John Curran wrote on 01/10/2018 00:21: >> There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion. > > other replies in this thread have assumed that RPKI CA failure modes are restricted to loss of availability, but there are others failure modes, for example: > > - fraud: rogue CA employee / external threat actor signs ROAs illegitimately > > - negligence: CA accidentally signs illegitimate ROAs due to e.g. software bug > > - force majeure: e.g. court orders CA to sign prefix with AS0, complicated by NIR RPKI delegation in jurisdictions which may have difficult relations with other parts of the world. Nick - Agreed… My question was specific to liability consequential to an operational outage of an RIR CA, since the community’s view of the proper allocation of liability from loss of availability will significantly shape the necessary legalities. (Liability from fraud or gross negligence is unlikely to respect such terms in any case) > Otherwise, as other people have pointed out, catastrophic systems failure at the CA is designed to be fail-safe. I.e. if the CA goes away, ROAs will be evaluated as "unknown" and life will continue on. If people misconfigure their networks and do silly things with this specific failure mode, that's their problem. One would expect as much (i.e. it’s their problem for networks doing silly things), but we’ve heard some folks suggest it should be the RIR's problem (given the RIR CA's role in triggering events by going unavailable.) Thanks! /John John Curran President and CEO ARIN From job at ntt.net Mon Oct 1 21:19:15 2018 From: job at ntt.net (Job Snijders) Date: Mon, 1 Oct 2018 21:19:15 +0000 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <4a0859b5-7e20-41b0-431c-d07fcbd830f7@foobar.org> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> <4a0859b5-7e20-41b0-431c-d07fcbd830f7@foobar.org> Message-ID: <20181001211915.GG64655@vurt.meerval.net> Dear all, I'm very happy to see the direction this conversation has taken, seems we've moved on towards focussing on solutions and outcomes - this is encouraging. On Mon, Oct 01, 2018 at 05:44:17PM +0100, Nick Hilliard wrote: > John Curran wrote on 01/10/2018 00:21: > > There is likely some on the nanog mailing list who have a view on > > this matter, so I pose the question of "who should be responsible" > > for consequences of RPKI RIR CA failure to this list for further > > discussion. > > other replies in this thread have assumed that RPKI CA failure modes > are restricted to loss of availability, but there are others failure > modes, for example: > > - fraud: rogue CA employee / external threat actor signs ROAs > illegitimately > > - negligence: CA accidentally signs illegitimate ROAs due to e.g. > software bug > > - force majeure: e.g. court orders CA to sign prefix with AS0, > complicated by NIR RPKI delegation in jurisdictions which may have > difficult relations with other parts of the world. > > These types of situations are well-trodden territory for other types > of PKI CA, where users > > Otherwise, as other people have pointed out, catastrophic systems > failure at the CA is designed to be fail-safe. I.e. if the CA goes > away, ROAs will be evaluated as "unknown" and life will continue on. > If people misconfigure their networks and do silly things with this > specific failure mode, that's their problem. You can't stop people > from aiming guns at their feet and pulling the trigger. There are a number of failure modes and I believe the operational community has yet to fully explore how to mitigate most risks. Over time I expect we'll develop BCPs how to improve the robustness of the system; these BCPs can only come into existence driven by actual operational experierence. A positive development that addresses some aspects of the concerns raised is Certificate Transparency. Cloudflare set up a CT log (https://groups.google.com/forum/#!topic/certificate-transparency/_deL5iGB5sY) and I hope others like Google will also consider doing this. CT is a great tool to help keep the roots perform in line with community expectations. I consider it the operator community's responsibility to figure out how to deal with outages. I don't intend to hold the RIRs liable - we'll need to learn to protect ourselves. Kind regards, Job From ross at tajvar.io Tue Oct 2 01:57:39 2018 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 1 Oct 2018 21:57:39 -0400 Subject: Buying IPv4 blocks Message-ID: Hi all, My US-based employer will be starting a new business unit soon that will require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a waitlist (though I'm not sure where they're getting new IPs from), but the faster way is to buy blocks from people who already have them. I'm aware of Hilco Streambank - are there any other auctions? If I want to buy via private sale, does anyone know of ways to find sellers? Thanks, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at tgconrad.com Tue Oct 2 02:36:09 2018 From: tyler at tgconrad.com (Tyler Conrad) Date: Mon, 1 Oct 2018 19:36:09 -0700 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: I've used IPv4 Market Group before. Process was pretty painless, and they were trusting enough to allow us to pay by PO (your mileage may vary). http://ipv4marketgroup.com/ On Mon, Oct 1, 2018 at 6:57 PM, Ross Tajvar wrote: > Hi all, > > My US-based employer will be starting a new business unit soon that will > require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a > waitlist (though I'm not sure where they're getting new IPs from), but the > faster way is to buy blocks from people who already have them. I'm aware of > Hilco Streambank - are there any other auctions? If I want to buy via > private sale, does anyone know of ways to find sellers? > > Thanks, > Ross > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Tue Oct 2 04:41:40 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 02 Oct 2018 00:41:40 -0400 Subject: Verizon FIOS finally gets IPv6? Message-ID: <166325.1538455300@turing-police.cc.vt.edu> Chatter here is that at least some areas are seeing actual functional IPv6, dhcpv6-pd and all... https://www.dslreports.com/forum/r32136440-Networking-IPv6-working From morrowc.lists at gmail.com Tue Oct 2 05:09:11 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Oct 2018 01:09:11 -0400 Subject: Verizon FIOS finally gets IPv6? In-Reply-To: <166325.1538455300@turing-police.cc.vt.edu> References: <166325.1538455300@turing-police.cc.vt.edu> Message-ID: On Tue, Oct 2, 2018 at 12:43 AM wrote: > Chatter here is that at least some areas are seeing actual > functional IPv6, dhcpv6-pd and all... > > https://www.dslreports.com/forum/r32136440-Networking-IPv6-working wait, hell froze over?? wtf? (I don't see any ipv6 on my provider facing fios ethernet in washington-dc area) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Oct 2 05:12:29 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 2 Oct 2018 01:12:29 -0400 Subject: Verizon FIOS finally gets IPv6? In-Reply-To: References: <166325.1538455300@turing-police.cc.vt.edu> Message-ID: It's in a limited rollout. My boss's home FiOS router just got a firmware update that enables IPv6 but it's not getting an address yet. On Tue, Oct 2, 2018, 1:11 AM Christopher Morrow wrote: > > > On Tue, Oct 2, 2018 at 12:43 AM wrote: > >> Chatter here is that at least some areas are seeing actual >> functional IPv6, dhcpv6-pd and all... >> >> https://www.dslreports.com/forum/r32136440-Networking-IPv6-working > > > > wait, hell froze over?? wtf? > (I don't see any ipv6 on my provider facing fios ethernet in washington-dc > area) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Tue Oct 2 09:57:31 2018 From: woody at pch.net (Bill Woodcock) Date: Tue, 2 Oct 2018 02:57:31 -0700 Subject: question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT In-Reply-To: References: <812C4A01-3798-4134-97E5-F6EBDEA888FD@tislabs.com> Message-ID: <8342096B-93BB-4FCC-8A59-ABE30886BC1B@pch.net> >> On Oct 1, 2018, at 2:04 PM, Sandra Murphy wrote: >> >> DHS had a program called PREDICT that made information important for security research available. >> >> The follow on is called IMPACT. https://www.impactcybertrust.org >> >> The key note speaker said his data was available under PREDICT, perhaps he meant IMPACT. Internet Atlas does show up on the IMPACT site. >> >> The IMPACT program has announced (see their home page) that due to a lack of funding support, the IMPACT program would cease operation in Dec 2018. That “continued use of existing data will expire and your ability to request data through IMPACT will no longer exist”. >> >> Can someone ask the speaker (can’t find support for remote attendees) if he knows if any impact from IMPACT’s ceasing to operation on the ability to look at the data that he said was available through PREDICT? All of the PCH data will continue to be available directly from us, despite the PREDICT/IMPACT portal going away. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sandy at tislabs.com Tue Oct 2 10:44:15 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 2 Oct 2018 06:44:15 -0400 Subject: question to the current NANOG keynote speaker (Paul Barford) re: availability of data in PREDICT In-Reply-To: <8342096B-93BB-4FCC-8A59-ABE30886BC1B@pch.net> References: <812C4A01-3798-4134-97E5-F6EBDEA888FD@tislabs.com> <8342096B-93BB-4FCC-8A59-ABE30886BC1B@pch.net> Message-ID: I’d like to express my appreciation for the fact that PCH makes the data available and has for many years. The data collected by RouteViews, RIS and PCH is a god-send for researchers and operators alike. —Sandy > On Oct 2, 2018, at 5:57 AM, Bill Woodcock wrote: > >>> On Oct 1, 2018, at 2:04 PM, Sandra Murphy wrote: >>> >>> DHS had a program called PREDICT that made information important for security research available. >>> >>> The follow on is called IMPACT. https://www.impactcybertrust.org >>> >>> The key note speaker said his data was available under PREDICT, perhaps he meant IMPACT. Internet Atlas does show up on the IMPACT site. >>> >>> The IMPACT program has announced (see their home page) that due to a lack of funding support, the IMPACT program would cease operation in Dec 2018. That “continued use of existing data will expire and your ability to request data through IMPACT will no longer exist”. >>> >>> Can someone ask the speaker (can’t find support for remote attendees) if he knows if any impact from IMPACT’s ceasing to operation on the ability to look at the data that he said was available through PREDICT? > > All of the PCH data will continue to be available directly from us, despite the PREDICT/IMPACT portal going away. > > -Bill > From mehmet at akcin.net Tue Oct 2 11:26:22 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 2 Oct 2018 04:26:22 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: Nikos Thank you for your valuable feedback. We will make this happen! Looking forward to your further support On Sat, Sep 29, 2018 at 2:32 PM Nikos Mouat wrote: > > Hi Mehmet - > You mention the SIX so I figured I'd chime in on this thread, despite > being > an old one. > We were in a similar situation in early 1997 - Seattle was a backwoods > as far > as internet infrastructure, with the nearest hub of activity being > Mae-West / > PAIX, and not a whole lot else in our neck of the woods. We had tried to > build > some momentum with a T1/Frame-relay based multi-point peering fabric which > came > online in early '96, but it never got past 5 or 6 participants and didn't > get > much traction with some providers in the region. > We had talked about doing an ethernet based exchange in the Westin, > and the > University of Washington had started talking about building the SNNAP > (Seattle > Network to Network Access Point) which started up a mailing list in early > '97, > but it seemed to always be just over the horizon. (It eventually launched > as the > Pacific Northwest Gigapop, but not until much later, and focused on > research and > education orgs). > When Chris and I were sitting together at Nanog 10, Bill Manning gave a > couple presentations - "International Exchange Points: Growth & Trends" and > "Large & Small Exchange Points: Advantages,Tradeoffs, Futures", and one of > his > key points was something along the lines of "any exchange point with 3 or > more > participants is a successful exchange point". This was ultimately the final > nudge that was needed to convince us to start the peering point, and > shortly > after we got back from Tampa we threw a hub in on a port I was using for a > private peering session and we were in business. We've grown a lot since > then, > certainly the emergence of Seattle as a key content market helped a lot, > but I > think you can draw some parallels. > If you measure success as having three participants peering, and you > find a > way to get off the ground with minimal costs (or as in our case, none at > all), > it's easy to succeed in a not-for-profit model. > My advice to you is to not worry about if any out of region folks are > going > to show up - find a space that folks operating in the region can get to > easily, > build something that is inexpensive to keep online, keep it simple, and > get 3 > participants. Once you're there - look for the 4th, and so on. > > Good luck, > Nikos > > > > On Thu, 13 Sep 2018, Mehmet Akcin wrote: > > > It has been little over a year and we have been working on launching an > > internet exchange in puerto rico but of course hurricane and other things > > got in the way of achieving this. > > > > We now have identified what we believe the right location (most of the > > isp’s have presence in this location) backbone/ip transit connectivity, > > local team to provide onsite support. > > > > Having said that We have been engaged with several content delivery > > networks, OTTs but general feedback was that Puerto Rico was not on their > > radar for 2018 hence delayed launch. Now we are talking to same players > > about 2019 but general answer seemed like people were satisfied enough to > > serve Puerto Rico from Miami. > > > > Perhaps we are talking to really big CDNs, OTTs and we should engage > > differently however the level of interest is very low and I really don’t > > want to “build and they will come” again ;-) > > > > Bottom line is, if there was an IXP in Puerto Rico similar to ones in > > Florida, I am trying to understand who would actually deploy (just speak > to > > your company only please) because most of my assumptions were proven > wrong > > ;-) > > > > I guess I want to ask two questions, given its location in caribbean, > does > > Puerto Rico need an internet exchange point? Would you join it?(it will > be > > a membership based IXP where members share cost) > > > > Mehmet > > > > On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin wrote: > > > >> Hey there! > >> > >> ... ok this time I am not going to call it PRIX ;) well name doesn't > >> matter really. Nearly 13 years ago I have attempted to start Puerto rico > >> Internet exchange in San Juan. I have lived there over 5 years and i > just > >> wanted to really watch videos faster. The project somewhat died when i > >> moved to LA but now there are few interested party to start an internet > >> exchange in Puerto rico. The jsland historically had one of the slowest > >> broadband/internet services which seemed to have improved in recent > years > >> however as of 2017 there still is not an IX in Puerto rico. > >> > >> We , 3-4 internet engineers (on island and remote) , want to look into > >> relaunch of this IX and hopefully find a way to keep local traffic > >> exchanged at high speeds and low cost. We need expertise, and people who > >> want to help any way they can. > >> > >> We are trying to make this IX a not-for-profit one and we are looking at > >> opeeating models to adapt which has worked incredibly well like Seattle > IX. > >> > >> We are hoping the relaunch to happen sometime in 2018. Thanks in advance > >> hope to share more info and traffic data sometime , soon. Watch this > space! > >> > >> Mehmet > >> > > -- > > Mehmet > > +1-424-298-1903 > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at payam124.com Tue Oct 2 04:57:21 2018 From: me at payam124.com (Payam Poursaied) Date: Mon, 1 Oct 2018 21:57:21 -0700 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: Hi Ross Try ripe ncc’s broker list here: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brokers They would easily find what you need. As the process is usually through escrow.com, there shouldn’t be a serious concern. This one: https://www.ipv4auctions.com is doing that. Usually the prices is a bit higher If need more info, feel free to get in touch with me off-list -payam On Mon, Oct 1, 2018 at 6:59 PM Ross Tajvar wrote: > Hi all, > > My US-based employer will be starting a new business unit soon that will > require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a > waitlist (though I'm not sure where they're getting new IPs from), but the > faster way is to buy blocks from people who already have them. I'm aware of > Hilco Streambank - are there any other auctions? If I want to buy via > private sale, does anyone know of ways to find sellers? > > Thanks, > Ross > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at istaff.org Tue Oct 2 14:38:24 2018 From: jcurran at istaff.org (John Curran) Date: Tue, 2 Oct 2018 07:38:24 -0700 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: On 1 Oct 2018, at 6:57 PM, Ross Tajvar wrote: > > Hi all, > > My US-based employer will be starting a new business unit soon that will require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a waitlist (though I'm not sure where they're getting new IPs from), but the faster way is to buy blocks from people who already have them. I'm aware of Hilco Streambank - are there any other auctions? If I want to buy via private sale, does anyone know of ways to find sellers? Ross - No facilitator is necessary, but if you wish to know ones that are aware of ARIN’s procedures, then you can find them here: https://www.arin.net/resources/transfer_listing/facilitator_list.html Best wishes, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsondt-sec at hotmail.com Tue Oct 2 20:44:31 2018 From: tsondt-sec at hotmail.com (Sec L) Date: Tue, 2 Oct 2018 20:44:31 +0000 Subject: Outlook SNDS and amzn-noc-contact Message-ID: Hi all, I know it's a long shot but let me explain. We're trying to get some insights into how AWS SES delivers our transaction emails to Hotmail/Outlook/Live users (most emails are blackholed for some reasons). We got dedicated IPs for SES and would like to request access to Outlook.com Smart Network Data Services to see how those IPs perform. SNDS has an authorization process that requires clicking a link in a verification email sent to authorization addresses, which are chosen based on reverse DNS and WHOIS of the IPs (more details here: https://sendersupport.olc.protection.outlook.com/snds/FAQ.aspx#AddressChoosing) Because the dedicated IPs are provisioned by AWS SES, all of the authorization email addresses are @amazon.com, @amazonaws.com or @amazonses.com. One of the addresses is amzn-noc-contact at amazon.com. I wonder if someone here from AWS can help me off-list to finish the authorization process. We have tried to escalate with AWS Support without success. Thanks a lot. Son -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillists at krassi.biz Tue Oct 2 18:46:46 2018 From: maillists at krassi.biz (Krassimir Tzvetanov) Date: Tue, 2 Oct 2018 11:46:46 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: Hello Everyone, Here is the copy of the combined slide deck. Thanks everyone. Regards, Krassimir On Thu, Sep 27, 2018 at 9:54 PM Krassimir T. Tzvetanov wrote: > Hello Everyone, > > I wanted to attract your attention to the Security Track this coming > NANOG. We'll be meeting on Tuesday morning and the line up looks like this: > * Andre Toonk - examples of hijacks, other ideas > * Alexander Azimov - State of BGP Security > * David Wishnick - ARIN TAL > * Job Snijders - Routing security roadmap > * Chris Morrow - So I need to start filtering routes from peers...' and > 'hey guess who needs to update their IRR data?' > > Time permitting at the end of the time slot we'll have a panel and time > for duscussion as well. > > Regards, > Krassi > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Oct 3 04:30:45 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Oct 2018 00:30:45 -0400 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: My slides are: http://tiny.cc/8rnmzy On Tue, Oct 2, 2018 at 10:44 PM Krassimir Tzvetanov wrote: > Hello Everyone, > > Here is the copy of the combined slide deck. > > Thanks everyone. > > Regards, > Krassimir > > > On Thu, Sep 27, 2018 at 9:54 PM Krassimir T. Tzvetanov > wrote: > >> Hello Everyone, >> >> I wanted to attract your attention to the Security Track this coming >> NANOG. We'll be meeting on Tuesday morning and the line up looks like this: >> * Andre Toonk - examples of hijacks, other ideas >> * Alexander Azimov - State of BGP Security >> * David Wishnick - ARIN TAL >> * Job Snijders - Routing security roadmap >> * Chris Morrow - So I need to start filtering routes from peers...' and >> 'hey guess who needs to update their IRR data?' >> >> Time permitting at the end of the time slot we'll have a panel and time >> for duscussion as well. >> >> Regards, >> Krassi >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at unlimitednet.us Wed Oct 3 12:18:30 2018 From: jason at unlimitednet.us (Jason Canady) Date: Wed, 3 Oct 2018 08:18:30 -0400 Subject: JCPenny Contact Message-ID: <4eb907f9-779b-ebec-1a23-353a93833ca6@unlimitednet.us> Hello, We are looking to contact someone at JCPenny in the abuse/NOC department.  Can anyone contact me from JCPenny or send me information off-list to someone there that can help me? Thank you! Jason From maillists at krassi.biz Wed Oct 3 15:35:06 2018 From: maillists at krassi.biz (Krassimir Tzvetanov) Date: Wed, 3 Oct 2018 08:35:06 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: Here they are on the main site: https://pc.nanog.org/static/published/meetings/NANOG74/agenda.html On Tue, Oct 2, 2018, 9:30 PM Christopher Morrow wrote: > > > My slides are: > http://tiny.cc/8rnmzy > > On Tue, Oct 2, 2018 at 10:44 PM Krassimir Tzvetanov > wrote: > >> Hello Everyone, >> >> Here is the copy of the combined slide deck. >> >> Thanks everyone. >> >> Regards, >> Krassimir >> >> >> On Thu, Sep 27, 2018 at 9:54 PM Krassimir T. Tzvetanov >> wrote: >> >>> Hello Everyone, >>> >>> I wanted to attract your attention to the Security Track this coming >>> NANOG. We'll be meeting on Tuesday morning and the line up looks like this: >>> * Andre Toonk - examples of hijacks, other ideas >>> * Alexander Azimov - State of BGP Security >>> * David Wishnick - ARIN TAL >>> * Job Snijders - Routing security roadmap >>> * Chris Morrow - So I need to start filtering routes from peers...' and >>> 'hey guess who needs to update their IRR data?' >>> >>> Time permitting at the end of the time slot we'll have a panel and time >>> for duscussion as well. >>> >>> Regards, >>> Krassi >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From meirea at charterschoolit.com Wed Oct 3 17:58:40 2018 From: meirea at charterschoolit.com (Mario Eirea) Date: Wed, 3 Oct 2018 17:58:40 +0000 Subject: FIU Contact Message-ID: Could someone from Florida International University it please contact me. Im having an issue where one of the schools we manage cannot reach my.fiu.edu. I suspect something triggered an automatic block. Thank you, Mario Eirea IT Department Layer 8 Solutions 7701 W 26th Ave Unit 2 Hialeah, FL 33016-5603 25.892545°, -80.335783° U.S.A., Earth, Solar System, Milky Way, Local Group, Universe Ph: 786-212-1660 “I am convinced that the act of thinking logically cannot possibly be natural to the human mind. If it were, then mathematics would be everybody's easiest course at school and our species would not have taken several millennia to figure out the scientific method.” -Neil deGrasse Tyson [https://charterschoolit.com/1up_micro.png] [http://charterschoolit.com/layer8_micro.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at andyring.com Wed Oct 3 18:52:35 2018 From: andy at andyring.com (Andy Ringsmuth) Date: Wed, 3 Oct 2018 13:52:35 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test Message-ID: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From milt at net2atlanta.com Wed Oct 3 19:23:33 2018 From: milt at net2atlanta.com (Milt Aitken) Date: Wed, 3 Oct 2018 15:23:33 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <122e01d45b4e$936910a0$ba3b31e0$@com> I got it on a Verizon Android. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth Sent: Wednesday, October 03, 2018 2:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From jhaustin at gmail.com Wed Oct 3 19:23:20 2018 From: jhaustin at gmail.com (Jeremy Austin) Date: Wed, 3 Oct 2018 11:23:20 -0800 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: I received it. On AT&T, but not on AT&T Wifi Calling — I got it about :30 EDT, when I went outside within range of a 4G signal. On Wed, Oct 3, 2018 at 11:22 AM Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -- Jeremy Austin jhaustin at gmail.com (907) 895-2311 office (907) 803-5422 cell Heritage NetWorks - Whitestone Power & Communications - Vertical Broadband, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenny.taylor at kccd.edu Wed Oct 3 19:23:40 2018 From: kenny.taylor at kccd.edu (Kenny Taylor) Date: Wed, 3 Oct 2018 19:23:40 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: We received it on T-Mobile and MetroPCS as well. -----Original Message----- From: NANOG On Behalf Of Andy Ringsmuth Sent: Wednesday, October 3, 2018 11:53 AM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From chaim.rieger at gmail.com Wed Oct 3 19:26:03 2018 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 3 Oct 2018 12:26:03 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: IPhone on vzw here. Received On Wed, Oct 3, 2018 at 12:23 Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nate at santafe.edu Wed Oct 3 19:26:25 2018 From: nate at santafe.edu (Nate Metheny) Date: Wed, 3 Oct 2018 13:26:25 -0600 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <122e01d45b4e$936910a0$ba3b31e0$@com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: <1d9d3c0f-3707-3ee6-501c-bf386b1a3de9@santafe.edu> Here in Santa Fe on Android / TMO no message was received. On 10/03/2018 01:23 PM, Milt Aitken wrote: > I got it on a Verizon Android. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth > Sent: Wednesday, October 03, 2018 2:53 PM > To: nanog at nanog.org > Subject: Oct. 3, 2018 EAS Presidential Alert test > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > -- .==== === -- - -- - - - - - ---. | Nate Metheny Director, Technology | | Santa Fe Institute office 505.946.2730 | | cell 505.672.8790 fax 505.982.0565 | | http://www.santafe.edu nate at santafe.edu | `--- - -- - - -- - = == ===' -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3804 bytes Desc: S/MIME Cryptographic Signature URL: From Ryan.Hamel at quadranet.com Wed Oct 3 19:26:51 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 3 Oct 2018 19:26:51 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <122e01d45b4e$936910a0$ba3b31e0$@com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: <2e28451aaac549118bbab28f9b4f7f66@LAX-MBX01.quadranet.local> Confirmed Verizon - Android - Los Angeles. -- Ryan Hamel Network Engineer ryan.hamel at quadranet.com | +1 (888) 578-2372 x201 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Milt Aitken Sent: Wednesday, October 3, 2018 12:24 PM To: 'Andy Ringsmuth' ; nanog at nanog.org Subject: RE: Oct. 3, 2018 EAS Presidential Alert test I got it on a Verizon Android. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth Sent: Wednesday, October 03, 2018 2:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From bensons at queuefull.net Wed Oct 3 19:28:21 2018 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 3 Oct 2018 12:28:21 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: Hi, Andy. I don't have a helpful answer for you, because I'm at the NANOG meeting in Canada right now and as far as I could tell none of the attendees' phones alerted. But I am curious if perhaps your office has a micro-cell for AT&T, or something like that, which might have caused different behavior versus the public tower? Cheers, -Benson On Wed, Oct 3, 2018, 12:22 Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaim.rieger at gmail.com Wed Oct 3 19:28:36 2018 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 3 Oct 2018 12:28:36 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <122e01d45b4e$936910a0$ba3b31e0$@com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: Asked co-workers that are on att and about half say they didn't get it. On Wed, Oct 3, 2018 at 12:26 Milt Aitken wrote: > I got it on a Verizon Android. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth > Sent: Wednesday, October 03, 2018 2:53 PM > To: nanog at nanog.org > Subject: Oct. 3, 2018 EAS Presidential Alert test > > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mis at seiden.com Wed Oct 3 19:29:29 2018 From: mis at seiden.com (mark seiden) Date: Wed, 3 Oct 2018 12:29:29 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <90c6094d-4d32-aa00-76e8-b34451a50a17@seiden.com> my entire bus in san francisco got it.  the expressions were priceless. t-mobile sent it earlier than other carriers -- i got it at x:18 On 10/3/18 11:52 AM, Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > From gary at lsu.edu Wed Oct 3 19:30:46 2018 From: gary at lsu.edu (Gary A Mumphrey) Date: Wed, 3 Oct 2018 19:30:46 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: We received it using the following platforms in Louisiana (Baton Rouge / New Orleans areas): AT&T (including Cricket) and Sprint iPhone and Android devices ~1:18 PM CDT -----Original Message----- From: NANOG On Behalf Of Kenny Taylor Sent: Wednesday, October 03, 2018 2:24 PM To: Andy Ringsmuth ; nanog at nanog.org Subject: RE: Oct. 3, 2018 EAS Presidential Alert test We received it on T-Mobile and MetroPCS as well. -----Original Message----- From: NANOG On Behalf Of Andy Ringsmuth Sent: Wednesday, October 3, 2018 11:53 AM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From me at robbiet.us Wed Oct 3 19:23:59 2018 From: me at robbiet.us (Robbie Trencheny) Date: Wed, 3 Oct 2018 12:23:59 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: I did not receive on my iPhone or Apple Watch (LTE) either. Both are T-Mobile and I'm in Oakland, CA. On Wed, Oct 3, 2018 at 12:21 Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -- -- Robbie Trencheny (@robbie ) 925-884-3728 robbie.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.joseph.johnson at gmail.com Wed Oct 3 19:25:33 2018 From: anthony.joseph.johnson at gmail.com (Anthony Johnson) Date: Wed, 3 Oct 2018 14:25:33 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: I have a Verizon iPhone 7 and did not receive the alert. I did get it on a T-Mobile Pixel 2 though. On Wed, Oct 3, 2018, 14:23 Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccummings at coeur.com Wed Oct 3 19:25:47 2018 From: ccummings at coeur.com (Cummings, Chris) Date: Wed, 3 Oct 2018 19:25:47 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: Yes, I received an alert on AT&T, iPhone X. 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.  Please consider the environment before printing this e-mail. -----Original Message----- From: NANOG On Behalf Of Andy Ringsmuth Sent: Wednesday, October 3, 2018 1:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.fema.gov%2femergency-alert-test&c=E,1,fr72hHe6gedphTpcUqBwvpTK0WFmRjf7FqlICQnIEFygbifiMG8spgvX2tJfj2gVu_Q8AYt5R6lOtqjxEEMXT5lY17sbIBJWi2Q0YGTIM8k4qqc,&typo=1 "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From kmiller at vantage.com Wed Oct 3 19:26:15 2018 From: kmiller at vantage.com (Kevin Miller) Date: Wed, 3 Oct 2018 15:26:15 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <1515375609.8138648.1538594775325.JavaMail.zimbra@vantage.com> I cannot speak for AT&T, but my T-Mobile iPhones did not receive them either. I was told by support that if you enabled WiFi-calling, you may not receive the alert. If this is true, it seems to be a safety issue as WiFi calling was enabled by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkain1 at ford.com Wed Oct 3 19:33:12 2018 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Wed, 3 Oct 2018 19:33:12 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <74fab0933e9f4d06a121e9eed1f5f764@ford.com> I got 1:19 and 1:21 (att then siruis) -----Original Message----- From: NANOG On Behalf Of Andy Ringsmuth Sent: Wednesday, October 03, 2018 2:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From ryan at kearney.io Wed Oct 3 19:40:55 2018 From: ryan at kearney.io (Ryan Kearney) Date: Wed, 3 Oct 2018 14:40:55 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: Awesome, I'm looking forward to hearing about all the locations a nationwide test was and was not received in. On Wed, Oct 3, 2018 at 2:23 PM Andy Ringsmuth wrote: > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > From james.cutler at consultant.com Wed Oct 3 19:43:35 2018 From: james.cutler at consultant.com (James R Cutler) Date: Wed, 3 Oct 2018 15:43:35 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2e28451aaac549118bbab28f9b4f7f66@LAX-MBX01.quadranet.local> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> <2e28451aaac549118bbab28f9b4f7f66@LAX-MBX01.quadranet.local> Message-ID: <83166567-6649-4465-8B34-6A2CBF97C2C1@consultant.com> Andy, Received on iPhone 7/iOS 12 on Sprint in SE Michigan. > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth > Sent: Wednesday, October 03, 2018 2:53 PM > To: nanog at nanog.org > Subject: Oct. 3, 2018 EAS Presidential Alert test > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > From rjoffe at centergate.com Wed Oct 3 19:47:12 2018 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 3 Oct 2018 12:47:12 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <7EDFE2D7-84BF-464E-8E1F-544A1EF7AA7A@centergate.com> Weirdly, I received 3. One of them is both French/English. More weirdly i am in the air, on the way from Nanog Vancouver to Denver. We were still in Canada airspace, and my AT&T phone showed clearly “no service”. The phone was NOT on wi-fi. Screen captures if anyone wants. > On Oct 3, 2018, at 11:52 AM, Andy Ringsmuth wrote: > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > From mike.lyon at gmail.com Wed Oct 3 19:53:57 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 3 Oct 2018 12:53:57 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: Iphone, vzw, silicon valley, rcvd. Interesting question though... I wonder if people on micro-cells and/or wifi calling don’t get the alerts. That would be extremely dumb and irresponsible of the cell phone carriers, so its likely the case :) In rural America where cell coverage may not exist but the customer may have PTMP wireless internet and is using a microcell and/or wifi calling over the internet, if they dont get the alert, that could be catastrophic. Something along the lines of the Santa Rosa, CA fires catastrophic. I wonder if that is the case. -Mike > On Oct 3, 2018, at 12:28, Chaim Rieger wrote: > > Asked co-workers that are on att and about half say they didn't get it. > >> On Wed, Oct 3, 2018 at 12:26 Milt Aitken wrote: >> I got it on a Verizon Android. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth >> Sent: Wednesday, October 03, 2018 2:53 PM >> To: nanog at nanog.org >> Subject: Oct. 3, 2018 EAS Presidential Alert test >> >> Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. >> >> I’m in CDT, so 1:18 and 1:20 p.m. CDT. >> >> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. >> >> FEMA says https://www.fema.gov/emergency-alert-test >> >> "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." >> >> My wife, with a Sprint iPhone, received the test. >> >> >> ---- >> Andy Ringsmuth >> 5609 Harding Drive >> Lincoln, NE 68521-5831 >> (402) 304-0083 >> andy at andyring.com >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From selphie.keller at gmail.com Wed Oct 3 20:01:54 2018 From: selphie.keller at gmail.com (Selphie Keller) Date: Wed, 3 Oct 2018 14:01:54 -0600 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: I did receive the alert on samsung devices: note 8 (tmobile), note 3 (no sim card/no service), and galaxy s6 (verizon) ~12:18 MDT (GMT-6) On Wed, 3 Oct 2018 at 13:55, Robbie Trencheny wrote: > I did not receive on my iPhone or Apple Watch (LTE) either. Both are > T-Mobile and I'm in Oakland, CA. > > On Wed, Oct 3, 2018 at 12:21 Andy Ringsmuth wrote: > >> Did anyone on AT&T or an iPhone receive the test today? I believe it was >> supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 >> EDT. >> >> I’m in CDT, so 1:18 and 1:20 p.m. CDT. >> >> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the >> sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full >> of AT&T iPhones and not a single one of them alerted. >> >> FEMA says https://www.fema.gov/emergency-alert-test >> >> "Cell towers will broadcast the WEA test for approximately 30 minutes >> beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones >> that are switched on, within range of an active cell tower, and whose >> wireless provider participates in WEA should be capable of receiving the >> test message. Some cell phones will not receive the test message, and cell >> phones should only receive the message once." >> >> My wife, with a Sprint iPhone, received the test. >> >> >> ---- >> Andy Ringsmuth >> 5609 Harding Drive >> Lincoln, NE 68521-5831 >> (402) 304-0083 >> andy at andyring.com >> >> -- > -- > Robbie Trencheny (@robbie ) > 925-884-3728 > robbie.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Wed Oct 3 20:07:59 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 3 Oct 2018 13:07:59 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test Message-ID: <20181003200759.GA36414@meow.BKantor.net> Alert was received on two Tracfone (Verizon?) Android in San Diego. A few minutes later, cable (Spectrum/TimeWarner) music service was interrupted by the alert tones, then a voice announcement began but cut off mid-word and the music resumed less than 5 seconds into the announcement. No terminating alert tones were heard. My AT&T (formerly PacBell) landline rang around that time but as I never answer it, I don't know if it was related. No message was recorded. - Brian From mhuff at ox.com Wed Oct 3 20:09:56 2018 From: mhuff at ox.com (Matthew Huff) Date: Wed, 3 Oct 2018 20:09:56 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <9433163a259e4345a0e34712036263d7@ox.com> I received it on my iPhone XS Max running iOS 12.0 with AT&T, wifi calling off... ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth Sent: Wednesday, October 3, 2018 2:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From chris at scsalaska.net Wed Oct 3 20:10:24 2018 From: chris at scsalaska.net (Chris J. Ruschmann) Date: Wed, 3 Oct 2018 20:10:24 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <74fab0933e9f4d06a121e9eed1f5f764@ford.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <74fab0933e9f4d06a121e9eed1f5f764@ford.com> Message-ID: Can we stop spamming this list? I don’t care if you received the alert or not. Contact the FCC or the whitehouse. -----Original Message----- From: NANOG On Behalf Of Kain, Rebecca (.) Sent: Wednesday, October 3, 2018 11:33 AM To: Andy Ringsmuth ; nanog at nanog.org Subject: RE: Oct. 3, 2018 EAS Presidential Alert test I got 1:19 and 1:21 (att then siruis) -----Original Message----- From: NANOG On Behalf Of Andy Ringsmuth Sent: Wednesday, October 03, 2018 2:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From bill at herrin.us Wed Oct 3 20:15:03 2018 From: bill at herrin.us (William Herrin) Date: Wed, 3 Oct 2018 16:15:03 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: On Wed, Oct 3, 2018 at 3:21 PM Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? AT&T Android in Virginia. I received it. The Washington Post is reporting that, "A number of iPhone users on AT&T’s network did not receive the notification until they had rebooted their smartphones." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog08 at mulligan.org Wed Oct 3 20:26:21 2018 From: nanog08 at mulligan.org (Geoff Mulligan) Date: Wed, 3 Oct 2018 14:26:21 -0600 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <734e9e9e-3f75-8056-581e-c8689fcb8ae7@mulligan.org> Received on Android on Sprint here in Colorado     Geoff Mulligan     CTO IIoT @ Jabil On 10/03/2018 01:23 PM, Robbie Trencheny wrote: > I did not receive on my iPhone or Apple Watch (LTE) either. Both are > T-Mobile and I'm in Oakland, CA. > > On Wed, Oct 3, 2018 at 12:21 Andy Ringsmuth > wrote: > > Did anyone on AT&T or an iPhone receive the test today? I believe > it was supposed to happen at 2:18 EDT, followed by one on > broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of > the sending of this at 1:52 p.m. CDT, nothing on phones. I have an > office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 > minutes beginning at 2:18 p.m. EDT. During this time, WEA > compatible cell phones that are switched on, within range of an > active cell tower, and whose wireless provider participates in WEA > should be capable of receiving the test message. Some cell phones > will not receive the test message, and cell phones should only > receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -- > -- > Robbie Trencheny (@robbie ) > 925-884-3728 > robbie.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvandolson at esri.com Wed Oct 3 20:28:29 2018 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 3 Oct 2018 13:28:29 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: <20181003202829.GA3448@esri.com> Anecdotally, we had staff feeding off of both AT&T and VZW IP-based metrocells get the alert message. Ray On Wed, Oct 03, 2018 at 12:53:57PM -0700, mike.lyon at gmail.com wrote: > Iphone, vzw, silicon valley, rcvd. > > Interesting question though... I wonder if people on micro-cells > and/or wifi calling don’t get the alerts. That would be extremely > dumb and irresponsible of the cell phone carriers, so its likely the > case :) > > In rural America where cell coverage may not exist but the customer > may have PTMP wireless internet and is using a microcell and/or wifi > calling over the internet, if they dont get the alert, that could be > catastrophic. Something along the lines of the Santa Rosa, CA fires > catastrophic. > > I wonder if that is the case. > > -Mike From lists.nanog at monmotha.net Wed Oct 3 20:37:15 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 3 Oct 2018 16:37:15 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: Alert received on Sprint in the Indianapolis area. I was on a phone call at the time [note that my handset doesn't do VoLTE - not sure if any Sprint handsets will at this time], and the alert was deferred until the call was terminated at approximately 14:30 EDT but was displayed immediately once that happened. -- Brandon Martin From sob at academ.com Wed Oct 3 20:40:44 2018 From: sob at academ.com (Stan Barber) Date: Wed, 3 Oct 2018 13:40:44 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <20181003202829.GA3448@esri.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> <20181003202829.GA3448@esri.com> Message-ID: I got it on ATT IPhone I have and a Verizon Pixel as well. On Wed, Oct 3, 2018 at 1:38 PM Ray Van Dolson wrote: > Anecdotally, we had staff feeding off of both AT&T and VZW IP-based > metrocells get the alert message. > > Ray > > On Wed, Oct 03, 2018 at 12:53:57PM -0700, mike.lyon at gmail.com wrote: > > Iphone, vzw, silicon valley, rcvd. > > > > Interesting question though... I wonder if people on micro-cells > > and/or wifi calling don’t get the alerts. That would be extremely > > dumb and irresponsible of the cell phone carriers, so its likely the > > case :) > > > > In rural America where cell coverage may not exist but the customer > > may have PTMP wireless internet and is using a microcell and/or wifi > > calling over the internet, if they dont get the alert, that could be > > catastrophic. Something along the lines of the Santa Rosa, CA fires > > catastrophic. > > > > I wonder if that is the case. > > > > -Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kshymkiw at gmail.com Wed Oct 3 19:36:05 2018 From: kshymkiw at gmail.com (Kevin Shymkiw) Date: Wed, 3 Oct 2018 13:36:05 -0600 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: Google Pixel2XL on VZW. Didn't receive anything Kevin On Wed, Oct 3, 2018, 13:34 Chaim Rieger wrote: > IPhone on vzw here. Received > > On Wed, Oct 3, 2018 at 12:23 Andy Ringsmuth wrote: > >> Did anyone on AT&T or an iPhone receive the test today? I believe it was >> supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 >> EDT. >> >> I’m in CDT, so 1:18 and 1:20 p.m. CDT. >> >> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the >> sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full >> of AT&T iPhones and not a single one of them alerted. >> >> FEMA says https://www.fema.gov/emergency-alert-test >> >> "Cell towers will broadcast the WEA test for approximately 30 minutes >> beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones >> that are switched on, within range of an active cell tower, and whose >> wireless provider participates in WEA should be capable of receiving the >> test message. Some cell phones will not receive the test message, and cell >> phones should only receive the message once." >> >> My wife, with a Sprint iPhone, received the test. >> >> >> ---- >> Andy Ringsmuth >> 5609 Harding Drive >> Lincoln, NE 68521-5831 >> (402) 304-0083 >> andy at andyring.com >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From udeme at ukutt.com Wed Oct 3 19:36:14 2018 From: udeme at ukutt.com (Udeme Ukutt) Date: Wed, 3 Oct 2018 15:36:14 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: VZW iPhone - received around 2.20pm EST. On Wed, Oct 3, 2018 at 3:23 PM Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at pardini.org Wed Oct 3 19:36:34 2018 From: tony at pardini.org (Anthony Pardini) Date: Wed, 3 Oct 2018 14:36:34 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: ATT Android worked in Texas. On Wed, Oct 3, 2018, 2:31 PM Kenny Taylor wrote: > We received it on T-Mobile and MetroPCS as well. > > > -----Original Message----- > From: NANOG On Behalf Of Andy Ringsmuth > Sent: Wednesday, October 3, 2018 11:53 AM > To: nanog at nanog.org > Subject: Oct. 3, 2018 EAS Presidential Alert test > > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 > EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full > of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and cell > phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at remotelylocated.com Wed Oct 3 19:38:05 2018 From: jason at remotelylocated.com (Jason Wilson) Date: Wed, 3 Oct 2018 12:38:05 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <1051C8C8-C00E-4381-A1B1-5F800D13827E@remotelylocated.com> VZW and Fi phones both had positive activation. Local small town Radio Station also had positive EAS activation in California. No Weather Radio Activation. Jason Wilson Remotely Located Providing High Speed Internet to out of the way places. 530-651-1736 Office 530-748-9608 Cell www.remotelylocated.com > On Oct 3, 2018, at 11:52 AM, Andy Ringsmuth wrote: > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at andyring.com Wed Oct 3 19:39:59 2018 From: andy at andyring.com (Andy Ringsmuth) Date: Wed, 3 Oct 2018 14:39:59 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <1515375609.8138648.1538594775325.JavaMail.zimbra@vantage.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1515375609.8138648.1538594775325.JavaMail.zimbra@vantage.com> Message-ID: <239F3364-B2FF-45A6-A7FD-39693C463393@andyring.com> > On Oct 3, 2018, at 2:26 PM, Kevin Miller wrote: > > I cannot speak for AT&T, but my T-Mobile iPhones did not receive them either. I was told by support that if you enabled WiFi-calling, you may not receive the alert. If this is true, it seems to be a safety issue as WiFi calling was enabled by default. Interesting. That seems to be a gigantic hole in this entire process. I do have my iPhone set to WiFi Calling as AT&T’s signal has trouble reaching inside our building very well. FEMA also notes: A dedicated mailbox has been created for all questions relating to the IPAWS National Test. Please e-mail us at FEMA-National-Test at fema.dhs.gov. I e-mailed them with my results as well. Might be worth considering sending a report to that address yourself if you didn’t receive it. If our friend Kim lobs a rocket this way for some reason, I’d kinda like to know about it before the sky turns orange. :-) ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From leeb at ratnaling.org Wed Oct 3 20:07:03 2018 From: leeb at ratnaling.org (Lee Brown) Date: Wed, 3 Oct 2018 13:07:03 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <1515375609.8138648.1538594775325.JavaMail.zimbra@vantage.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1515375609.8138648.1538594775325.JavaMail.zimbra@vantage.com> Message-ID: I work underground so I'm in airplane mode with WiFi calling enabled. Nothing on Verizon Android. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.Fernandes at dot.gov Wed Oct 3 20:13:29 2018 From: Paul.Fernandes at dot.gov (Fernandes, Paul (Volpe)) Date: Wed, 3 Oct 2018 20:13:29 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: Got it on both AT&T and Verizon iPhones in New England. Sincerely, Paul -----Original Message----- From: NANOG [mailto:nanog-bounces+paul.fernandes=dot.gov at nanog.org] On Behalf Of Kenny Taylor Sent: Wednesday, October 03, 2018 3:24 PM To: Andy Ringsmuth ; nanog at nanog.org Subject: RE: Oct. 3, 2018 EAS Presidential Alert test We received it on T-Mobile and MetroPCS as well. -----Original Message----- From: NANOG On Behalf Of Andy Ringsmuth Sent: Wednesday, October 3, 2018 11:53 AM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From nathan at robotics.net Wed Oct 3 20:21:28 2018 From: nathan at robotics.net (Nathan Stratton) Date: Wed, 3 Oct 2018 16:21:28 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: On Wed, Oct 3, 2018 at 4:18 PM wrote: > Iphone, vzw, silicon valley, rcvd. > > Interesting question though... I wonder if people on micro-cells and/or > wifi calling don’t get the alerts. That would be extremely dumb and > irresponsible of the cell phone carriers, so its likely the case :) > Very possible, I have two phones on a AT&T micro-cells and both missed it. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschmi at gmail.com Wed Oct 3 20:49:09 2018 From: aschmi at gmail.com (Adrian Schmidt) Date: Wed, 3 Oct 2018 13:49:09 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> <20181003202829.GA3448@esri.com> Message-ID: My son who has a Canadian line got it while in the Washington state area. Adrian On Wed, Oct 3, 2018 at 1:44 PM Stan Barber wrote: > I got it on ATT IPhone I have and a Verizon Pixel as well. > > On Wed, Oct 3, 2018 at 1:38 PM Ray Van Dolson wrote: > >> Anecdotally, we had staff feeding off of both AT&T and VZW IP-based >> metrocells get the alert message. >> >> Ray >> >> On Wed, Oct 03, 2018 at 12:53:57PM -0700, mike.lyon at gmail.com wrote: >> > Iphone, vzw, silicon valley, rcvd. >> > >> > Interesting question though... I wonder if people on micro-cells >> > and/or wifi calling don’t get the alerts. That would be extremely >> > dumb and irresponsible of the cell phone carriers, so its likely the >> > case :) >> > >> > In rural America where cell coverage may not exist but the customer >> > may have PTMP wireless internet and is using a microcell and/or wifi >> > calling over the internet, if they dont get the alert, that could be >> > catastrophic. Something along the lines of the Santa Rosa, CA fires >> > catastrophic. >> > >> > I wonder if that is the case. >> > >> > -Mike >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denniss at imaginesoftware.com Wed Oct 3 21:01:47 2018 From: denniss at imaginesoftware.com (Dennis Serkov) Date: Wed, 3 Oct 2018 21:01:47 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <74fab0933e9f4d06a121e9eed1f5f764@ford.com>, Message-ID: <22DD2E95-472D-459C-8FB4-1EE4FFBF0DC4@imaginesoftware.com> +1 Dennis S > On Oct 3, 2018, at 4:25 PM, Chris J. Ruschmann wrote: > > Can we stop spamming this list? > > I don’t care if you received the alert or not. Contact the FCC or the whitehouse. > > -----Original Message----- > From: NANOG On Behalf Of Kain, Rebecca (.) > Sent: Wednesday, October 3, 2018 11:33 AM > To: Andy Ringsmuth ; nanog at nanog.org > Subject: RE: Oct. 3, 2018 EAS Presidential Alert test > > I got 1:19 and 1:21 (att then siruis) > > > -----Original Message----- > From: NANOG On Behalf Of Andy Ringsmuth > Sent: Wednesday, October 03, 2018 2:53 PM > To: nanog at nanog.org > Subject: Oct. 3, 2018 EAS Presidential Alert test > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > From maxh at maxh.me.uk Wed Oct 3 21:03:58 2018 From: maxh at maxh.me.uk (Max Harmony) Date: Wed, 3 Oct 2018 17:03:58 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: I got it, but not until 14.34. For a system that's supposed to be able to warn people of incoming nuclear attack, that seems unacceptably slow. Ar Mer, 3 Hyd 2018 am 14:52 Andy Ringsmuth ysgrifennodd: > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > From woody at pch.net Wed Oct 3 21:16:46 2018 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 Oct 2018 14:16:46 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <8EA39434-AB3C-4BFB-97BF-A883D60B5F83@pch.net> Received at roughly 12:15 Pacific time, AT&T / IOS / Berkeley CA. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From surfer at mauigateway.com Wed Oct 3 21:22:42 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 3 Oct 2018 14:22:42 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test Message-ID: <20181003142242.30BE419E@m0117458.ppops.net> --- andy at andyring.com wrote: From: Andy Ringsmuth Interesting. That seems to be a gigantic hole in this entire process. ------------------------------------------------- Surprising given it's a gov't process. Because, you know, those always go really well. ;) :: A dedicated mailbox has been created for all questions :: relating to the IPAWS National Test. Please e-mail us :: at FEMA-National-Test at fema.dhs.gov. I'm sure that will go well, too. No doubt... scott From davidpeahi at gmail.com Wed Oct 3 21:45:13 2018 From: davidpeahi at gmail.com (david peahi) Date: Wed, 3 Oct 2018 14:45:13 -0700 Subject: Possible Comcast Packet Loss Between Atlanta and Chandler, Az Message-ID: I suspect random packet loss between an Xfinity (Comcast) cable modem user in Atlanta, and our Chandler, Az data center. Traceroute between the Atlanta user and Chandler shows Comcast/TW backbone handing off to Abovenet/Zayo, finally to Internap for local loop connection. Can anyone verify this? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From fearghas at gmail.com Wed Oct 3 21:45:46 2018 From: fearghas at gmail.com (Fearghas Mckay) Date: Wed, 3 Oct 2018 17:45:46 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: > On 3 Oct 2018, at 14:52, Andy Ringsmuth wrote: > > Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. Got it on an iPhone using Project Fi at 2:18 on the dot in southern MA. BTW the list member who was complaining about spamming the list - can I suggest you investigate procmail to solve your perceived problem on topics you are not interested in ? f From surfer at mauigateway.com Wed Oct 3 21:51:11 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 3 Oct 2018 14:51:11 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test Message-ID: <20181003145111.30BE4020@m0117458.ppops.net> --- maxh at maxh.me.uk wrote: From: Max Harmony I got it, but not until 14.34. For a system that's supposed to be able to warn people of incoming nuclear attack, that seems unacceptably slow. ----------------------------------------------- You mean like the one we got in Hawaii? https://en.wikipedia.org/wiki/2018_Hawaii_false_missile_alert "BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL." Parents were putting their children into storm drains... scott From valdis.kletnieks at vt.edu Wed Oct 3 22:14:40 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 03 Oct 2018 18:14:40 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> Message-ID: <97649.1538604880@turing-police.cc.vt.edu> On Wed, 03 Oct 2018 12:53:57 -0700, mike.lyon at gmail.com said: > Interesting question though... I wonder if people on micro-cells and/or wifi > calling don���t get the alerts. That would be extremely dumb and irresponsible of > the cell phone carriers, so its likely the case :) Oddball corner case - I'm at home taking a sick day, and my Moto X4 on Project Fi *did* receive the alert text right at 2:18 but did *not* trigger the amazingly loud and annoying alert tone. Phone says it's set for wifi calling, but has a tower in sight too. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From sean at donelan.com Wed Oct 3 22:18:42 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 3 Oct 2018 18:18:42 -0400 (EDT) Subject: Where to send feedback on the nationwide EAS-WEA tests Message-ID: FEMA invites the public to send comments on the nationwide EAS-WEA test to FEMA-National-Test at fema.dhs.gov Valuable information on the effectiveness of a national WEA capability using the Presidential alert category includes: 1. Whether your mobile device displayed one, more or no WEA test messages; 2. The make, model and operating system version of your mobile device; 3. Your wireless service provider; 4. Whether the device was turned on and in the same location for at least 30 minutes after the start of the test (2:18 p.m. ET); 5. The location of the device (as precise as possible), including the device’s environment (e.g. indoors or outdoors, rural or urban, mobile or stationary); 6. Whether you are normally able to make calls, receive texts, or use apps at that location; 7. Whether the mobile device was in use at the time of the alert (for a call or a data session); and 8. Whether anyone else at your location received the WEA test alert message. From mattlists at rivervalleyinternet.net Wed Oct 3 22:29:04 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Wed, 3 Oct 2018 18:29:04 -0400 Subject: Where to send feedback on the nationwide EAS-WEA tests In-Reply-To: References: Message-ID: Yup. All 300 of us received it and our phones started reading the message uncontrollably. Utter chaos. > On Oct 3, 2018, at 18:18, Sean Donelan wrote: > > > FEMA invites the public to send comments on the nationwide EAS-WEA test to > > FEMA-National-Test at fema.dhs.gov > > Valuable information on the effectiveness of a national WEA capability using the Presidential alert category includes: > > 1. Whether your mobile device displayed one, more or no WEA test messages; > > 2. The make, model and operating system version of your mobile device; > > 3. Your wireless service provider; > > 4. Whether the device was turned on and in the same location for at least 30 minutes after the start of the test (2:18 p.m. ET); > > 5. The location of the device (as precise as possible), including the device’s environment (e.g. indoors or outdoors, rural or urban, mobile or stationary); > > 6. Whether you are normally able to make calls, receive texts, or use apps at that location; > > 7. Whether the mobile device was in use at the time of the alert (for a call or a data session); and > > 8. Whether anyone else at your location received the WEA test alert message. From james.voip at gmail.com Thu Oct 4 00:31:15 2018 From: james.voip at gmail.com (james jones) Date: Wed, 3 Oct 2018 20:31:15 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <97649.1538604880@turing-police.cc.vt.edu> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> <97649.1538604880@turing-police.cc.vt.edu> Message-ID: i got it iPhone X on Xfinity Mobile On Wed, Oct 3, 2018 at 6:16 PM wrote: > On Wed, 03 Oct 2018 12:53:57 -0700, mike.lyon at gmail.com said: > > > Interesting question though... I wonder if people on micro-cells and/or > wifi > > calling don’t get the alerts. That would be extremely dumb and > irresponsible of > > the cell phone carriers, so its likely the case :) > > Oddball corner case - I'm at home taking a sick day, and my Moto X4 on > Project > Fi *did* receive the alert text right at 2:18 but did *not* trigger the > amazingly loud and > annoying alert tone. Phone says it's set for wifi calling, but has a tower > in > sight too. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayw at rayw.net Thu Oct 4 00:34:27 2018 From: rayw at rayw.net (Ray Wong) Date: Wed, 3 Oct 2018 17:34:27 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <122e01d45b4e$936910a0$ba3b31e0$@com> <97649.1538604880@turing-police.cc.vt.edu> Message-ID: received 11:18am PDT T-Mobile SF bay area. On Wed, Oct 3, 2018 at 5:32 PM james jones wrote: > i got it iPhone X on Xfinity Mobile > > On Wed, Oct 3, 2018 at 6:16 PM wrote: > >> On Wed, 03 Oct 2018 12:53:57 -0700, mike.lyon at gmail.com said: >> >> > Interesting question though... I wonder if people on micro-cells and/or >> wifi >> > calling don’t get the alerts. That would be extremely dumb and >> irresponsible of >> > the cell phone carriers, so its likely the case :) >> >> Oddball corner case - I'm at home taking a sick day, and my Moto X4 on >> Project >> Fi *did* receive the alert text right at 2:18 but did *not* trigger the >> amazingly loud and >> annoying alert tone. Phone says it's set for wifi calling, but has a >> tower in >> sight too. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From techzone at greeleynet.com Thu Oct 4 00:58:55 2018 From: techzone at greeleynet.com (F.L. Whiteley) Date: Wed, 3 Oct 2018 18:58:55 -0600 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <067b01d45b7d$6d748760$485d9620$@greeleynet.com> Received on 2x VZW/Androids in Greeley, CO, :18 MDT, via radio :21. Frank Whiteley GreeleyNet Online 970-330-2050 techzone at greeleynet.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andy Ringsmuth Sent: Wednesday, October 03, 2018 12:53 PM To: nanog at nanog.org Subject: Oct. 3, 2018 EAS Presidential Alert test Did anyone on AT&T or an iPhone receive the test today? I believe it was supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 EDT. I’m in CDT, so 1:18 and 1:20 p.m. CDT. Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T iPhones and not a single one of them alerted. FEMA says https://www.fema.gov/emergency-alert-test "Cell towers will broadcast the WEA test for approximately 30 minutes beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that are switched on, within range of an active cell tower, and whose wireless provider participates in WEA should be capable of receiving the test message. Some cell phones will not receive the test message, and cell phones should only receive the message once." My wife, with a Sprint iPhone, received the test. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From ross at tajvar.io Thu Oct 4 14:57:25 2018 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 4 Oct 2018 10:57:25 -0400 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: Thanks everyone who replied. I got many responses off-list, including a lot of positive endorsements for several different vendors. It's good to know there are so many reputable options. -Ross On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar wrote: > Hi all, > > My US-based employer will be starting a new business unit soon that will > require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a > waitlist (though I'm not sure where they're getting new IPs from), but the > faster way is to buy blocks from people who already have them. I'm aware of > Hilco Streambank - are there any other auctions? If I want to buy via > private sale, does anyone know of ways to find sellers? > > Thanks, > Ross > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Thu Oct 4 16:19:42 2018 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 4 Oct 2018 12:19:42 -0400 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: I'm rolling my eyes. We'll be using IPv6, but obviously we need IPv4 too. On Thu, Oct 4, 2018, 12:00 PM John Lee wrote: > If is a new US business and you are working internationally why not go > simple and use IPv6 addresses? > > John Lee > > On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar wrote: > >> Thanks everyone who replied. I got many responses off-list, including a >> lot of positive endorsements for several different vendors. It's good to >> know there are so many reputable options. >> >> -Ross >> >> On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar wrote: >> >>> Hi all, >>> >>> My US-based employer will be starting a new business unit soon that will >>> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a >>> waitlist (though I'm not sure where they're getting new IPs from), but the >>> faster way is to buy blocks from people who already have them. I'm aware of >>> Hilco Streambank - are there any other auctions? If I want to buy via >>> private sale, does anyone know of ways to find sellers? >>> >>> Thanks, >>> Ross >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Oct 4 16:27:36 2018 From: matt at netfire.net (Matt Harris) Date: Thu, 4 Oct 2018 11:27:36 -0500 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: On Thu, Oct 4, 2018 at 11:20 AM Ross Tajvar wrote: > I'm rolling my eyes. We'll be using IPv6, but obviously we need IPv4 too. > > On Thu, Oct 4, 2018, 12:00 PM John Lee wrote: > >> If is a new US business and you are working internationally why not go >> simple and use IPv6 addresses? >> >> John Lee >> > What do you mean you want to be able to reach and be reachable by more than 20% of the internet? I'm all for IPv6 deployment and I go so far as to push it onto customers (and configure things correctly so that they have a good IPv6 experience) who otherwise wouldn't even know anything about it or care at all, but to pretend that one can subsist without at least some IPv4 space to facilitate translation at this stage is just unrealistic. - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Oct 4 17:01:33 2018 From: randy at psg.com (Randy Bush) Date: Thu, 04 Oct 2018 10:01:33 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: re: https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies from a side convo with a well known sec researcher: >> saw that a couple of years back when apple tossed them out. so who >> do we know that is for sure not poisoned. and therein lies the rub. > Yup truth is, i am surprised they had to add a chip, and one of the larger dies was not already trojaned. have visions of the chinese implant on box A fighting with the american implant on box B with occasional jabs from the israelis from box C. what i would love to see/know is how apple tries to vet the macs made in shenzhen. randy From matlockken at gmail.com Thu Oct 4 17:41:57 2018 From: matlockken at gmail.com (Ken Matlock) Date: Thu, 4 Oct 2018 11:41:57 -0600 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: Message-ID: Would be remiss in our duties if we didn't also link AWS' blog, in response to the Bloomberg article. In short, AWS refutes many of Bloomberg's reporting in the article. https://aws.amazon.com/blogs/security/setting-the-record-straight-on-bloomberg-businessweeks-erroneous-article/ Ken On Thu, Oct 4, 2018 at 11:03 AM Randy Bush wrote: > re: > https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies > > from a side convo with a well known sec researcher: > > >> saw that a couple of years back when apple tossed them out. so who > >> do we know that is for sure not poisoned. and therein lies the rub. > > Yup > > truth is, i am surprised they had to add a chip, and one of the larger > dies was not already trojaned. > > have visions of the chinese implant on box A fighting with the american > implant on box B with occasional jabs from the israelis from box C. > > what i would love to see/know is how apple tries to vet the macs made in > shenzhen. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Thu Oct 4 18:52:34 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Oct 2018 11:52:34 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181004115234.30BE326B@m0117458.ppops.net> --- matlockken at gmail.com wrote: From: Ken Matlock Would be remiss in our duties if we didn't also link AWS' blog, in response to the Bloomberg article. -------------------------------------------------- Every company and the Chinese gov't is saying "no, Bloomberg is wrong": https://www.bloomberg.com/news/articles/2018-10-04/the-big-hack-amazon-apple-supermicro-and-beijing-respond Can't wait to see how this evolves... scott From denys at visp.net.lb Thu Oct 4 19:07:31 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Thu, 04 Oct 2018 22:07:31 +0300 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181004115234.30BE326B@m0117458.ppops.net> References: <20181004115234.30BE326B@m0117458.ppops.net> Message-ID: <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> On 2018-10-04 21:52, Scott Weeks wrote: > --- matlockken at gmail.com wrote: > From: Ken Matlock > > Would be remiss in our duties if we didn't also link > AWS' blog, in response to the Bloomberg article. > -------------------------------------------------- > > > Every company and the Chinese gov't is saying "no, > Bloomberg is wrong": > > https://www.bloomberg.com/news/articles/2018-10-04/the-big-hack-amazon-apple-supermicro-and-beijing-respond > > Can't wait to see how this evolves... > > scott It would be better for them(AMZN, SMCI, AAPL) to prove that these events did not take place - in court. In the opposite case, even if this article is full of inaccuracies, judging by the discussions of security specialists, the scenario indicated in the article is quite possible. Unpopulated SOIC-8 near populated SOIC-16 flash for BMC firmware is sweet spot for custom MCU - snooping on flash SPI(most likely) bus and probably altering some data. At the same time there will be a good precedent, if this article is fabricated - such journalists need to be taught a lesson. And if they wont go to the court, there is something to think about. From brandon at burn.net Thu Oct 4 19:07:49 2018 From: brandon at burn.net (Brandon Applegate) Date: Thu, 4 Oct 2018 15:07:49 -0400 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? Message-ID: Hello, I’ve seen mention on this list and other places about keeping one’s PTPs / loopbacks out of routing tables for security reasons. Totally get this and am on board with it. What I don’t get - is how. I’m going to list some of my ideas below and the pros/cons/problems (that I can think of at least) for them. - RFC 1918 for loopbacks and PTP - Immediately “protects” from the internet at large, as they aren’t routable. - Traceroutes are miserable. - Use public block that is allocated to you (i.e. PI) - but not announced. - So would this be a totally separate (from user/customer prefixes) announcement and allocation ? In other words, let’s say you were a small ISP getting started. You manage to get a /20 from a broker (IPv6 should be “easy”). Do you also now go out and get a /23 (I’m making these sizes up, obviously all of these will vary based on ISP size, growth plan, etc.). You have the /23 registered to you (with proper rDNS delegation, WHOIS, etc.). But you simply don’t announce it ? I’d say I need this /23 day one to even build my network before it’s ready for customers. - On the IPv6 front - would a RIR give you your /32 and then also a /48 (for loop/PTP) ? - Deaggregate and not announce your infra - Bad net behavior out of the gate with this method. The opposite of elegant. - Keeping with previously made up / arbitrary prefixes - for your /20 - you’d end up announcing 2 x /23, 1 x /22 and 1 x /21. I’m too lazy to enumerate the IPv6 gymnastics, but with IPv6 you could “waste” a bit more to get to boundaries that are a bit easier to work with I suppose. Thanks in advance for insights on this. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible." From petrus.lt at gmail.com Thu Oct 4 19:17:45 2018 From: petrus.lt at gmail.com (Pierre Emeriaud) Date: Thu, 4 Oct 2018 21:17:45 +0200 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: Le jeu. 4 oct. 2018 à 21:12, Brandon Applegate a écrit : > > I’ve seen mention on this list and other places about keeping one’s PTPs / loopbacks out of routing tables for security reasons. Totally get this and am on board with it. What I don’t get - is how. I’m going to list some of my ideas below and the pros/cons/problems (that I can think of at least) for them. > - Use public block that is allocated to you (i.e. PI) - but not announced. this is what we do. We are lucky enough to have plenty of address space which was quite correctly assigned in the first place. This is nice, except for one thing: other networks having urpf towards us. It makes traceroutes from their side to ours useless. Other than that, we use bgpmon to monitor for the absence of advertisements /leaks for those internal prefixes. Works really well. From bill at herrin.us Thu Oct 4 19:26:15 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2018 15:26:15 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> Message-ID: On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko wrote: > It would be better for them(AMZN, SMCI, AAPL) to prove that these > events did not take place - in court. "Can't prove a negative." > In the opposite case, even if this article is full of inaccuracies, > judging by the discussions of security specialists, the scenario > indicated in the article is quite possible. The Bloomberg article described them as looking like 'signal conditioning couplers" on the motherboard. There is no such part on server boards but maybe they meant optoisolators or power conditioning capacitors. The former is a hard place to tweak the BMC from without a high probability of crashing it. The latter doesn't touch the data lines at all. They also quoted someone describing such a hack as being "like witnessing a unicorn jumping over a rainbow." I agree. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From valdis.kletnieks at vt.edu Thu Oct 4 19:31:29 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Oct 2018 15:31:29 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> Message-ID: <16850.1538681489@turing-police.cc.vt.edu> On Thu, 04 Oct 2018 15:26:15 -0400, William Herrin said: > The Bloomberg article described them as looking like 'signal > conditioning couplers" on the motherboard. There is no such part on > server boards but maybe they meant optoisolators or power conditioning > capacitors. You overlook the obvious case - that it *looks* like Yet Another Filter Cap but it's actually a microcontroller wired into a useful SPI bus.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From jason+nanog at lixfeld.ca Thu Oct 4 19:44:21 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 4 Oct 2018 15:44:21 -0400 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: <4BDEC833-C45D-48AC-B363-062776A86161@lixfeld.ca> > On Oct 4, 2018, at 3:07 PM, Brandon Applegate wrote: > > Thanks in advance for insights on this. If you’re MPLS enabled, one implementation could see place the loop/infra/p2p in the global table and customer/internet traffic inside a VRF. From david.g.cooke at baesystems.com Wed Oct 3 21:36:15 2018 From: david.g.cooke at baesystems.com (Cooke, David) Date: Wed, 3 Oct 2018 21:36:15 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <8EA39434-AB3C-4BFB-97BF-A883D60B5F83@pch.net> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <8EA39434-AB3C-4BFB-97BF-A883D60B5F83@pch.net> Message-ID: Not received here but the BBC did apparently... https://www.bbc.com/news/technology-45730367 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bill Woodcock Sent: Wednesday, October 03, 2018 5:17 PM To: nanog at nanog.org list Subject: Re: Oct. 3, 2018 EAS Presidential Alert test Received at roughly 12:15 Pacific time, AT&T / IOS / Berkeley CA. -Bill BAE Systems will collect and process information about you that may be subject to data protection laws. For more information about how we use and disclose your personal information, how we protect your information, our legal basis to use your information, your rights and who you can contact, please refer to the relevant sections of our Privacy note at www.baesystems.com/en/cybersecurity/privacy Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies under the control of BAE Systems PLC, details of which can be found at http://www.baesystems.com/Businesses/index.htm. From dan at tangledhelix.com Wed Oct 3 23:48:34 2018 From: dan at tangledhelix.com (Dan Lowe) Date: Wed, 03 Oct 2018 19:48:34 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> Message-ID: <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> My wife and I, both on AT&T iPhones in the greater Cleveland area, received nothing. A co-worker of mine in Virginia got an alert, another in Texas did not. I believe the co-workers are both on AT&T. I can't speak for the co-workers, but my wife and I do not have wifi calling enabled. Dan On Wed, Oct 3, 2018, at 2:52 PM, Andy Ringsmuth wrote: > Did anyone on AT&T or an iPhone receive the test today? I believe it was > supposed to happen at 2:18 EDT, followed by one on broadcast radio at > 2:20 EDT. > > I’m in CDT, so 1:18 and 1:20 p.m. CDT. > > Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the > sending of this at 1:52 p.m. CDT, nothing on phones. I have an office > full of AT&T iPhones and not a single one of them alerted. > > FEMA says https://www.fema.gov/emergency-alert-test > > "Cell towers will broadcast the WEA test for approximately 30 minutes > beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones > that are switched on, within range of an active cell tower, and whose > wireless provider participates in WEA should be capable of receiving the > test message. Some cell phones will not receive the test message, and > cell phones should only receive the message once." > > My wife, with a Sprint iPhone, received the test. > > > ---- > Andy Ringsmuth > 5609 Harding Drive > Lincoln, NE 68521-5831 > (402) 304-0083 > andy at andyring.com > From jllee9753 at gmail.com Thu Oct 4 16:00:33 2018 From: jllee9753 at gmail.com (John Lee) Date: Thu, 4 Oct 2018 12:00:33 -0400 Subject: Buying IPv4 blocks In-Reply-To: References: Message-ID: If is a new US business and you are working internationally why not go simple and use IPv6 addresses? John Lee On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar wrote: > Thanks everyone who replied. I got many responses off-list, including a > lot of positive endorsements for several different vendors. It's good to > know there are so many reputable options. > > -Ross > > On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar wrote: > >> Hi all, >> >> My US-based employer will be starting a new business unit soon that will >> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a >> waitlist (though I'm not sure where they're getting new IPs from), but the >> faster way is to buy blocks from people who already have them. I'm aware of >> Hilco Streambank - are there any other auctions? If I want to buy via >> private sale, does anyone know of ways to find sellers? >> >> Thanks, >> Ross >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Thu Oct 4 19:43:59 2018 From: markr at signal100.com (Mark Rousell) Date: Thu, 4 Oct 2018 20:43:59 +0100 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> Message-ID: <5BB66D7F.5020405@signal100.com> On 04/10/2018 20:26, William Herrin wrote: > On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko wrote: >> It would be better for them(AMZN, SMCI, AAPL) to prove that these >> events did not take place - in court. > "Can't prove a negative." You can in effect do so by suing for defamation. It's then up to the person who has made allegedly defamatory claims to prove their claims. If they can't prove their claims in court then the claims are, in effect, proven to be false. However, I'm not sure that Amazon, Apple or Supermicro have actually been defamed by the article in question. In other words, there could be nothing to sue for. The PLA and Chinese government would have been defamed (if the claims are untrue) but that's a different matter. Any lawyers wants to offer an opinion? > The Bloomberg article described them as looking like 'signal > conditioning couplers" on the motherboard. There is no such part on > server boards but maybe they meant optoisolators or power conditioning > capacitors. The former is a hard place to tweak the BMC from without a > high probability of crashing it. The latter doesn't touch the data > lines at all. The mystery object in the pictures in the article seemed to me to (sort of) resemble a surface mount power conditioning capacitor. Note that there was no suggestion that the mystery objects were connected in place of capacitors; the article merely claimed that they were visually disguised. They would obviously have to connect to data lines somewhere to do what is claimed. > They also quoted someone describing such a hack as being "like > witnessing a unicorn jumping over a rainbow." I agree. It doesn't seem so unreasonable to me. If true, this is not a matter of fitting the mystery components to random hardware and hoping that they go somewhere useful. Instead, these were specific models of hardware being manufactured for specific customers for use in specific locations/roles. In other words, it was near-guaranteed that the hardware (or at least some of it) would end up being used in a location that carried 'interesting' target data. As such, this would be, if true, an example of very carefully targetted espionage, not some random lucky miracle. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Oct 4 19:51:43 2018 From: matt at netfire.net (Matt Harris) Date: Thu, 4 Oct 2018 14:51:43 -0500 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> Message-ID: On Thu, Oct 4, 2018 at 2:26 PM William Herrin wrote: > On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko > wrote: > > It would be better for them(AMZN, SMCI, AAPL) to prove that these > > events did not take place - in court. > > "Can't prove a negative." > > > In the opposite case, even if this article is full of inaccuracies, > > judging by the discussions of security specialists, the scenario > > indicated in the article is quite possible. > > The Bloomberg article described them as looking like 'signal > conditioning couplers" on the motherboard. There is no such part on > server boards but maybe they meant optoisolators or power conditioning > capacitors. The former is a hard place to tweak the BMC from without a > high probability of crashing it. The latter doesn't touch the data > lines at all. > One wonders if, with the quality of BMC's in general being as low as it is, and their security as bad, if any sort of extraneous hardware is necessary to facilitate a compromise of a system where any of these BMCs is present. Keep in mind many of these devices for some time included a "feature" where telnet'ing to a specific port and typing in a short string would result in a response containing a cleartext list of usernames and cleartext passwords. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Oct 4 19:53:10 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2018 15:53:10 -0400 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: On Thu, Oct 4, 2018 at 3:10 PM Brandon Applegate wrote: > I’ve seen mention on this list and other places about keeping one’s PTPs / loopbacks out of routing tables for security reasons. Totally get this and am on board with it. What I don’t get - is how. I’m going to list some of my ideas below and the pros/cons/problems (that I can think of at least) for them. > > - RFC 1918 for loopbacks and PTP > - Immediately “protects” from the internet at large, as they aren’t routable. > - Traceroutes are miserable. Also breaks PMTUD which can break TCP for everybody whose packets transit your router. So don't do this. > - Use public block that is allocated to you (i.e. PI) - but not announced. This works. > - Deaggregate and not announce your infra Not great. Another option is to let it be announced but filter the packets at your border. I wonder if it would be useful to ask the IETF to assign a block of "origination-only" IP addresses... IP addresses which by standard are permitted to be the source of ICMP packets but which should be unreachable by forward routing. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From lathama at gmail.com Thu Oct 4 19:57:15 2018 From: lathama at gmail.com (Andrew Latham) Date: Thu, 4 Oct 2018 14:57:15 -0500 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: Message-ID: Supermicro's response at https://www.supermicro.com/newsroom/pressreleases/2018/press181004_Bloomberg.cfm On Thu, Oct 4, 2018 at 12:03 PM Randy Bush wrote: > re: > https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies > > from a side convo with a well known sec researcher: > > >> saw that a couple of years back when apple tossed them out. so who > >> do we know that is for sure not poisoned. and therein lies the rub. > > Yup > > truth is, i am surprised they had to add a chip, and one of the larger > dies was not already trojaned. > > have visions of the chinese implant on box A fighting with the american > implant on box B with occasional jabs from the israelis from box C. > > what i would love to see/know is how apple tries to vet the macs made in > shenzhen. > > randy > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl_gerh at gmx.at Thu Oct 4 19:59:44 2018 From: karl_gerh at gmx.at (Karl Gerhard) Date: Thu, 4 Oct 2018 21:59:44 +0200 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: <905e7c03-469b-4a09-02b9-c07cac36f128@gmx.at> Hello Brandon, instead of not announcing it you can send it to your upstream and tag it with no-export. That way you can still see your router in traceroutes if the source ASN of the traceroute doesn't do uRPF. If you don't have a separate range from which you assign PTP/loopback addresses, but your upstream offers a BGP blackhole community you can permanently blackhole your PTPs/loopbacks/infra at your upstream if you want to increase your security. Another way to keep your traceroutes pretty. However, if it's thousands of /32s then you should probably talk to your upstream before doing that. :) Regards Karl ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Brandon Applegate [mailto:brandon at burn.net] *Sent:* Thu, Oct 4, 2018 9:07 PM CEST *To:* NANOG mailing list *Subject:* Not announcing (to the greater internet) loopbacks/PTP/infra - how ? > Hello, > > I’ve seen mention on this list and other places about keeping one’s PTPs / loopbacks out of routing tables for security reasons. Totally get this and am on board with it. What I don’t get - is how. I’m going to list some of my ideas below and the pros/cons/problems (that I can think of at least) for them. > > - RFC 1918 for loopbacks and PTP > - Immediately “protects” from the internet at large, as they aren’t routable. > - Traceroutes are miserable. > > - Use public block that is allocated to you (i.e. PI) - but not announced. > - So would this be a totally separate (from user/customer prefixes) announcement and allocation ? In other words, let’s say you were a small ISP getting started. You manage to get a /20 from a broker (IPv6 should be “easy”). Do you also now go out and get a /23 (I’m making these sizes up, obviously all of these will vary based on ISP size, growth plan, etc.). You have the /23 registered to you (with proper rDNS delegation, WHOIS, etc.). But you simply don’t announce it ? I’d say I need this /23 day one to even build my network before it’s ready for customers. > - On the IPv6 front - would a RIR give you your /32 and then also a /48 (for loop/PTP) ? > > - Deaggregate and not announce your infra > - Bad net behavior out of the gate with this method. The opposite of elegant. > - Keeping with previously made up / arbitrary prefixes - for your /20 - you’d end up announcing 2 x /23, 1 x /22 and 1 x /21. I’m too lazy to enumerate the IPv6 gymnastics, but with IPv6 you could “waste” a bit more to get to boundaries that are a bit easier to work with I suppose. > > Thanks in advance for insights on this. > > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A > "For thousands of years men dreamed of pacts with demons. > Only now are such things possible." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu Oct 4 20:02:34 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 4 Oct 2018 16:02:34 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> Message-ID: Since I know network engineers are geeks, and can't stop themselves from looking... On your iPhone (and android, and likely other cell phone OS), there are detailed diagnostics logs. On your iPhone, look under Settings->Privacy->Analytics->Analytics Data->awdd- "awdd" means Apple Wireless Diagnostic Data. In my iOS awdd file for October 3,there was something like this: metriclogs { triggerTime: 1538590702067 triggerId: 524356 profileId: 174 commCenterGSMCellBroadcastEvent { timestamp: 1538590702066 message_id: 4370 message_code: 0 update_number: 0 emergency_user_alert: false } } The trigger time is local time in milliseconds. That means my phone got the cell broadcast at Wed Oct 03 2018 14:18:22, and displayed/alerted on the phone 1 millisecond later. Its usually a big file, so you'll need to scroll a long way. The entries are in triggerTime order, which is the date/time, will help narrow down where in the file. That is the diagnostic data about the WEA Presidential Alert cell broadcast message. The message_id 4370 is the GSM code for CMAS Alert type Presidential. An Amber alert is code 4379 and other codes exist for other messages. If you didn't get an alert, you can look in the diagnostic file around that time for other things which might have prevented receiving an alert, e.g. no receiption, voice call in progress, roaming on carrier without WEA, etc. In theory, Apple (iOS) and Alphabet (Android), and other manufacturers, which collect diagnostic data analytics on handsets could create a nationwide report how well WEA performed based on actual data instead of anedoctal reports. From johnl at iecc.com Thu Oct 4 20:07:47 2018 From: johnl at iecc.com (John Levine) Date: 4 Oct 2018 16:07:47 -0400 Subject: Buying IPv4 blocks In-Reply-To: Message-ID: <20181004200748.74E6220069D340@ary.qy> In article you write: > >If is a new US business and you are working internationally why not go >simple and use IPv6 addresses? Just a guess, but it's probably because they would like for the large fraction of the net that is still v4 only to be able to contact them. Even if you do have v6, some things like DNSSEC don't work very well if you can't do them over v4. From nick at foobar.org Thu Oct 4 20:08:11 2018 From: nick at foobar.org (Nick Hilliard) Date: Thu, 4 Oct 2018 21:08:11 +0100 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: William Herrin wrote on 04/10/2018 20:53: > I wonder if it would be useful to ask the IETF to assign a block of > "origination-only" IP addresses... IP addresses which by standard are > permitted to be the source of ICMP packets but which should be > unreachable by forward routing. no - this would be abused for ddos. Nick From bill at herrin.us Thu Oct 4 20:10:45 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2018 16:10:45 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <5BB66D7F.5020405@signal100.com> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> Message-ID: On Thu, Oct 4, 2018 at 3:57 PM Mark Rousell wrote: > The mystery object in the pictures in the article seemed to me > to (sort of) resemble a surface mount power conditioning > capacitor. Though Bloomberg didn't go out of their way to say it, the photos were "representative" of the chip supposedly found. Were they in possession of any hard evidence of the chips' existence, they'd have said so. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mdavids at forfun.net Thu Oct 4 20:25:56 2018 From: mdavids at forfun.net (Marco Davids) Date: Thu, 4 Oct 2018 22:25:56 +0200 Subject: Buying IPv4 blocks In-Reply-To: <20181004200748.74E6220069D340@ary.qy> References: <20181004200748.74E6220069D340@ary.qy> Message-ID: <60afb948-5f6d-8ea8-00c9-6d4d92ff0269@forfun.net> Op 04-10-18 om 22:07 schreef John Levine: > Even if you do have v6, some things like DNSSEC don't work very well > if you can't do them over v4. Is that so? -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From SNaslund at medline.com Thu Oct 4 20:37:38 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 20:37:38 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> I was wondering about where this chip tapped into all of the data and timing lines it would need to have access to. It would seem that being really small creates even more problems making those connections. I am a little doubtful about the article. It would seem to me better to create a corrupted copy of something like a front side bus chipset, memory controller or some other component that handles data lines than create a new component that would then require a motherboard redesign to integrate correctly. It would seem that as soon as the motherboard design was changed someone would wonder "hey, where are all those data lines going?" It would also require less people in on the plan to corrupt or replace a device already in the design. All you need is a way to intercept the original chip supply and insert your rogue devices. On the opposite side of the argument, does anyone think it is strange that all of the companies mentioned in the article along with the PRC managed to get a simultaneous response back to Bloomberg. Seems pretty pre-calculated to me. Or did some agency somewhere tell everyone they better shut up about the whole thing? Steven Naslund Chicago IL >Though Bloomberg didn't go out of their way to say it, the photos were >"representative" of the chip supposedly found. Were they in possession >of any hard evidence of the chips' existence, they'd have said so. > >Regards, >Bill Herrin From denys at visp.net.lb Thu Oct 4 20:46:00 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Thu, 04 Oct 2018 23:46:00 +0300 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> Message-ID: <9347eb12cd1330c3c91576a09f740f96@visp.net.lb> On 2018-10-04 23:37, Naslund, Steve wrote: > I was wondering about where this chip tapped into all of the data and > timing lines it would need to have access to. It would seem that > being really small creates even more problems making those > connections. I am a little doubtful about the article. It would seem > to me better to create a corrupted copy of something like a front side > bus chipset, memory controller or some other component that handles > data lines than create a new component that would then require a > motherboard redesign to integrate correctly. It would seem that as > soon as the motherboard design was changed someone would wonder "hey, > where are all those data lines going?" It would also require less > people in on the plan to corrupt or replace a device already in the > design. All you need is a way to intercept the original chip supply > and insert your rogue devices. > > On the opposite side of the argument, does anyone think it is strange > that all of the companies mentioned in the article along with the PRC > managed to get a simultaneous response back to Bloomberg. Seems > pretty pre-calculated to me. Or did some agency somewhere tell > everyone they better shut up about the whole thing? > > Steven Naslund > Chicago IL > > Just theory - tapping on same lines as SPI flash (let's assume it is not QSPI), so we are "in parallel", as "snooper" chip. First - it can easily snoop by listening MISO/MOSI/CS/CLK. When required data pattern and block detected during snooping, it can remember offset(s) of required data. When, later, BMC send over MOSI request for this "offset", we override BMC and force CS high (inactive), so main flash chip will not answer, and answer instead of him our, different data from "snooper". Voila... instead of root:password we get root:nihao From bill at herrin.us Thu Oct 4 20:59:47 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2018 16:59:47 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> Message-ID: On Thu, Oct 4, 2018 at 4:37 PM Naslund, Steve wrote: > On the opposite side of the argument, does anyone think it is strange that all of > the companies mentioned in the article along with the PRC managed to get a > simultaneous response back to Bloomberg. Seems pretty pre-calculated to > me. Or did some agency somewhere tell everyone they better shut up > about the whole thing? As they mentioned in their responses, Bloomberg has been calling each of the companies for comment on the developing article for months to a year. That's why they all knew it was coming. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Thu Oct 4 21:00:57 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 21:00:57 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9347eb12cd1330c3c91576a09f740f96@visp.net.lb> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> <9347eb12cd1330c3c91576a09f740f96@visp.net.lb> Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192BB2@MUNPRDMBXA1.medline.com> It is definitely more desirable to try and tap a serialized data line than the parallel lines. The thing that made me most suspicious of the article is why would anyone add a chip. It requires power and connections that a highly detectable. Motherboard designs are very complex in the characteristics of data buses so it is not so easy to just extend or tap into them without having negative effects (which brings the board under scrutiny that we don't want). Why not embed our rogue chip inside the case of a chip that is already controlling the bus or memory we want to play with? It would be really hard to detect without x-ray of all of the system chipsets. The other thing I am highly skeptical of is the suggestion of attempting to tap sensitive intel agency systems this way. Talking to a C&C server is suicide from within their network. How long do you think it would take them to detect a reach out to the Internet from inside? How are you going to get the data from the outside back into their network? You still have to defeat their firewalls to do it. If this was targeted to specialized video processing server then would it not be unusual for them to be talking to some random IP address on the Internet? Steven Naslund Chicago IL >Just theory - tapping on same lines as SPI flash (let's assume it is not >QSPI), so we are "in parallel", as "snooper" chip. >First - it can easily snoop by listening MISO/MOSI/CS/CLK. >When required data pattern and block detected during snooping, it can >remember offset(s) of required data. >When, later, BMC send over MOSI request for this "offset", we override >BMC and force CS high (inactive), so main flash chip will not answer, >and answer instead of him our, different data from "snooper". >Voila... instead of root:password we get root:nihao From eric.kuhnke at gmail.com Thu Oct 4 21:03:59 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 4 Oct 2018 14:03:59 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: Message-ID: To me this looks like a Chinese version of the NSA FIREWALK product. Which is a network implant built into a RJ45 jack intended to be soldered onto a motherboard. The FIREWALK info came out with the Snowden leaks in 2013 and the tech was years old at that time. https://en.wikipedia.org/wiki/NSA_ANT_catalog I am not able to say a lot more, but when I worked for a major defence contractor in 2006-2007 in Afghanistan, building WAN links in and out of the country by satellite, hardware implants were found in equipment. Not our equipment, but it was close enough to our operations that we were briefed on it and made aware. On Thu, Oct 4, 2018 at 10:02 AM Randy Bush wrote: > re: > https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies > > from a side convo with a well known sec researcher: > > >> saw that a couple of years back when apple tossed them out. so who > >> do we know that is for sure not poisoned. and therein lies the rub. > > Yup > > truth is, i am surprised they had to add a chip, and one of the larger > dies was not already trojaned. > > have visions of the chinese implant on box A fighting with the american > implant on box B with occasional jabs from the israelis from box C. > > what i would love to see/know is how apple tries to vet the macs made in > shenzhen. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Thu Oct 4 21:04:28 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 21:04:28 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192BC3@MUNPRDMBXA1.medline.com> I can read but I am really finding it hard to believe that they all agreed to even comment on it at all. Especially the PRC. Next question would be that if Bloomberg was calling me for "months to a year" why not get out in front of it in the first place? The whole story and its responses are very flakey at least to my BS detector. Steven Naslund Chicago IL >As they mentioned in their responses, Bloomberg has been calling each >of the companies for comment on the developing article for months to a >year. That's why they all knew it was coming. > >Regards, >Bill Herrin From randy at psg.com Thu Oct 4 21:09:59 2018 From: randy at psg.com (Randy Bush) Date: Thu, 04 Oct 2018 14:09:59 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: Message-ID: > To me this looks like a Chinese version of the NSA FIREWALK product. so the good thing about the trade war with china is that it keeps implant designers fully employed on both sides. they can't just buy eachother's implants; the tariffs would be too high. randy From surfer at mauigateway.com Thu Oct 4 21:10:07 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Oct 2018 14:10:07 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181004141007.30BE01A8@m0117458.ppops.net> --- SNaslund at medline.com wrote: From: "Naslund, Steve" The other thing I am highly skeptical of is the suggestion of attempting to tap sensitive intel agency systems this way. Talking to a C&C server is suicide from within their network. ---------------------------------------------------------- Classified networks do not connect to other networks unless they are equally or higher classified. No internet connection. Period. scott From valdis.kletnieks at vt.edu Thu Oct 4 21:14:12 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Oct 2018 17:14:12 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B402FD192BB2@MUNPRDMBXA1.medline.com> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> <9347eb12cd1330c3c91576a09f740f96@visp.net.lb> <9578293AE169674F9A048B2BC9A081B402FD192BB2@MUNPRDMBXA1.medline.com> Message-ID: <26158.1538687652@turing-police.cc.vt.edu> On Thu, 04 Oct 2018 21:00:57 -0000, "Naslund, Steve" said: > The other thing I am highly skeptical of is the suggestion of attempting to > tap sensitive intel agency systems this way. Talking to a C&C server is > suicide from within their network. How long do you think it would take them to > detect a reach out to the Internet from inside? Oh, at least 2 or 3 years. Or that's how long it took to be noticed the *last* time. https://en.wikipedia.org/wiki/Titan_Rain -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From eric.kuhnke at gmail.com Thu Oct 4 21:24:25 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 4 Oct 2018 14:24:25 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <26158.1538687652@turing-police.cc.vt.edu> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> <9347eb12cd1330c3c91576a09f740f96@visp.net.lb> <9578293AE169674F9A048B2BC9A081B402FD192BB2@MUNPRDMBXA1.medline.com> <26158.1538687652@turing-police.cc.vt.edu> Message-ID: The US' extensive reliance on third party commercial contractors to implement a lot of programs, means that despite laws and SOW/PWS for their contracts, many contractors *do* have sensitive data on their networks with a gateway out to the public Internet. I have seen it. I have cringed at it. SIGINT agencies in many cases rely on people being less than perfectly reliable in their data hygiene practices to extract useful information. I'm sure that all of the super secret squirrel stuff is going on properly inside SCIFs, but mistakes will be made. Now draw an imaginary venn diagram overlap of human mistakes with places that handle classified data. On Thu, Oct 4, 2018 at 2:21 PM wrote: > On Thu, 04 Oct 2018 21:00:57 -0000, "Naslund, Steve" said: > > The other thing I am highly skeptical of is the suggestion of attempting > to > > tap sensitive intel agency systems this way. Talking to a C&C server is > > suicide from within their network. How long do you think it would take > them to > > detect a reach out to the Internet from inside? > > Oh, at least 2 or 3 years. Or that's how long it took to be noticed the > *last* time. > > https://en.wikipedia.org/wiki/Titan_Rain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu Oct 4 21:24:43 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 04 Oct 2018 17:24:43 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181004141007.30BE01A8@m0117458.ppops.net> References: <20181004141007.30BE01A8@m0117458.ppops.net> Message-ID: <27464.1538688283@turing-police.cc.vt.edu> On Thu, 04 Oct 2018 14:10:07 -0700, "Scott Weeks" said: > Classified networks do not connect to other networks unless > they are equally or higher classified. No internet connection. > Period. Well, if your classified network is connecting to a higher classified net, then *that* network is connecting to a lower classified net, right? That, plus I think the Snowden escapade was ample proof that security rules will get bent when needed to get work done - it turned out that Snowden was able to walk off with terabytes of data because security restrictions had been disabled because they were putting a crimp in the analysts' style... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From randy at psg.com Thu Oct 4 21:24:58 2018 From: randy at psg.com (Randy Bush) Date: Thu, 04 Oct 2018 14:24:58 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181004141007.30BE01A8@m0117458.ppops.net> References: <20181004141007.30BE01A8@m0117458.ppops.net> Message-ID: > Classified networks do not connect to other networks unless > they are equally or higher classified. that sentence makes no sense. if A can connect to B because B is more highly classified than A, then B is connecting to a less classified network A. randy From SNaslund at medline.com Thu Oct 4 21:28:47 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 21:28:47 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192C16@MUNPRDMBXA1.medline.com> Quite different really. FIREWALK is really an intercept device to get data out of a firewalled or air gapped network. The exploit Bloomberg describes would modify or alter data going across a server’s bus. The big difference is the Bloomberg device needs command and control and a place to dump the tapped data to over the server’s network connection. That device is not going to be able to do so out of any classified military network I have ever worked on. Or anyone with a halfway decent firewall (which I would assume Apple and Amazon would have for the internal servers). I think this article is unlikely to be true for the following reasons : 1. Separate chip is much more detectable physically than an altered chipset that is already on the board. 2. Requires motherboard redesign to get access to power and buses needed (again easily detectable during any design mods “hey does anyone know what these are for?”) 3. Does not have onboard communications so it will be sending data traffic on the network interfaces (will definitely trigger even the most rudimentary IDP systems). It relies on these backbone Internet companies and Intelligence agencies to have absolutely abysmal security on their networks to be at all useful. 4. Parts would have to be brought into the plant, stored somewhere, and all the internal systems would need a trail of where the part came from, how ordered it, where it is warehoused, loaded into pick/place, etc. Much better to compromised an existing chips supply chain. Does anyone think that someone somewhere is trying to kill Supermicro? They sure have had a lots of bad news lately. Steven Naslund Chicago IL >To me this looks like a Chinese version of the NSA FIREWALK product. Which is a network implant built into a RJ45 jack intended to be soldered onto a motherboard. The FIREWALK info came out with the Snowden leaks in 2013 and the tech was >years old at that time. > >https://en.wikipedia.org/wiki/NSA_ANT_catalog > >I am not able to say a lot more, but when I worked for a major defence contractor in 2006-2007 in Afghanistan, building WAN links in and out of the country by satellite, hardware implants were found in equipment. Not our equipment, but it was close >enough to our operations that we were briefed on it and made aware. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markr at signal100.com Thu Oct 4 21:31:50 2018 From: markr at signal100.com (Mark Rousell) Date: Thu, 4 Oct 2018 22:31:50 +0100 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B402FD192BB2@MUNPRDMBXA1.medline.com> References: <20181004115234.30BE326B@m0117458.ppops.net> <8d3f17d14b32cef418a85de46ca72a3a@visp.net.lb> <5BB66D7F.5020405@signal100.com> <9578293AE169674F9A048B2BC9A081B402FD192B8B@MUNPRDMBXA1.medline.com> <9347eb12cd1330c3c91576a09f740f96@visp.net.lb> <9578293AE169674F9A048B2BC9A081B402FD192BB2@MUNPRDMBXA1.medline.com> Message-ID: <5BB686C6.5080908@signal100.com> On 04/10/2018 22:00, Naslund, Steve wrote: > The other thing I am highly skeptical of is the suggestion of attempting to tap sensitive intel agency systems this way. Talking to a C&C server is suicide from within their network. How long do you think it would take them to detect a reach out to the Internet from inside? How are you going to get the data from the outside back into their network? You still have to defeat their firewalls to do it. If this was targeted to specialized video processing server then would it not be unusual for them to be talking to some random IP address on the Internet? If I understand the article correctly, all the 'infected' systems were built for outsourced service providers so not intended directly for the most sensitive of systems. Still, I agree that network activity is inevitably going to be seen in any modern competent network. In fact, the article states that odd network traffic is how Apple found out about the implants. I have observed that a common trait in technically complex stories like this is that we are not seeing the whole story. Key facts that cause everything to make sense to technical readers are often left out, either because those who have the information cannot release it (for safety or security reasons) or because it's perceived as too complex for the readership to understand. Sometimes these issues even result in deliberate inaccuracies being introduced. To put it another way: Considering that, if true, these were carefully targeted attacks it is possible that there were other ways to exfiltrate the target data that have been glossed over. That said, even in highly complex or high cost plans, people sometimes make basic errors. Misplaced decimal places, wrong units, etc. Perhaps relaying on network access was another basic error. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Thu Oct 4 21:36:07 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 21:36:07 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <27464.1538688283@turing-police.cc.vt.edu> References: <20181004141007.30BE01A8@m0117458.ppops.net> <27464.1538688283@turing-police.cc.vt.edu> Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192C5B@MUNPRDMBXA1.medline.com> >> Classified networks do not connect to other networks unless they are >> equally or higher classified. No internet connection. >> Period. Not quite but there are at least application level gateways. For example, there are usually gateway that can let unclassified email flow into classified systems. However there is an application gateway to allow ONLY email protocols and only in the desired direction. >Well, if your classified network is connecting to a higher classified net, then >*that* network is connecting to a lower classified net, right? In a very highly controlled manner. The lower classified network may only be allowed to send data to the higher classified network. If the higher level network is multilevel capable it will be allowed to move documents to the lower level network if they are at the right level of classification. Again this is application layer security and all levels below that would not be trusted between the two networks. A gateway with a specialized application would have vetted connectivity to both networks. >That, plus I think the Snowden escapade was ample proof that security rules will get bent when needed to get work done - it turned out that Snowden was able to walk off with terabytes of data because >security restrictions had been disabled because they were putting a crimp in the analysts' style... That is completely different. We are talking HUMINT instead of ELINT or SIGINT. Snowden flat out stole the data as an insider. Steven Naslund Chicago IL From SNaslund at medline.com Thu Oct 4 21:41:20 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 21:41:20 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004141007.30BE01A8@m0117458.ppops.net> Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192C7F@MUNPRDMBXA1.medline.com> Remember it's the data that is classified, not the network. It does not matter if you have IP connectivity, it matters if the classified data is allowed to move over the connection. When a government agency talks about a "classified network" they are talking about a network that has been approved to transport the data and has appropriate access controls. Just because your email server is attached to the Internet does not mean I have access to its data. Same in the classified world, just because you can send an email from the Internet to SIPRNET does not mean you have SIPRNET access. Steven Naslund Chicago IL >> Classified networks do not connect to other networks unless >> they are equally or higher classified. >that sentence makes no sense. if A can connect to B because B is more >highly classified than A, then B is connecting to a less classified >network A. > >randy From bill at herrin.us Thu Oct 4 21:48:47 2018 From: bill at herrin.us (William Herrin) Date: Thu, 4 Oct 2018 17:48:47 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181004141007.30BE01A8@m0117458.ppops.net> References: <20181004141007.30BE01A8@m0117458.ppops.net> Message-ID: On Thu, Oct 4, 2018 at 5:17 PM Scott Weeks wrote: > --- SNaslund at medline.com wrote: >> The other thing I am highly skeptical of is the suggestion >> of attempting to tap sensitive intel agency systems this way. >> Talking to a C&C server is suicide from within their network. > > Classified networks do not connect to other networks unless > they are equally or higher classified. No internet connection. > Period. Which makes the traffic that wanders towards the default route where nothing should go *very* noticeable. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From markr at signal100.com Thu Oct 4 21:52:21 2018 From: markr at signal100.com (Mark Rousell) Date: Thu, 4 Oct 2018 22:52:21 +0100 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B402FD192C16@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B402FD192C16@MUNPRDMBXA1.medline.com> Message-ID: <5BB68B95.1010205@signal100.com> On 04/10/2018 22:28, Naslund, Steve wrote: > > Quite different really. FIREWALK is really an intercept device to get > data out of a firewalled or air gapped network. The exploit Bloomberg > describes would modify or alter data going across a server’s bus. The > big difference is the Bloomberg device needs command and control and a > place to dump the tapped data to over the server’s network > connection. That device is not going to be able to do so out of any > classified military network I have ever worked on. Or anyone with a > halfway decent firewall (which I would assume Apple and Amazon would > have for the internal servers). I think this article is unlikely to > be true for the following reasons : > > > > 1. Separate chip is much more detectable physically than an > altered chipset that is already on the board. > > 2. Requires motherboard redesign to get access to power and > buses needed (again easily detectable during any design mods “hey does > anyone know what these are for?”) > > 3. Does not have onboard communications so it will be sending > data traffic on the network interfaces (will definitely trigger even > the most rudimentary IDP systems). It relies on these backbone > Internet companies and Intelligence agencies to have absolutely > abysmal security on their networks to be at all useful. > > 4. Parts would have to be brought into the plant, stored > somewhere, and all the internal systems would need a trail of where > the part came from, how ordered it, where it is warehoused, loaded > into pick/place, etc. Much better to compromised an existing chips > supply chain. > Whatever the truth here, I'm sure that the article as it is written isn't telling us everything. There's more to this than meets the eye including, quite possibly, the full facts about how data would be exfiltrated and/or, perhaps, exactly what was done to the customers' hardware. > Does anyone think that someone somewhere is trying to kill > Supermicro? They sure have had a lots of bad news lately. > Who knows. Perhaps we are intended to come away with certain impressions. -- Mark Rousell -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Thu Oct 4 22:07:06 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 4 Oct 2018 22:07:06 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004141007.30BE01A8@m0117458.ppops.net> Message-ID: <9578293AE169674F9A048B2BC9A081B402FD192CA4@MUNPRDMBXA1.medline.com> It would be really noticeable. In the secure networks I have worked with "default routes" were actually strictly forbidden. Also, ACLs and firewall policy is all written with Deny All policy first. Everything talking through them is explicitly allowed. The government especially in the three letter intel agencies is not a clownish as they are depicted. Steven Naslund Chicago IL >Which makes the traffic that wanders towards the default route where >nothing should go *very* noticeable. > >Regards, >Bill Herrin From surfer at mauigateway.com Thu Oct 4 22:07:10 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Oct 2018 15:07:10 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181004150710.30BE0488@m0117458.ppops.net> --- randy at psg.com wrote: From: Randy Bush > Classified networks do not connect to other networks unless > they are equally or higher classified. that sentence makes no sense. if A can connect to B because B is more highly classified than A, then B is connecting to a less classified network A. ------------------------------------------------- Yeah, I borked that higher thing, but I still stand by the no internet access. Someone bends that rule and trouble follows. scott From surfer at mauigateway.com Thu Oct 4 22:13:09 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Oct 2018 15:13:09 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181004151309.30BE0413@m0117458.ppops.net> --- eric.kuhnke at gmail.com wrote: From: Eric Kuhnke many contractors *do* have sensitive data on their networks with a gateway out to the public Internet. ---------------------------------------- I could definitely imagine that happening. scott From johnl at iecc.com Fri Oct 5 01:07:21 2018 From: johnl at iecc.com (John Levine) Date: 4 Oct 2018 21:07:21 -0400 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <60afb948-5f6d-8ea8-00c9-6d4d92ff0269@forfun.net> Message-ID: <20181005010722.122C02006A0D69@ary.qy> In article <60afb948-5f6d-8ea8-00c9-6d4d92ff0269 at forfun.net>, Marco Davids via NANOG wrote: >> Even if you do have v6, some things like DNSSEC don't work very well >> if you can't do them over v4. > >Is that so? Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot easier to stick to v4. Geoff Huston has written about this a lot and it's a well known problem in the DNS community. I'm surprised if it's news to anyone here. https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/ From jhellenthal at dataix.net Fri Oct 5 03:06:57 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Thu, 4 Oct 2018 22:06:57 -0500 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B402FD192CA4@MUNPRDMBXA1.medline.com> References: <20181004141007.30BE01A8@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B402FD192CA4@MUNPRDMBXA1.medline.com> Message-ID: You are what you allow -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Oct 4, 2018, at 17:07, Naslund, Steve wrote: > > It would be really noticeable. In the secure networks I have worked with "default routes" were actually strictly forbidden. Also, ACLs and firewall policy is all written with Deny All policy first. Everything talking through them is explicitly allowed. > > The government especially in the three letter intel agencies is not a clownish as they are depicted. > > Steven Naslund > Chicago IL > >> Which makes the traffic that wanders towards the default route where >> nothing should go *very* noticeable. >> >> Regards, >> Bill Herrin > From bzs at theworld.com Fri Oct 5 03:08:46 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 4 Oct 2018 23:08:46 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> Message-ID: <23478.54718.613935.849399@gargle.gargle.HOWL> Just to try to squeeze something worthwhile out of these reports... I wonder, if there were a real alert, what the odds are that one wouldn't hear about it in 1 minute, 5 minutes, etc even if they didn't personally get it. Obviously edge cases are possible, you were deep in a cave with your soccer team, but there must be mathematical modeling of that sort of information dispersion. It would have to account for other possible channels, word of mouth, facebook, twitter, &c posts or really any informatonal source you were on on the internet (e.g., news sites), TV, radio, people screaming in the streets, etc. -- -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 Fri Oct 5 05:12:26 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 5 Oct 2018 07:12:26 +0200 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <20181005010722.122C02006A0D69@ary.qy> References: <20181005010722.122C02006A0D69@ary.qy> Message-ID: On 5/Oct/18 03:07, John Levine wrote: > Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of > fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot > easier to stick to v4. > > Geoff Huston has written about this a lot and it's a well known problem > in the DNS community. I'm surprised if it's news to anyone here. > > https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/ In BIND, I think this can be solved by using the "minimal-responses" knob. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Fri Oct 5 05:53:24 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 5 Oct 2018 15:53:24 +1000 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: References: <20181005010722.122C02006A0D69@ary.qy> Message-ID: <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> > On 5 Oct 2018, at 3:12 pm, Mark Tinka wrote: > > > > On 5/Oct/18 03:07, John Levine wrote: > >> Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of >> fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot >> easier to stick to v4. >> >> Geoff Huston has written about this a lot and it's a well known problem >> in the DNS community. I'm surprised if it's news to anyone here. >> >> >> https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/ > > In BIND, I think this can be solved by using the "minimal-responses" knob. > > Mark. If you don’t want fragmented IPv6 UDP responses use server ::/0 { edns-udp-size 1232; }; That’s 1280 - IPv6 header - UDP header. Anything bigger than that can theoretically be fragmented. You will then have to deal with PMTUD failures as the servers switch over to TCP. What I find ridiculous is firewall vendor that claim to support adding stateful rules on demand but don’t add “from to frag offset != 0” when they add “from to proto xxx src-port dst-port ” or don’t do packet reassembly to work around the lack of passing fragments. This is IP and fragments are part and parcel of IP whether it is IPv4 or IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From lists.nanog at monmotha.net Fri Oct 5 06:22:48 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 5 Oct 2018 02:22:48 -0400 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> References: <20181005010722.122C02006A0D69@ary.qy> <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> Message-ID: <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> On 10/5/18 1:53 AM, Mark Andrews wrote: > If you don’t want fragmented IPv6 UDP responses use > > server ::/0 { edns-udp-size 1232; }; > > That’s 1280 - IPv6 header - UDP header. Anything bigger than that can theoretically > be fragmented. You will then have to deal with PMTUD failures as the servers switch > over to TCP. Speaking of, anyone have any good reports similar to that which was the genesis of this discussion but regarding PMTUD broken-ness on IPv6? Perhaps specifically focusing on its impact w.r.t DNS over TCP? My understanding is that this is quite common on IPv4 but not as evident due to in-transit transparent fragmentation. > > What I find ridiculous is firewall vendor that claim to support adding stateful rules > on demand but don’t add “from to frag offset != 0” when they add “from to proto xxx src-port dst-port ” or don’t do packet reassembly to > work around the lack of passing fragments. This is IP and fragments are part > and parcel of IP whether it is IPv4 or IPv6. I think the "justification" for not allowing fragments is that they can be crafted specifically to evade filter policies. Now, I'd argue that, if you want to not be a broken device, you then need to do reassembly so that you can inspect. At minimum, do so for the typical attack case which uses very small fragments and/or large L3 headers to split up application data since the result is presumably something that fits within the MTU of your LAN. Or statefully track whether fragments are expected for a conversation. Or drop fragments that could be used to evade policies but permit fragments that couldn't. Or...something other than breaking things horribly and whining that the protocol is broken. Of course, a lot of these are also the same boxes that, through design or misconfiguration, break PMTUD, too, I suspect. -- Brandon Martin From marka at isc.org Fri Oct 5 07:16:49 2018 From: marka at isc.org (Mark Andrews) Date: Fri, 5 Oct 2018 17:16:49 +1000 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> References: <20181005010722.122C02006A0D69@ary.qy> <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> Message-ID: <16BCDD71-E433-4335-8356-094B1E6EC3BD@isc.org> > On 5 Oct 2018, at 4:22 pm, Brandon Martin wrote: > > On 10/5/18 1:53 AM, Mark Andrews wrote: >> If you don’t want fragmented IPv6 UDP responses use >> server ::/0 { edns-udp-size 1232; }; >> That’s 1280 - IPv6 header - UDP header. Anything bigger than that can theoretically >> be fragmented. You will then have to deal with PMTUD failures as the servers switch >> over to TCP. > > Speaking of, anyone have any good reports similar to that which was the genesis of this discussion but regarding PMTUD broken-ness on IPv6? Perhaps specifically focusing on its impact w.r.t DNS over TCP? > > My understanding is that this is quite common on IPv4 but not as evident due to in-transit transparent fragmentation. > >> What I find ridiculous is firewall vendor that claim to support adding stateful rules >> on demand but don’t add “from to frag offset != 0” when they add “from to proto xxx src-port dst-port ” or don’t do packet reassembly to >> work around the lack of passing fragments. This is IP and fragments are part >> and parcel of IP whether it is IPv4 or IPv6. > > I think the "justification" for not allowing fragments is that they can be crafted specifically to evade filter policies. So require frag 0 to have what you require to do the filtering. Most stacks send maximal sized initial fragments up to 1280 bytes. For DNS the UDP header will be there as there is at least 8 bytes of fragmented packet. Additionally reassembly attacks are much harder as there is 32 bits of fragmentation identifier rather than 16 in IPv4. IPv6 fragmentation was designed with knowledge of the IPv4 reassembly attacks in mind. > Now, I'd argue that, if you want to not be a broken device, you then need to do reassembly so that you can inspect. At minimum, do so for the typical attack case which uses very small fragments and/or large L3 headers to split up application data since the result is presumably something that fits within the MTU of your LAN. Or statefully track whether fragments are expected for a conversation. Or drop fragments that could be used to evade policies but permit fragments that couldn't. Or...something other than breaking things horribly and whining that the protocol is broken. > > Of course, a lot of these are also the same boxes that, through design or misconfiguration, break PMTUD, too, I suspect. > -- > Brandon Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wwaites at tardis.ed.ac.uk Fri Oct 5 10:32:45 2018 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Fri, 5 Oct 2018 11:32:45 +0100 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23478.54718.613935.849399@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> Message-ID: > I wonder, if there were a real alert, what the odds are that one > wouldn't hear about it in 1 minute, 5 minutes, etc even if they didn't > personally get it. > > Obviously edge cases are possible, you were deep in a cave with your > soccer team, but there must be mathematical modeling of that sort of > information dispersion. > > It would have to account for other possible channels, word of mouth, > facebook, twitter, &c posts or really any informatonal source you were > on on the internet (e.g., news sites), TV, radio, people screaming in > the streets, etc. You could do this, in principle, but you’d need a whole bunch of assumptions. What you want is a big graph of all people with weighted edges. The weights are the effective bitrates, or the chance per unit time that a message is sent and received along the edge (that’s going to mean guessing at some plausible numbers for each medium). We don’t have such a giant graph so we’d have to construct it and claim that for these purposes it has the right properties and represents the real world. You do this by saying, for each person, make a “word of mouth” edge to another randomly chosen person with a some probability. And so on. There’s more guessing here about those probabilities, but this has been studied quite a bit, at least for real networks where the graph is available (e.g. twitter and facebook are favourites among people who research social networks). Once you’ve got this big graph of all the people and the chance of a message going between any two of them pairwise, you write down a big matrix, Q = [q_ij] which tells you that a message at person i has such and such a chance to go to person j in one time unit. You then pick the people who got the initial message and make a vector x_0 = [x_i] where the entries are 0 if they didn’t get it and 1/n if they did (n is the number of people who got it). Now you can say, x(t) = exp(tQ) * x_0 and ask all the sorts of questions that you ask. That gives you the chance at each time that each person is receiving the message. To answer “what are the chances someone heard about it in one minute”, sum up x*dt for all times from 0 to 1 minute, subtract out x_0 (because they already got it) and add up the probabilities that are left. If Q is very big, this is expensive to compute (matrix exponentials are expensive) but I think you could scale the whole thing down to a representative sample population. It might be fun to do this a little bit more seriously than a hastily written mailing list post but I think it would always rely on a lot of guesses so would have to be taken with a very big grain of salt. As well, this is just one way you could model the process and there are a number of obvious criticisms (memorylessness jumps right out). Cheers, -w From cscora at apnic.net Fri Oct 5 18:03:19 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Oct 2018 04:03:19 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181005180319.250E0C450F@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, IRNOG 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 06 Oct, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 719613 Prefixes after maximum aggregation (per Origin AS): 276479 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 345397 Total ASes present in the Internet Routing Table: 62033 Prefixes per ASN: 11.60 Origin-only ASes present in the Internet Routing Table: 53570 Origin ASes announcing only one prefix: 23365 Transit ASes present in the Internet Routing Table: 8463 Transit-only ASes present in the Internet Routing Table: 265 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 45 Number of instances of unregistered ASNs: 45 Number of 32-bit ASNs allocated by the RIRs: 24323 Number of 32-bit ASNs visible in the Routing Table: 19649 Prefixes from 32-bit ASNs in the Routing Table: 82878 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 282 Number of addresses announced to Internet: 2855171843 Equivalent to 170 /8s, 46 /16s and 119 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 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: 240471 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 196173 Total APNIC prefixes after maximum aggregation: 55802 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 193872 Unique aggregates announced from the APNIC address blocks: 79906 APNIC Region origin ASes present in the Internet Routing Table: 9145 APNIC Prefixes per ASN: 21.20 APNIC Region origin ASes announcing only one prefix: 2579 APNIC Region transit ASes present in the Internet Routing Table: 1369 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4111 Number of APNIC addresses announced to Internet: 767775170 Equivalent to 45 /8s, 195 /16s and 81 /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: 214165 Total ARIN prefixes after maximum aggregation: 101278 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 214003 Unique aggregates announced from the ARIN address blocks: 101771 ARIN Region origin ASes present in the Internet Routing Table: 18264 ARIN Prefixes per ASN: 11.72 ARIN Region origin ASes announcing only one prefix: 6792 ARIN Region transit ASes present in the Internet Routing Table: 1816 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2455 Number of ARIN addresses announced to Internet: 1098491808 Equivalent to 65 /8s, 121 /16s and 167 /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: 196442 Total RIPE prefixes after maximum aggregation: 93831 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 192762 Unique aggregates announced from the RIPE address blocks: 113962 RIPE Region origin ASes present in the Internet Routing Table: 25533 RIPE Prefixes per ASN: 7.55 RIPE Region origin ASes announcing only one prefix: 11499 RIPE Region transit ASes present in the Internet Routing Table: 3519 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7459 Number of RIPE addresses announced to Internet: 714618496 Equivalent to 42 /8s, 152 /16s and 54 /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: 93183 Total LACNIC prefixes after maximum aggregation: 21345 LACNIC Deaggregation factor: 4.37 Prefixes being announced from the LACNIC address blocks: 94581 Unique aggregates announced from the LACNIC address blocks: 41323 LACNIC Region origin ASes present in the Internet Routing Table: 7601 LACNIC Prefixes per ASN: 12.44 LACNIC Region origin ASes announcing only one prefix: 2089 LACNIC Region transit ASes present in the Internet Routing Table: 1423 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5149 Number of LACNIC addresses announced to Internet: 172320544 Equivalent to 10 /8s, 69 /16s and 103 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19604 Total AfriNIC prefixes after maximum aggregation: 4183 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 24113 Unique aggregates announced from the AfriNIC address blocks: 8183 AfriNIC Region origin ASes present in the Internet Routing Table: 1201 AfriNIC Prefixes per ASN: 20.08 AfriNIC Region origin ASes announcing only one prefix: 406 AfriNIC Region transit ASes present in the Internet Routing Table: 246 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 475 Number of AfriNIC addresses announced to Internet: 101538304 Equivalent to 6 /8s, 13 /16s and 90 /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 4450 485 476 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2994 1153 93 VIETEL-AS-AP Viettel Group, VN 4766 2822 11130 764 KIXS-AS-KR Korea Telecom, KR 45899 2762 1674 159 VNPT-AS-VN VNPT Corp, VN 9829 2746 1494 557 BSNL-NIB National Internet Backbone, IN 9394 2589 4907 31 CTTNET China TieTong Telecommunications 9808 2270 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2250 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2132 421 171 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 11492 3547 229 465 CABLEONE - CABLE ONE, INC., US 6327 3451 1324 83 SHAW - Shaw Communications Inc., CA 22773 3242 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2315 5005 815 AMAZON-02 - Amazon.com, Inc., US 18566 2157 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2153 2739 522 CHARTER-NET-HKY-NC - Charter Communicat 16625 2143 1109 1551 AKAMAI-AS - Akamai Technologies, Inc., 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications 30036 2047 346 149 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2046 5081 602 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 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 4907 1613 129 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3054 378 50 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2568 592 1915 AKAMAI-ASN1, US 12389 2099 2048 673 ROSTELECOM-AS, RU 34984 2047 337 509 TELLCOM-AS, TR 9121 1837 1691 17 TTNET, TR 13188 1604 100 45 TRIOLAN, UA 8402 1256 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA 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 5401 3302 612 Uninet S.A. de C.V., MX 10620 3195 489 804 Telmex Colombia S.A., CO 11830 2650 370 81 Instituto Costarricense de Electricidad 6503 1648 444 65 Axtel, S.A.B. de C.V., MX 7303 1432 955 206 Telecom Argentina S.A., AR 28573 1120 2238 189 CLARO S.A., BR 6147 1040 377 31 Telefonica del Peru S.A.A., PE 3816 1014 509 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 933 144 71 Alestra, S. de R.L. de C.V., MX 18881 919 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 1205 396 48 LINKdotNET-AS, EG 37611 898 107 9 Afrihost, ZA 36903 795 399 143 MT-MPLS, MA 36992 749 1411 41 ETISALAT-MISR, EG 24835 653 802 18 RAYA-AS, EG 8452 607 1728 15 TE-AS TE-AS, EG 37492 466 470 57 ORANGE-, TN 29571 463 70 11 ORANGE-COTE-IVOIRE, CI 37342 394 32 1 MOVITEL, MZ 23889 375 231 15 MauritiusTelecom, MU 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 5401 3302 612 Uninet S.A. de C.V., MX 12479 4907 1613 129 UNI2-AS, ES 4538 4645 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4450 485 476 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3547 229 465 CABLEONE - CABLE ONE, INC., US 6327 3451 1324 83 SHAW - Shaw Communications Inc., CA 22773 3242 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3195 489 804 Telmex Colombia S.A., CO 8551 3054 378 50 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 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 4907 4778 UNI2-AS, ES 4538 4645 4571 ERX-CERNET-BKB China Education and Research Net 7545 4450 3974 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3451 3368 SHAW - Shaw Communications Inc., CA 22773 3242 3086 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11492 3547 3082 CABLEONE - CABLE ONE, INC., US 8551 3054 3004 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2994 2901 VIETEL-AS-AP Viettel Group, VN 45899 2762 2603 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 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 64643 PRIVATE 119.44.18.0/24 9394 CTTNET China TieTong Telecommu 64643 PRIVATE 119.44.192.0/22 9394 CTTNET China TieTong Telecommu 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.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 45.121.32.0/22 134356 UNKNOWN 45.121.136.0/22 22552 ESITED - eSited Solutions, US 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 64.28.160.0/20 20475 AS20475 - Global Capacity, LLC, US 64.29.240.0/20 27279 -Reserved AS-, ZZ 64.30.152.0/24 15830 TELECITY-LON, GB 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:14 /9:11 /10:36 /11:98 /12:290 /13:566 /14:1104 /15:1884 /16:13315 /17:7906 /18:13774 /19:25359 /20:39581 /21:45915 /22:89388 /23:73469 /24:404701 /25:817 /26:618 /27:633 /28:36 /29:21 /30:21 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3684 4907 UNI2-AS, ES 6327 3237 3451 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2800 3547 CABLEONE - CABLE ONE, INC., US 8551 2510 3054 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2504 3242 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2051 2157 MEGAPATH5-US - MegaPath Corporation, US 11830 2000 2650 Instituto Costarricense de Electricidad y Telec 30036 1795 2047 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1762 2085 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:1604 2:883 4:18 5:2660 6:44 7:1 8:1137 12:1864 13:218 14:1829 15:34 16:3 17:194 18:55 20:50 23:2546 24:2431 25:2 27:2512 31:2003 32:84 35:29 36:536 37:2878 38:1547 39:261 40:121 41:3218 42:714 43:1968 44:123 45:5699 46:3090 47:225 49:1348 50:1064 51:318 52:1087 54:364 55:1 56:12 57:39 58:1623 59:986 60:417 61:2090 62:1881 63:1800 64:5054 65:2209 66:4793 67:2680 68:1157 69:3365 70:1155 71:579 72:2256 74:2728 75:420 76:456 77:1647 78:1735 79:2234 80:1568 81:1415 82:1051 83:790 84:1043 85:2038 86:561 87:1489 88:916 89:2349 90:207 91:6440 92:1280 93:2397 94:2440 95:3029 96:934 97:353 98:928 99:142 100:86 101:1188 102:233 103:18831 104:3569 105:218 106:772 107:1805 108:709 109:3362 110:1676 111:1810 112:1332 113:1307 114:1169 115:1684 116:1666 117:1788 118:2208 119:1694 120:1084 121:1046 122:2387 123:1662 124:1444 125:1931 128:1179 129:672 130:500 131:1616 132:726 133:191 134:1033 135:237 136:530 137:658 138:1931 139:695 140:546 141:754 142:840 143:1020 144:844 145:498 146:1237 147:741 148:1685 149:776 150:767 151:997 152:867 153:325 154:1873 155:931 156:1414 157:813 158:661 159:1877 160:1490 161:838 162:2642 163:625 164:1093 165:1555 166:450 167:1258 168:3171 169:850 170:3954 171:497 172:1035 173:2074 174:999 175:806 176:2097 177:4044 178:2521 179:1329 180:2161 181:2442 182:2382 183:1303 184:1146 185:14183 186:3600 187:2474 188:2921 189:2000 190:8187 191:1368 192:9848 193:6287 194:5108 195:4026 196:2757 197:1606 198:5663 199:5948 200:7313 201:4991 202:10262 203:10234 204:4600 205:3001 206:3207 207:3176 208:3932 209:4149 210:3831 211:1986 212:3032 213:2806 214:1045 215:52 216:6012 217:2164 218:868 219:577 220:1802 221:1001 222:986 223:1392 End of report From lists.nanog at monmotha.net Fri Oct 5 20:43:24 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 5 Oct 2018 16:43:24 -0400 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <16BCDD71-E433-4335-8356-094B1E6EC3BD@isc.org> References: <20181005010722.122C02006A0D69@ary.qy> <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> <16BCDD71-E433-4335-8356-094B1E6EC3BD@isc.org> Message-ID: <5875b6f6-1341-7f31-1a19-be25b869afa9@monmotha.net> On 10/5/18 3:16 AM, Mark Andrews wrote: > So require frag 0 to have what you require to do the filtering. Most stacks send maximal sized initial fragments up to 1280 bytes. For DNS the UDP header will be there as there is at least 8 bytes of fragmented packet. Additionally reassembly attacks are much harder as there is 32 bits of fragmentation identifier rather than 16 in IPv4. > > IPv6 fragmentation was designed with knowledge of the IPv4 reassembly attacks in mind. You'll get no argument from me, here. This is not new nor are ways to deal with it unknown. Despite that, it's a common reason I hear for just blindly dropping all fragments. Personally, I consider such devices/stacks broken, but that doesn't mean we don't have to deal with them, unfortunately. -- Brandon Martin From sean at donelan.com Fri Oct 5 23:47:51 2018 From: sean at donelan.com (Sean Donelan) Date: Fri, 5 Oct 2018 19:47:51 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23478.54718.613935.849399@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> Message-ID: On Thu, 4 Oct 2018, bzs at theworld.com wrote: > Just to try to squeeze something worthwhile out of these reports... > > I wonder, if there were a real alert, what the odds are that one > wouldn't hear about it in 1 minute, 5 minutes, etc even if they didn't > personally get it. What happens when people don't get warnings? Gatlinburg, TN - 2016 Wildfires - 14 fatalities Northern California - 2017 Wildfires - 44 fatalities Yes, neighbors alerted neighbors, local emergency officials drove through the streets and knocked on doors, radio and television stations broke into programming. It took hours, and eventually about 200,000 people were warned. But the wildfires moved faster than those other alerting methods. Sometimes people are asleep (disasters don't always happen at 2pm on a work day), live alone, are not constantly watching TV or checking social media. Its unlikely any system will ever be able to reach everyone. WEA reaches more people (about 70% of the national population), much faster (about 10-15 seconds), day and night (most people keep their mobile phones near them even while sleeping) than the existing warning systems. But they should still be used in combination, not exclusive. Warning systems depend on communication service providers keeping their systems operating, i.e. cell towers with backup power, ISPs with diversity in their networks, etc. From mike at mtcc.com Fri Oct 5 23:53:52 2018 From: mike at mtcc.com (Michael Thomas) Date: Fri, 5 Oct 2018 16:53:52 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> Message-ID: <2a6c45aa-d208-4559-39f4-cb6fdb85d34a@mtcc.com> On 10/05/2018 04:47 PM, Sean Donelan wrote: > On Thu, 4 Oct 2018, bzs at theworld.com wrote: >> Just to try to squeeze something worthwhile out of these reports... >> >> I wonder, if there were a real alert, what the odds are that one >> wouldn't hear about it in 1 minute, 5 minutes, etc even if they didn't >> personally get it. > > What happens when people don't get warnings? > > Gatlinburg, TN - 2016 Wildfires - 14 fatalities > > Northern California - 2017 Wildfires - 44 fatalities > > Yes, neighbors alerted neighbors, local emergency officials drove > through the streets and knocked on doors, radio and television > stations broke into programming. It took hours, and eventually about > 200,000 people were warned. But the wildfires moved faster than those > other alerting methods. > > Sometimes people are asleep (disasters don't always happen at 2pm on a > work day), live alone, are not constantly watching TV or checking > social media. > > Its unlikely any system will ever be able to reach everyone. WEA > reaches more people (about 70% of the national population), much > faster (about 10-15 seconds), day and night (most people keep their > mobile phones near them even while sleeping) than the existing warning > systems. But they should still be used in combination, not exclusive. > > Warning systems depend on communication service providers keeping > their systems operating, i.e. cell towers with backup power, ISPs with > diversity in their networks, etc. If we ever get our earthquake early warning system, people definitely have incentive to pay attention since a minute before the incoming S waves ain't a lot of time, but could be a lifesaver. Mike From nanog at radu-adrian.feurdean.net Sat Oct 6 08:24:46 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 06 Oct 2018 10:24:46 +0200 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: <1538814286.166893.1532712632.1D899322@webmail.messagingengine.com> On Thu, Oct 4, 2018, at 21:53, William Herrin wrote: > On Thu, Oct 4, 2018 at 3:10 PM Brandon Applegate wrote: > > - Traceroutes are miserable. > > Also breaks PMTUD which can break TCP for everybody whose packets > transit your router. So don't do this. ... unless you happen to provide a "MTU1500" service over a jumboframe (more than 9100) backbone, which you can very easily do these days. In which case fragmentation/packet too big should never occur. Traceroutes remain miserable, at least from outside towards your network. From surfer at mauigateway.com Sat Oct 6 22:09:09 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 6 Oct 2018 15:09:09 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test Message-ID: <20181006150909.4698A624@m0117459.ppops.net> --- sean at donelan.com wrote: From: Sean Donelan Sometimes people are asleep (disasters don't always happen at 2pm on a work day), live alone, are not constantly watching TV or checking social media. Its unlikely any system will ever be able to reach everyone. ------------------------------------------- Or some live where there is no cell coverage, don't watch TV, live where their neighbors are far away and no gov't folks are going to knock on doors because the driveway is long, locked at the front gate and there're dogs in the yard... :-) scott From valdis.kletnieks at vt.edu Sun Oct 7 03:13:52 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 06 Oct 2018 23:13:52 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <20181006150909.4698A624@m0117459.ppops.net> References: <20181006150909.4698A624@m0117459.ppops.net> Message-ID: <188348.1538882032@turing-police.cc.vt.edu> On Sat, 06 Oct 2018 15:09:09 -0700, "Scott Weeks" said: > Or some live where there is no cell coverage, don't > watch TV, live where their neighbors are far away > and no gov't folks are going to knock on doors > because the driveway is long, locked at the front > gate and there're dogs in the yard... :-) Population density issues (you can only have so many people with long driveways and neighbors far away per square mile) mean that these people are *way* down the long tail. Right up there with people who live on tiny almost uninhabited islands out in the middle of the ocean. :) Since there isn't infinite money to build a system that will reach *everybody*, the only reasonable approach is to cobble together a set of overlapping systems on existing technology that covers the most people while staying inside the funding restrictions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From pete at altadena.net Sun Oct 7 06:17:01 2018 From: pete at altadena.net (Pete Carah) Date: Sat, 6 Oct 2018 23:17:01 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181004151309.30BE0413@m0117458.ppops.net> References: <20181004151309.30BE0413@m0117458.ppops.net> Message-ID: On 10/04/2018 03:13 PM, Scott Weeks wrote: > > --- eric.kuhnke at gmail.com wrote: > From: Eric Kuhnke > > many contractors *do* have sensitive data on their > networks with a gateway out to the public Internet. > ---------------------------------------- > > I could definitely imagine that happening. > > scott > I always loved the early "HIPPA" systems at the doctor's office where the web browser was not restricted, nor the email client, and they ran XP.  These didn't even need a hardware feature to exploit... Even in a server, though, given spectre or an equivalent (remember this could be exploited from javascript in a browser or php or...) if apps were present on a machine with both kinds of info/connections, we don't even need custom chips, the path is there in cache-management/pipeline-management bugs.  I once ran into a cute bug in a power-pc chip (405ep, used in some older switches as the management processor) where I had to mark all I/O buffers non-cachable (yes, this is a good idea anyhow, but the chip documentation said that an invalidate/flush in the right places took care of that, and I really needed the speed later during packet parsing.  And no, copying the packets was prohibitive...)  Anyhow, with an 30 (or so) mbit stream coming into ram, about every 30 seconds, the ethertype byte came in 0 instead of 0800 (the responsible bug was in cache management, and the errata item describing it required 5 separate steps involving both processor and I/O access to that address or one in that cache line.  At least this system wasn't multiuser...  A friend who read the errata item said (and I agree) it looks like a Rube Goldberg sequence. (yes, I'm dating myself.)  As far as I know, 10 years later, the bug has never been fixed in the masks (of course, most ppc (and embedded mips) designs are now going to ARM chips.  Don't know how much better that is; some of the speed-demon versions of that have a version of spectre.) -- Pete From bzs at theworld.com Sun Oct 7 19:23:33 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sun, 7 Oct 2018 15:23:33 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> Message-ID: <23482.23861.377358.50231@gargle.gargle.HOWL> Re: EAS alert, people not being reached That was one advantage of the old air raid siren system, it was difficult to ignore and required nothing special to receive (hearing impaired excepted.) I recall in NYC as a kid you were expected (maybe legally required, not sure) to head off the streets and to the nearest shelter. And people did. If you were a wise guy teen and didn't and a cop saw you you'd get an earful (don't ask me how I know this.) Some areas particularly near the shore have similar siren systems. Probably a bigger issue which isn't as apparent from a test is do people have any reasonable options even if they are completely aware that negotiations with the UFOs have collapsed and the death rays have started? In the days when nuclear attack was more likely we'd often say that it's all well and good to be alerted but seriously wtf are we supposed to do (duck and cover!)? Beyond "better than nothing!"? Granted for some proportion of the population a half-baked response is a lot better than none. If you're likely 2+ miles from a 1MT nuclear air burst just going into your cellars and away from windows (flying glass and debris) would probably save most of those lives and much injury at least from the initial blast. So, EAS alert may be better than nothing for many but some enumeration of why one might get one and what would be a reasonable reaction to each case would be useful. Otherwise it's just "ALERT! YOU ARE ABOUT TO DIE!" Ok... Of course for many here it might mean "switch to alternate power source immediately". -- -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 aaron at heyaaron.com Sun Oct 7 21:53:10 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sun, 7 Oct 2018 14:53:10 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23482.23861.377358.50231@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <23482.23861.377358.50231@gargle.gargle.HOWL> Message-ID: Hopefully Google and Amazon product engineers are listening: EAS/NWS alert messages could come over your various devices to help the consumer... The NEST Protect smoke alarms would particularly be useful for NWS Alerts (i.e. they're loud and could broadcast "TORNADO! SEEK SHELTER IMMEDIATELY!") Already having ~6 Nest Protects, and a few Home devices, I can't seem myself ever needing to spend money on another one...unless version next.0 included an internal antenna that could pick up NWS alerts....seems like a good source of new hardware revenue to me... -A On Sun, Oct 7, 2018 at 12:25 PM wrote: > > > Re: EAS alert, people not being reached > > That was one advantage of the old air raid siren system, it was > difficult to ignore and required nothing special to receive (hearing > impaired excepted.) > > I recall in NYC as a kid you were expected (maybe legally required, > not sure) to head off the streets and to the nearest shelter. And > people did. If you were a wise guy teen and didn't and a cop saw you > you'd get an earful (don't ask me how I know this.) > > Some areas particularly near the shore have similar siren systems. > > Probably a bigger issue which isn't as apparent from a test is do > people have any reasonable options even if they are completely aware > that negotiations with the UFOs have collapsed and the death rays have > started? > > In the days when nuclear attack was more likely we'd often say that > it's all well and good to be alerted but seriously wtf are we supposed > to do (duck and cover!)? Beyond "better than nothing!"? > > Granted for some proportion of the population a half-baked response is > a lot better than none. If you're likely 2+ miles from a 1MT nuclear > air burst just going into your cellars and away from windows (flying > glass and debris) would probably save most of those lives and much > injury at least from the initial blast. > > So, EAS alert may be better than nothing for many but some enumeration > of why one might get one and what would be a reasonable reaction to > each case would be useful. > > Otherwise it's just "ALERT! YOU ARE ABOUT TO DIE!" Ok... > > Of course for many here it might mean "switch to alternate power > source immediately". > > -- > -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 fredbaker.ietf at gmail.com Sun Oct 7 22:49:36 2018 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Sun, 7 Oct 2018 15:49:36 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23482.23861.377358.50231@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <23482.23861.377358.50231@gargle.gargle.HOWL> Message-ID: > On Oct 7, 2018, at 12:23 PM, bzs at theworld.com wrote: > > That was one advantage of the old air raid siren system, it was difficult to ignore and required nothing special to receive (hearing > impaired excepted.) Where I grew up, the “Civil Defense Warning” was used for air raids, nuclear defense, and tornado warnings. By regulation, it was tested monthly. When we heard it, which we did, the usual response was “they’re testing the siren again” and resumption of the barely-interrupted activity. From mike at mtcc.com Sun Oct 7 22:53:11 2018 From: mike at mtcc.com (Michael Thomas) Date: Sun, 7 Oct 2018 15:53:11 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <23482.23861.377358.50231@gargle.gargle.HOWL> Message-ID: On 10/07/2018 03:49 PM, Fred Baker wrote: >> On Oct 7, 2018, at 12:23 PM, bzs at theworld.com wrote: >> >> That was one advantage of the old air raid siren system, it was difficult to ignore and required nothing special to receive (hearing >> impaired excepted.) > Where I grew up, the “Civil Defense Warning” was used for air raids, nuclear defense, and tornado warnings. By regulation, it was tested monthly. When we heard it, which we did, the usual response was “they’re testing the siren again” and resumption of the barely-interrupted activity. 12pm every tuesday here in SF. It's not always very easy to understand given the echos though. Mike From Brian at ampr.org Sun Oct 7 23:26:12 2018 From: Brian at ampr.org (Brian Kantor) Date: Sun, 7 Oct 2018 16:26:12 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <23482.23861.377358.50231@gargle.gargle.HOWL> Message-ID: <20181007232612.GA58990@meow.BKantor.net> On Oct 7, 2018, at 12:23 PM, bzs at theworld.com wrote: > That was one advantage of the old air raid siren system, it was > difficult to ignore and required nothing special to receive (hearing > impaired excepted.) _Wired_ has an interesting history of the various networked and standalone national alert systems that FEMA and its predecessors have tried over the years, many of them of limited success: https://www.wired.com/story/presidential-text-alert-fema-emergency-history/ - Brian https://www.dpvintageposters.com/cgi-local/detail.cgi?d=2469 From bzs at theworld.com Sun Oct 7 23:27:03 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sun, 7 Oct 2018 19:27:03 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <23482.23861.377358.50231@gargle.gargle.HOWL> Message-ID: <23482.38471.593529.287959@gargle.gargle.HOWL> On October 7, 2018 at 15:49 fredbaker.ietf at gmail.com (Fred Baker) wrote: > > > On Oct 7, 2018, at 12:23 PM, bzs at theworld.com wrote: > > > > That was one advantage of the old air raid siren system, it was difficult to ignore and required nothing special to receive (hearing > > impaired excepted.) > > Where I grew up, the “Civil Defense Warning” was used for air raids, nuclear defense, and tornado warnings. By regulation, it was tested monthly. When we heard it, which we did, the usual response was “they’re testing the siren again” and resumption of the barely-interrupted activity. No doubt we'll get there with these presidential alerts, just give it time :-) I'll get "amber alerts" regionally and just about every time it's nearly impossible that I could even with the best of intentions do a thing in response. Some non-custodial parent absconded with two kids 50 miles from here in a black honda or toyota...ok gotcha I'll keep my eyes peeled...no doubt a terrible and stressful event for those involved but... So I tend not to be in a big rush to look at those alerts, actually I think I turned them off which in that case was an option. -- -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 randy at psg.com Mon Oct 8 00:56:50 2018 From: randy at psg.com (Randy Bush) Date: Sun, 07 Oct 2018 17:56:50 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23482.38471.593529.287959@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <23482.23861.377358.50231@gargle.gargle.HOWL> <23482.38471.593529.287959@gargle.gargle.HOWL> Message-ID: > So I tend not to be in a big rush to look at those alerts, actually I > think I turned them off which in that case was an option. i turned them off long ago. i did get a presidential alert in november '16. turned out to be a very serious disaster. randy From SNaslund at medline.com Mon Oct 8 03:37:34 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 8 Oct 2018 03:37:34 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> Message-ID: <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> A few cases come to mind. I also think there are lots of alerts that will not send people screaming into the streets. 9/11 did not really have that effect in most places and it took quite some time for word to spread to people who did not have full time media access. You also have to account for non-urban areas (the majority of our land mass). In a lot of this country you might not see anyone other than the ones you live with for many hours or days at a time. Here is a few times I know I would not get an alert unless it came via cellular. 1. 2 AM when most people are sleeping. 2. Riding in my car for an hour to / from work and listening to a podcast or music on my device. 3. Out in the boat or at the beach. Usually not listening to broadcast media. Alerting cell phones should not be too high a bar to reach. They certainly don't seem to have a problem getting notifications to you from every app you have. It's pretty long overdue coming from companies that constantly brag about their super advanced high speed data networks. It's pretty clear that they are not taking this real serious if you look at how long this executive order is taking to realize. We are talking about years and years. With more and more people cutting their cable and using Internet media vs broadcast media, alerting has actually gotten worse recently. Steven Naslund Chicago IL > I wonder, if there were a real alert, what the odds are that one > wouldn't hear about it in 1 minute, 5 minutes, etc even if they didn't > personally get it. > > Obviously edge cases are possible, you were deep in a cave with your > soccer team, but there must be mathematical modeling of that sort of > information dispersion. > > It would have to account for other possible channels, word of mouth, > facebook, twitter, &c posts or really any informatonal source you were > on on the internet (e.g., news sites), TV, radio, people screaming in > the streets, etc. From SNaslund at medline.com Mon Oct 8 03:47:25 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 8 Oct 2018 03:47:25 +0000 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> References: <20181005010722.122C02006A0D69@ary.qy> <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> Message-ID: <9578293AE169674F9A048B2BC9A081B4030082406D@WAUPRDMBXP1.medline.com> >On 10/5/18 1:53 AM, Mark Andrews wrote: > If you don’t want fragmented IPv6 UDP responses use > > server ::/0 { edns-udp-size 1232; }; > > That’s 1280 - IPv6 header - UDP header. Anything bigger than that can > theoretically be fragmented. You will then have to deal with PMTUD > failures as the servers switch over to TCP. That is true provided that you accept that some people may not be able to respond without the packet getting fragmented due to tunneling or a million other reasons they may not support that MTU. Nonstandard MTU has always and seems will continue to be problematic. It all really began with tunneling which by its nature lowers the MTU available to the application. Firewalls really have to just deal with it and do the re-assembly they need to. It does create tremendous performance issues for these devices at high bandwidth. Bottom line is fragmentation sucks and V6 does not make it any better. Steven Naslund Chicago IL From SNaslund at medline.com Mon Oct 8 03:53:08 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 8 Oct 2018 03:53:08 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181004151309.30BE0413@m0117458.ppops.net> References: <20181004151309.30BE0413@m0117458.ppops.net> Message-ID: <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> You just need to fire any contractor that allows a server with sensitive data out to an unknown address on the Internet. Security 101. Steven Naslund >From: Eric Kuhnke > >many contractors *do* have sensitive data on their networks with a gateway out to the public Internet. >---------------------------------------- > >I could definitely imagine that happening. > >scott From lists.nanog at monmotha.net Mon Oct 8 03:55:15 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 7 Oct 2018 23:55:15 -0400 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <9578293AE169674F9A048B2BC9A081B4030082406D@WAUPRDMBXP1.medline.com> References: <20181005010722.122C02006A0D69@ary.qy> <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> <9578293AE169674F9A048B2BC9A081B4030082406D@WAUPRDMBXP1.medline.com> Message-ID: <357cc258-5816-3186-2995-1011fcc738a5@monmotha.net> On 10/7/18 11:47 PM, Naslund, Steve wrote: > That is true provided that you accept that some people may not be able to respond without the packet getting fragmented due to tunneling or a million other reasons they may not support that MTU. Nonstandard MTU has always and seems will continue to be problematic. It all really began with tunneling which by its nature lowers the MTU available to the application. Firewalls really have to just deal with it and do the re-assembly they need to. It does create tremendous performance issues for these devices at high bandwidth. Bottom line is fragmentation sucks and V6 does not make it any better. Except that, in IPv6-land, anyone with effective MTU < 1280 has the onus put on them to "make things work" i.e. come up with an adaptation layer or some sort of tunnel-layer transparent fragmentation. If you're relying on The Internet to fragment to <1280 for you, you're bound to see breakage. I'd like to think we can safely ignore this case in terms of operations. -- Brandon Martin From randy at psg.com Mon Oct 8 04:38:43 2018 From: randy at psg.com (Randy Bush) Date: Sun, 07 Oct 2018 21:38:43 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> Message-ID: > You just need to fire any contractor that allows a server with > sensitive data out to an unknown address on the Internet. Security > 101. 'cept the goal is not unemployed contractors From dtaylor at vocalabs.com Mon Oct 8 13:53:55 2018 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 8 Oct 2018 08:53:55 -0500 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> Message-ID: <17e72878-815a-74a6-90b1-0752fb51b908@vocalabs.com> That would be one way, but a lot of the problem is unplanned cross-access. It's (relatively) easy to isolate network permissions and access at a single location, but once you have multi-site configurations it gets more complex. Especially when you have companies out there that consider VPN a reasonable way to handle secure data transfer cross-connects with vendors or clients. On 10/07/2018 10:53 PM, Naslund, Steve wrote: > You just need to fire any contractor that allows a server with sensitive data out to an unknown address on the Internet. Security 101. > > Steven Naslund > >> From: Eric Kuhnke >> > >many contractors *do* have sensitive data on their networks with a gateway out to the public Internet. -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From valdis.kletnieks at vt.edu Mon Oct 8 17:15:27 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 08 Oct 2018 13:15:27 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <17e72878-815a-74a6-90b1-0752fb51b908@vocalabs.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <17e72878-815a-74a6-90b1-0752fb51b908@vocalabs.com> Message-ID: <16279.1539018927@turing-police.cc.vt.edu> On Mon, 08 Oct 2018 08:53:55 -0500, Daniel Taylor said: > Especially when you have companies out there that consider VPN a > reasonable way to handle secure data transfer cross-connects with > vendors or clients. At some point, you get to balance any inherent security problems with the concept of using a VPN against the fact that while most VPN software has a reasonably robust point-n-drool interface to configure, most VPN alternatives are very much "some assembly required". Which is more likely? That some state-level actor finds a hole in your VPN software, or that somebody mis-configures your VPN alternative so it leaks keys and data all over the place? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From dtaylor at vocalabs.com Mon Oct 8 17:31:11 2018 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 8 Oct 2018 12:31:11 -0500 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <16279.1539018927@turing-police.cc.vt.edu> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <17e72878-815a-74a6-90b1-0752fb51b908@vocalabs.com> <16279.1539018927@turing-police.cc.vt.edu> Message-ID: <432cfaeb-0a69-40ca-3d28-60de8341c46f@vocalabs.com> The risks of VPN aren't in the VPN itself, they are in the continuous network connection architecture. 90%+ of VPN interconnects could be handled cleanly, safely, and reliably using HTTPS, without having to get internal network administration involved at all. And the risks of key exposure with HTTPS are exactly the same as the risks of having one end or the other of your VPN compromised. As it is, VPN means trusting the network admins at your peer company. On 10/08/2018 12:15 PM, valdis.kletnieks at vt.edu wrote: > On Mon, 08 Oct 2018 08:53:55 -0500, Daniel Taylor said: >> Especially when you have companies out there that consider VPN a >> reasonable way to handle secure data transfer cross-connects with >> vendors or clients. > At some point, you get to balance any inherent security problems with the > concept of using a VPN against the fact that while most VPN software has a > reasonably robust point-n-drool interface to configure, most VPN alternatives > are very much "some assembly required". > > Which is more likely? That some state-level actor finds a hole in your VPN > software, or that somebody mis-configures your VPN alternative so it leaks keys > and data all over the place? From sean at donelan.com Mon Oct 8 17:53:15 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 8 Oct 2018 13:53:15 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <188348.1538882032@turing-police.cc.vt.edu> References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: On Sat, 6 Oct 2018, valdis.kletnieks at vt.edu wrote: > Since there isn't infinite money to build a system that will reach *everybody*, > the only reasonable approach is to cobble together a set of overlapping systems > on existing technology that covers the most people while staying inside the > funding restrictions. There is also the circular logic of budget cutting. 1. We don't need to fund outdoor sirens, becuase we have E.A.S. on radio/TV/cable. 2. We don't need E.A.S. because we have NOAA weather radio. 3. We don't need NWR because we have Wireless Emergencey Alerts. 4. We don't need WEA, because we have outdoor sirens. 5. Goto 1 There is no business case for Amazon, Apple or Google to include emergency alerts as part of their smart speakers. The majority of cities did not repair/replace their outdoor civil defense sirens when they reached their 40-year lifespan in the 1990s. Tornado Alley likely still has the most working outdoor sirens, but even in that part of the country a majority of cities saved money by not maintaining them. An average outdoor siren costs $25,000 installation, $1,000/year maintenance and only covers 1/2-mile radius -- outdoors. In most places, an outdoor siren won't wake you up indoors. This year's federal budget proposed cutting 20% of NOAA weather readio transmitters to save money. Fewer than 5% of households buy weather radios. Although FCC and FEMA help standardize national disaster response systems, such as 9-1-1, E.A.S. and W.E.A, essentially 100% use of those systems is for local disasters and emergencies. It makes sense for some national consistency for things like stop signs and emergency alerts and 9-1-1. People travel and work in other cities, and aren't ready for lots of local variations during emergencies. Since 2011, EAS and WEA has been used for 33,000 local weather alerts and local emergencies and only 4 national tests (4 for EAS and 1 for WEA). FEMA only has about 15 people to maintain its national warning system 24/7/365. Giving the lack of disaster funding, you are more likely NOT to get any warnings during a disaster than ever seeing any black helicopters flying over your house. Alexa won't say a word. From bzs at theworld.com Mon Oct 8 18:42:01 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 8 Oct 2018 14:42:01 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> Message-ID: <23483.42233.795819.818838@gargle.gargle.HOWL> On October 8, 2018 at 03:37 SNaslund at medline.com (Naslund, Steve) wrote: > A few cases come to mind. I also think there are lots of alerts > that will not send people screaming into the streets. 9/11 did not > really have that effect in most places and it took quite some time > for word to spread to people who did not have full time media > access. You also have to account for non-urban areas (the majority > of our land mass). In a lot of this country you might not see > anyone other than the ones you live with for many hours or days at > a time. 9/11 literally did send people out into the streets screaming. Even nationwide skyscrapers were evacuated in some cities. In Chicago Sears tower (and I believe the Amoco tower according to some eyewitnesses) were evacuated at about 10AM. So was the IDS tower in Minneapolis (57 stories, tallest in the city.) The White House and Capitol building were evacuated a little earlier, about 9:30AM. And the UN in NYC. At about 10:45AM NYC mayor Rudi Giuliani ordered the total evacuation of all of Lower Manhattan. https://en.wikipedia.org/wiki/Timeline_for_the_day_of_the_September_11_attacks The article below lists the evacuations of the Coca-Cola and BellSouth buildings, CNN center in Atlanta. And several more in Los Angeles (Citibank tower etc.) Well, read the article, Detroit, the Grand Coulee Dam, etc. http://articles.latimes.com/2001/sep/11/news/ss-44625 I suppose one can go back to the phrase "most places", sure, MOST places even in western Europe weren't bombed in WWII or even affected physically (i.e., by ordnance of any sort.) P.S. Over 80% of the US population is urban. I suppose since every life is precious one can measure the effectiveness based on "land mass" but then one wonders if some sheep out in a field in Idaho really care that the US was just invaded...put better: You do what you can! -- -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 nate at santafe.edu Mon Oct 8 18:54:38 2018 From: nate at santafe.edu (Nate Metheny) Date: Mon, 8 Oct 2018 12:54:38 -0600 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23483.42233.795819.818838@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> <23483.42233.795819.818838@gargle.gargle.HOWL> Message-ID: <2d181314-d828-f758-ea9e-be528d94c0f6@santafe.edu> Just as a small point of contention, if you lose the bread basket and the agricultural industries, you might as well have never received an emergency alert in a city where the supplies and fresh food will run out and people will be fighting and killing each other for a Snickers bar. No good saving millions of people if you can't feed more than thousands. Just my $.02. :) On 10/08/2018 12:42 PM, bzs at theworld.com wrote: > I suppose since every life is precious one can measure the > effectiveness based on "land mass" but then one wonders if some sheep > out in a field in Idaho really care that the US was just invaded...put > better: You do what you can! -- .==== === -- - -- - - - - - ---. | Nate Metheny Director, Technology | | Santa Fe Institute office 505.946.2730 | | cell 505.672.8790 fax 505.982.0565 | | http://www.santafe.edu nate at santafe.edu | `--- - -- - - -- - = == ===' -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3804 bytes Desc: S/MIME Cryptographic Signature URL: From sean at donelan.com Mon Oct 8 20:37:35 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 8 Oct 2018 16:37:35 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23483.42233.795819.818838@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> <23483.42233.795819.818838@gargle.gargle.HOWL> Message-ID: On Mon, 8 Oct 2018, bzs at theworld.com wrote: > I suppose since every life is precious one can measure the > effectiveness based on "land mass" but then one wonders if some sheep > out in a field in Idaho really care that the US was just invaded...put > better: You do what you can! How quickly we forget. Puerto Rico's catastrophe was only a year ago. Per capita fatalities in rural areas are usually higher than cities after a disaster. Telecommunications are even more important in rural areas because you have fewer disaster response resources than in cities. Rural areas receive warnings later, have fewer emergency responders, fewer advanced trauma hospitals. There are more neighbors helping neighbors in cities, and more potential sources of help in densely populated areas. Telecommunication providers are less likely to spend money hardening infrastructure in rural areas, because there is less business. Its easy to find alternative telecommunications in New York City. Its hard to find backup telecommunications in Idaho. A nation-wide WEA and EAS system helps warn people in both cities and rural areas. But they still depend on carriers and broadcasters. If there are no backup batteries in cell towers, or backup transmitters for broadcasters, you end up with communication blackouts like in Puerto Rico for months. From bzs at theworld.com Mon Oct 8 21:30:01 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 8 Oct 2018 17:30:01 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> <23483.42233.795819.818838@gargle.gargle.HOWL> Message-ID: <23483.52313.601756.711559@gargle.gargle.HOWL> On October 8, 2018 at 16:37 sean at donelan.com (Sean Donelan) wrote: > A nation-wide WEA and EAS system helps warn people in both cities and > rural areas. But they still depend on carriers and broadcasters. If there > are no backup batteries in cell towers, or backup transmitters for > broadcasters, you end up with communication blackouts like in Puerto Rico > for months. Which is why it's more relevant to this list than some were grousing since people here are often the ones keeping the infrastructure this has to travel on running. The US govt should pay us all to discuss this! -- -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 aaron at heyaaron.com Tue Oct 9 03:04:46 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Mon, 8 Oct 2018 20:04:46 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: On Mon, Oct 8, 2018 at 10:54 AM Sean Donelan wrote: > There is no business case for Amazon, Apple or Google to include emergency > alerts as part of their smart speakers. I have a $50 weather alert radio. Does it have have batteries? Are they charged? Are they almost dead? When did I last hear an alert from it? Does your smoke alarm have batteries? Are they dead? When did you last test it? Google solved these problems with ~$120 smoke alarm and a decent cell phone app. If they released a new version with weather alerts, I wouldn't think twice about dropping $200 on it. So how is there no business case? No disrespect intended, but you failed to back up that statement. Perhaps I'm the only one who would spend more than $50 on a weather alert device? -A From sean at donelan.com Tue Oct 9 04:19:40 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 9 Oct 2018 00:19:40 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: On Mon, 8 Oct 2018, Aaron C. de Bruyn wrote: > Google solved these problems with ~$120 smoke alarm and a decent cell phone app. > If they released a new version with weather alerts, I wouldn't think > twice about dropping $200 on it. A company already made a combination smoke alarm/weather radio. Halo Smart Labs went out of business earlier this year. https://www.smartthings.com/products/halo-smart-labs-halo-smoke-and-carbon-monoxide-alarm-plus-weather-alerts A $120+ niche silicon valley product is great for the nerds. Whats the business case for everyone else? What's the business case for reaching 126 million households, with a product that is afforable or already part of something they already have. > So how is there no business case? No disrespect intended, but you > failed to back up that statement. More people own Amazon smart speakers than NEST thermostats. Amazon product people have told me there is no demand for emergency alerts in its Alexa product. Likewise, I've asked Google developers. They said the same thing about adding emergency alerts to their Google assistant product. > Perhaps I'm the only one who would spend more than $50 on a weather > alert device? Fewer than 5% of households buy weather radios. WEA can reach over 60% of households with cell phones. Its not 100%. Yes, 5% of households are willing to spend $50 on a weather radio. How to reach more than 5%? If you know that Google or Amazon plan to add emergency alerts to its smart assistant products, that would be great news. But so far, their product people have been very clear, they see no business case for supporting government emergency alerts on their "smart" products. From andy at andyring.com Tue Oct 9 14:20:39 2018 From: andy at andyring.com (Andy Ringsmuth) Date: Tue, 9 Oct 2018 09:20:39 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: > On Oct 8, 2018, at 11:19 PM, Sean Donelan wrote: > >> Perhaps I'm the only one who would spend more than $50 on a weather >> alert device? > > Fewer than 5% of households buy weather radios. > > WEA can reach over 60% of households with cell phones. Its not 100%. > > Yes, 5% of households are willing to spend $50 on a weather radio. How to reach more than 5%? > I’ll chime in again as I’m the original poster for this whole thread (and no I’m not with the FCC or FEMA or anything else, just an average network guy like the rest of us). My weather alert radio did not activate during this test last week. I don’t know if it was supposed to or not, but it certainly does go crazy any time there’s a weather warning issued and for the weekly tests. Yeah, this thread is getting somewhat removed from the original question, so what the heck. I’ve often thought that vehicle radios should have a location-based weather radio built in, just like the location-based regular weather radios you can buy. If I’m traveling in an unfamiliar city and the weather is looking dicey, I won’t have any idea what AM station to turn on. Or if I’m on some 2-lane highway in Nowhere, Oklahoma, etc. etc. etc. Heck, I submitted that idea to a couple aftermarket car stereo manufacturers years ago but was met with crickets. ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy at andyring.com From brandon at burn.net Tue Oct 9 14:51:27 2018 From: brandon at burn.net (Brandon Applegate) Date: Tue, 9 Oct 2018 10:51:27 -0400 Subject: Spectrum residential IPv6 rDNS - thank you ! Message-ID: Wanted to give a shoutout / thank you to Spectrum for this. Just noticed today my home PD now has dynamic/synthesized rDNS for IPv6. Some of my dumb little scripts outputs are a bit happier today ! :) -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible." From jason+nanog at lixfeld.ca Tue Oct 9 15:35:31 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 9 Oct 2018 11:35:31 -0400 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? Message-ID: Has anyone played around with this? Curious if the BCM (or whatever other chip) can do this, and if not, if any of the box vendors have tried to find a way to get these things to do a bunch of NAT - say some flavour of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but not sure if there are others out there. Thanks! From edward.dore at freethought-internet.co.uk Tue Oct 9 15:52:38 2018 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Tue, 9 Oct 2018 15:52:38 +0000 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: Message-ID: Not sure if you count Arista as whitebox given their use of merchant silicon but running their own NOS, however they were touting the 7170 series as being able to do NAT recently. That's a Barefoot Tofino chip under the hood. I've no idea how well it can do NAT or what the limitations are mind you, but it was a specific selling point that they were pushing ... Edward Dore Freethought Internet On 09/10/2018, 16:38, "NANOG on behalf of Jason Lixfeld" wrote: Has anyone played around with this? Curious if the BCM (or whatever other chip) can do this, and if not, if any of the box vendors have tried to find a way to get these things to do a bunch of NAT - say some flavour of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but not sure if there are others out there. Thanks! From jackson.tim at gmail.com Tue Oct 9 15:56:44 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 9 Oct 2018 10:56:44 -0500 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: Message-ID: The older Fulcrum/Intel FM6000 in the Arista 7150 can do NAT. -- Tim On Tue, Oct 9, 2018 at 10:54 AM Edward Dore < edward.dore at freethought-internet.co.uk> wrote: > Not sure if you count Arista as whitebox given their use of merchant > silicon but running their own NOS, however they were touting the 7170 > series as being able to do NAT recently. That's a Barefoot Tofino chip > under the hood. > > I've no idea how well it can do NAT or what the limitations are mind you, > but it was a specific selling point that they were pushing ... > > Edward Dore > Freethought Internet > > On 09/10/2018, 16:38, "NANOG on behalf of Jason Lixfeld" < > nanog-bounces at nanog.org on behalf of jason+nanog at lixfeld.ca> wrote: > > Has anyone played around with this? Curious if the BCM (or whatever > other chip) can do this, and if not, if any of the box vendors have tried > to find a way to get these things to do a bunch of NAT - say some flavour > of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for > it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but > not sure if there are others out there. > > Thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason+nanog at lixfeld.ca Tue Oct 9 16:07:19 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 9 Oct 2018 12:07:19 -0400 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: Message-ID: Indeed, however there are some other features currently missing from the Arista stack that sort of take it off the table (granted, those features have been promised early-ish next year). > On Oct 9, 2018, at 11:52 AM, Edward Dore wrote: > > Not sure if you count Arista as whitebox given their use of merchant silicon but running their own NOS, however they were touting the 7170 series as being able to do NAT recently. That's a Barefoot Tofino chip under the hood. > > I've no idea how well it can do NAT or what the limitations are mind you, but it was a specific selling point that they were pushing ... > > Edward Dore > Freethought Internet > > On 09/10/2018, 16:38, "NANOG on behalf of Jason Lixfeld" wrote: > > Has anyone played around with this? Curious if the BCM (or whatever other chip) can do this, and if not, if any of the box vendors have tried to find a way to get these things to do a bunch of NAT - say some flavour of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but not sure if there are others out there. > > Thanks! > From aaron at heyaaron.com Tue Oct 9 16:19:59 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Tue, 9 Oct 2018 09:19:59 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: On Mon, Oct 8, 2018 at 9:19 PM Sean Donelan wrote: > A company already made a combination smoke alarm/weather radio. > Halo Smart Labs went out of business earlier this year. > https://www.smartthings.com/products/halo-smart-labs-halo-smoke-and-carbon-monoxide-alarm-plus-weather-alerts *click* *buy* Thanks for the link. :) > A $120+ niche silicon valley product is great for the nerds. Whats the > business case for everyone else? I know plenty of non-nerds that live in tornado and hurricane-prone locations in the US that could also use a nice fire alarm/CO detector in their house. > What's the business case for reaching 126 million households, with a > product that is afforable or already part of something they already have. Sure--I totally agree. But we don't build smoke detectors into our cell phones because that's not a very good use case. And I'm not aware of weather alerts being broadcast to cell phones without having an app installed, and it's unreliable. (Although some already have AM/FM radios in them...) > More people own Amazon smart speakers than NEST thermostats. Amazon > product people have told me there is no demand for emergency alerts in its > Alexa product. > > Likewise, I've asked Google developers. They said the same thing about > adding emergency alerts to their Google assistant product. Maybe so. I never received a survey. Sounds like they just aren't interested in developing a 'boring' feature. > Fewer than 5% of households buy weather radios. That's...surprising to me. Any chance the majority of those 5% are in hurricane or tornado areas? *wonders what smoke alarm coverage is* > If you know that Google or Amazon plan to add emergency alerts to its > smart assistant products, that would be great news. But so far, their > product people have been very clear, they see no business case for > supporting government emergency alerts on their "smart" products. The only down-side I see to that is that my assistant products lose power immediately when the grid fails. My smoke alarm is wired, but it has a battery backup. Thanks for the info. -A From surfer at mauigateway.com Tue Oct 9 17:05:55 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 9 Oct 2018 10:05:55 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test Message-ID: <20181009100555.469AD6A0@m0117568.ppops.net> --- andy at andyring.com wrote: From: Andy Ringsmuth Yeah, this thread is getting somewhat removed from the original question, so what the heck. I’ve often thought that vehicle radios should have a location-based weather radio built in --------------------------------------------------- This is coming. See IETF's ipwave. https://www.ietfjournal.org/vehicular-networks-are-expected-to-save-lives-but-carry-privacy-risks/ https://datatracker.ietf.org/wg/ipwave/documents/ scott From cma at cmadams.net Tue Oct 9 18:00:30 2018 From: cma at cmadams.net (Chris Adams) Date: Tue, 9 Oct 2018 13:00:30 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: <20181009180030.GB20478@cmadams.net> Once upon a time, Aaron C. de Bruyn via NANOG said: > And I'm not > aware of weather alerts being broadcast to cell phones without having > an app installed, and it's unreliable. The same part of the phone that was used for the Presidential Alert can also be used for weather alerts (it is used some around here, but don't know how reliably). > *wonders what smoke alarm coverage is* Isn't that part of building code for all new houses for at least 10 years? I think it is where I live. > The only down-side I see to that is that my assistant products lose > power immediately when the grid fails. My smoke alarm is wired, but > it has a battery backup. So power your assistant from an UPS... maybe with a PoE splitter (since low-voltage Cat5 is easier to run)? -- Chris Adams From bzs at theworld.com Tue Oct 9 18:50:10 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 9 Oct 2018 14:50:10 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: <23484.63586.547033.939103@gargle.gargle.HOWL> A good home investment people don't immediately think of (I'm sure some here have) is one of those inexpensive computer UPS's. An off-the-shelf 1500VA is usually under $200 or thereabouts. One can run anything off one, like a radio or lamp. Not a lot but I'd imagine 1500VA would keep a small radio and 6W LED 100W equivalent lumens running for 24 hours? Probably more. And it'll recharge phones, batteries, etc. I run my big screen TV through one not so much for emergency backup per se but more for when they bounce the power up and down occasionally which I figure can't be good for it. But in a lengthy power outage I've shut that TV off and used it for other things I mention, there it was ready to go. For example it wouldn't be a bad holiday gift for an elderly or stupid person you know (OH DON'T REACT!) who wouldn't ever think of such a thing. Particularly if you set it up for them and showed them it's just receptacles pointing out those backed up and those not and how you should otherwise always leave it plugged and charging. Anything can be plugged in tho probably not the fridge (i.e., only small things.) And it can be carried around the house if needed (e.g., to the bedroom for a light.) -- -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 Brian at ampr.org Tue Oct 9 18:58:31 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 9 Oct 2018 11:58:31 -0700 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23484.63586.547033.939103@gargle.gargle.HOWL> References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> <23484.63586.547033.939103@gargle.gargle.HOWL> Message-ID: <20181009185830.GA68285@meow.BKantor.net> Many of those lightweight UPS units have a very small battery in them and are really designed to 1) carry the computer across a power flicker, or 2) provide a few minutes to shut down the computer in a controlled manner. Units with much bigger batteries to last a day are much more expensive and much heavier. If you're thinking of investing in one, download the manual and take a look at the runtime-vs-load chart. I believe you'll be disappointed. I was. - Brian On Tue, Oct 09, 2018 at 02:50:10PM -0400, bzs at theworld.com wrote: > > A good home investment people don't immediately think of (I'm sure > some here have) is one of those inexpensive computer UPS's. An > off-the-shelf 1500VA is usually under $200 or thereabouts. > > One can run anything off one, like a radio or lamp. Not a lot but I'd > imagine 1500VA would keep a small radio and 6W LED 100W equivalent > lumens running for 24 hours? Probably more. And it'll recharge phones, > batteries, etc. From bzs at theworld.com Tue Oct 9 19:07:53 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 9 Oct 2018 15:07:53 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <20181009180030.GB20478@cmadams.net> References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> <20181009180030.GB20478@cmadams.net> Message-ID: <23484.64649.941745.382747@gargle.gargle.HOWL> Related: Handy - I have two little boxes I bought at radio shack many years ago. One converts from the car lighter plug (or whatever they call it these days) to a three-prong (5-15R, ok?), the other converts from a regular 120V house plug to a "12V car lighter" which actually was very handy once when a house guest forgot their phone wall charger but had their car charger so I noticed was sitting in the yard with their car running charging their phone and I said "I CAN HELP YOU WITH THAT!" I believe the key word is "inverter". I can't imagine they're much more than $20 each. With a long extension cord it means even w/o a generator you can run or charge some small things off your car even if that was never the plan. -- -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 adamv0025 at netconsultings.com Fri Oct 5 11:27:24 2018 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 5 Oct 2018 12:27:24 +0100 Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ? In-Reply-To: References: Message-ID: <004d01d45c9e$64000ca0$2c0025e0$@netconsultings.com> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William > Herrin > Sent: Thursday, October 04, 2018 8:53 PM > > > - RFC 1918 for loopbacks and PTP > > - Immediately “protects” from the internet at large, as they aren’t > routable. > > - Traceroutes are miserable. > > Also breaks PMTUD which can break TCP for everybody whose packets > transit your router. So don't do this. > Only if you have lower MTU on your core links than on your edge -which is a huge design flaw. Also most of the internet backbones out there are MPLS based meaning the traceroutes are well "sparse" to say at least, so I wouldn't worry about this that much. > Another option is to let it be announced but filter the packets at your border. > That defeats the whole purpose of this exercise. Yes we all use infrastructure ACLs to protect our infrastructure, but if the infra-block is advertised the DDoS is still delivered to your doorstep even if you filter it at the edge interfaces the damage has been done already -as your upstream pipes are full. If your infra-ranges are not advertised your infrastructure simply can't be targeted by any DDoS attack. adam From thomasammon at gmail.com Sun Oct 7 01:58:53 2018 From: thomasammon at gmail.com (Tom Ammon) Date: Sat, 6 Oct 2018 21:58:53 -0400 Subject: new(ish) ipv6 transition tech status on CPE Message-ID: Are there any CPE vendors providing MAP-T features yet? I'm working on rolling v6 to residential subscribers and am trying to understand what the landscape looks like on the CPE side, for MAP-T specifically. What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been running for a while on some mobile provider networks, but are there any vendors out there with a decent/mature CLAT implementation in a CPE product that is ready to buy right now? Thanks, Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.trupel at laposte.net Sun Oct 7 09:55:23 2018 From: thomas.trupel at laposte.net (Thomas Trupel) Date: Sun, 7 Oct 2018 11:55:23 +0200 Subject: F5 contact Message-ID: <005201d45e23$deec6e50$9cc54af0$@laposte.net> Hello, I'm looking for a contact from F5 to help me reproduce a scenario to confirm a bug report (https bugzilla.mozilla.org/show_bug.cgi?id=1492843). I need a BIG-IP VE trial license without bandwidth limitation. Any help would be greatly appreciated Thank you Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Sun Oct 7 17:16:27 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Sun, 7 Oct 2018 10:16:27 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> Message-ID: <3CA067B5-16E2-4807-80BF-7D91BA5689EF@thenetworknerds.ca> I have found that the article below provides some interesting analysis on the matter which is informative as apposed to many articles which simply restate what others have already said. https://www.servethehome.com/bloomberg-reports-china-infiltrated-the-supermicro-supply-chain-we-investigate/ Thanks ~ Bryce Wilson, AS202313 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Mon Oct 8 06:09:01 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Sun, 7 Oct 2018 23:09:01 -0700 Subject: v6 DNSSEC fail, was Buying IPv4 blocks In-Reply-To: <357cc258-5816-3186-2995-1011fcc738a5@monmotha.net> References: <20181005010722.122C02006A0D69@ary.qy> <241503C5-271A-4B1D-ABC2-A5C9E5E83658@isc.org> <242a742b-f24b-fe09-5f42-89e420d048ff@monmotha.net> <9578293AE169674F9A048B2BC9A081B4030082406D@WAUPRDMBXP1.medline.com> <357cc258-5816-3186-2995-1011fcc738a5@monmotha.net> Message-ID: > On Oct 7, 2018, at 8:55 PM, Brandon Martin wrote: > > Except that, in IPv6-land, anyone with effective MTU < 1280 has the onus put on them to "make things work" i.e. come up with an adaptation layer or some sort of tunnel-layer transparent fragmentation. If you're relying on The Internet to fragment to <1280 for you, you're bound to see breakage. I'd like to think we can safely ignore this case in terms of operations. > -- > Brandon Martin I am interested in what people would suggest as the best practice for dealing with any link of a nonstandard MTU lower than 1500. It’s usually fine for end users such as those with VPNs or other tunnels, but it can cause issues when it’s on an intermediary link. I am personally involved in a project that uses links with an MTU of 1410. It’s high enough that it should not be an issue for the most part, but it does cause me some concern. It’s at an internet exchange of sorts so it could, theoretically, transit data as an intermediate link with neither side of the connection being aware of its existence. Right now we don’t have much traffic so it’s fine, but it does beg the question of what we would do if we came upon an issue. We could set a “virtual” MTU of 1500 such that it will always fragment even if DF is set, but that’s out of spec so it may be a bad idea. Thanks ~ Bryce Wilson, AS202313 From alfie at fdx.services Mon Oct 8 09:48:59 2018 From: alfie at fdx.services (Alfie Pates) Date: Mon, 08 Oct 2018 10:48:59 +0100 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> Message-ID: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> Important distinction; You fire any contractor who does it *repeatedly* after communicating the requirements for securing your data. Zero-tolerance for genuine mistakes (we all make them) just leads to high contractor turnaround and no conceivable security improvement; A a rotating door of mediocre contractors is a much larger attack surface than a small set of contractors you actively work with to improve security. ~ a On Mon, Oct 8, 2018, at 4:53 AM, Naslund, Steve wrote: > You just need to fire any contractor that allows a server with sensitive > data out to an unknown address on the Internet. Security 101. > > Steven Naslund > > >From: Eric Kuhnke > > > >many contractors *do* have sensitive data on their networks with a > gateway out to the public Internet. > >---------------------------------------- > > > >I could definitely imagine that happening. > > > >scott From spoofer-info at caida.org Mon Oct 8 17:00:03 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Mon, 8 Oct 2018 10:00:03 -0700 Subject: Spoofer Report for NANOG for Sep 2018 Message-ID: <201810081700.w98H03VC023395@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 Sep 2018: ASN Name Fixed-By 16842 5DL 2018-09-04 4 ISI 2018-09-07 2152 CSUNET-NW 2018-09-10 22742 CT-EDU-NET 2018-09-13 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Sep 2018: ASN Name First-Spoofed Last-Spoofed 5650 FRONTIER-FRTR 2016-02-22 2018-09-27 577 BACOM 2016-03-09 2018-09-27 7922 COMCAST-7922 2016-06-04 2018-09-30 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-09-28 20412 CLARITY-TELECOM 2016-09-30 2018-09-25 6181 FUSE-NET 2016-10-10 2018-09-29 15305 SYRINGANETWORKS 2016-10-21 2018-09-29 25787 ROWE-NETWORKS 2016-10-21 2018-09-26 174 COGENT-174 2016-10-21 2018-09-25 271 BCNET 2016-10-24 2018-09-26 2828 XO-AS15 2016-10-25 2018-09-20 31857 PRIORITY-TERABIT 2016-10-25 2018-09-28 30341 SCTA-ASN 2016-10-31 2018-09-30 32440 LONI 2016-11-03 2018-09-26 33182 DimeNOC 2016-11-08 2018-09-27 12083 WOW-INTERNET 2016-11-09 2018-09-29 3549 LVLT-3549 2016-11-16 2018-09-19 7106 INDEPENDENTSFIBERNETWORK 2017-01-09 2018-09-14 21832 KELLINCOM-1 2017-02-03 2018-09-29 23314 ORLANDOTELCO 2017-04-14 2018-09-01 7122 MTS-ASN 2017-05-16 2018-09-27 6461 ZAYO-6461 2017-06-21 2018-09-24 63296 AMARILLO-WIRELESS 2017-09-01 2018-09-27 7233 YAHOO-US 2017-09-07 2018-09-29 33523 ROWANUNIVERSITY 2017-10-29 2018-09-28 2152 CSUNET-NW 2017-11-08 2018-09-26 546 PARSONS-PGS-1 2017-11-20 2018-09-17 54540 INCERO 2018-01-15 2018-09-17 12222 AKAMAI 2018-02-14 2018-09-13 3257 GTT-BACKBONE 2018-03-06 2018-09-04 29384 Qatar-Foundation 2018-03-08 2018-09-30 23148 TERRENAP 2018-03-15 2018-09-25 20009 WADSNET 2018-04-13 2018-09-21 4201 ORST 2018-04-19 2018-09-14 11827 WSU 2018-04-19 2018-09-24 393564 SPOKANE 2018-06-05 2018-09-26 35911 BNQ-1 2018-06-06 2018-09-28 225 VIRGINIA 2018-06-18 2018-09-21 40911 L2NC 2018-08-31 2018-09-11 2381 WISCNET1 2018-09-04 2018-09-25 22742 CT-EDU-NET 2018-09-05 2018-09-06 54804 CSMIII-BUNKIELA 2018-09-15 2018-09-30 33452 RW 2018-09-19 2018-09-26 20448 VPNTRANET-LLC 2018-09-20 2018-09-28 11215 LOGIXCOMM 2018-09-20 2018-09-20 11996 LOBOIS 2018-09-24 2018-09-24 10326 WORCESTER-1 2018-09-26 2018-09-30 16570 TELOIP-SW-ASN 2018-09-27 2018-09-27 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 thomasammon at gmail.com Tue Oct 9 14:43:34 2018 From: thomasammon at gmail.com (Tom Ammon) Date: Tue, 9 Oct 2018 10:43:34 -0400 Subject: contact for offerup Message-ID: Can somebody from offerup.com contact me off-list regarding your blocking of our ASN (23089)? Thanks in advance, Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From endre.szabo at nanog-list-kitfvhs.redir.email Tue Oct 9 15:37:24 2018 From: endre.szabo at nanog-list-kitfvhs.redir.email (endre.szabo at nanog-list-kitfvhs.redir.email) Date: Tue, 9 Oct 2018 17:37:24 +0200 Subject: Spectrum residential IPv6 rDNS - thank you ! In-Reply-To: References: Message-ID: Hey there, On 10/9/18 4:51 PM, Brandon Applegate wrote: > Wanted to give a shoutout / thank you to Spectrum for this. Just noticed today my home PD now has dynamic/synthesized rDNS for IPv6. I wonder how they generate these rDNS PTR records? I was always curious, hope someone knows. -- Endre From sean at donelan.com Tue Oct 9 22:34:25 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 9 Oct 2018 18:34:25 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181006150909.4698A624@m0117459.ppops.net> <188348.1538882032@turing-police.cc.vt.edu> Message-ID: On Tue, 9 Oct 2018, Aaron C. de Bruyn wrote: > Sure--I totally agree. But we don't build smoke detectors into our > cell phones because that's not a very good use case. And I'm not > aware of weather alerts being broadcast to cell phones without having > an app installed, and it's unreliable. (Although some already have > AM/FM radios in them...) Since 2011, WEA has been used for over 30,000 weather alerts including tsunami, tornado, extreme wind, hurricane & typhoons. Unless you turn alerts off on your cell phone. iPhone 5 (iOS 6 and later) includes WEA. https://www.weather.gov/wrn/wea Weather alerts are the largest catagory of Wireless Emergency Alerts on cell phones. However, WEA is only used for the most severe weather alerts. WEA is built into most smart cell phones, and overcomes the congestion issues with text based Apps on cell phones. And we come full circle. No single warning system works for everything. That's why its important to have multiple warning systems or warning communication channels. Amazon Alexa is ahead of Google Assistant with weather warnings. Alexa won't proactively warn you about tornados. But if you ask "Alexa, What's the weather?" Alexa will tell you when there is a tornado warning in your area at that moment. Google Assistant only tells you the forecast, not information about active tornado warnings in your area. Siri and Cortana are very far behind both Amazon and Google. From brandon at burn.net Tue Oct 9 22:42:33 2018 From: brandon at burn.net (Brandon Applegate) Date: Tue, 9 Oct 2018 18:42:33 -0400 Subject: Spectrum residential IPv6 rDNS - thank you ! In-Reply-To: References: Message-ID: <91B015C6-7025-4FCB-8578-7E56335B53B9@burn.net> > On Oct 9, 2018, at 11:37 AM, endre.szabo at nanog-list-kitfvhs.redir.email wrote: > > Hey there, > > On 10/9/18 4:51 PM, Brandon Applegate wrote: >> Wanted to give a shoutout / thank you to Spectrum for this. Just noticed today my home PD now has dynamic/synthesized rDNS for IPv6. > > I wonder how they generate these rDNS PTR records? I was always curious, hope someone knows. > > -- I’m guessing synthesized. There are a couple of dns servers out there that can do this. An interesting one I just found: https://all-knowing-dns.zekjur.net Also my excitement was a bit premature. It seems that: 1) This is only available from one of the resolvers given out as an IPv6 DNS server (in my region at least) - 2001:1998:f00:1::1 A dig +trace from the internet at large only gets to the NXDOMAIN (which is still much better than a SERVFAIL). 2) Looks like 2001:1998:f00:1::1 is anycasted (as one would expect). However not all of the instances will consistently return a PTR. # Simply running dig a handful of times to hit the different anycast boxes… # vom at ice:~$ dig +short @2001:1998:f00:1::1 -x 2607:fcc8:1234:5678::1234 cpe-2607-FCC8-1234-5678-0-0-0-1234.dyn6.twc.com. vom at ice:~$ dig +short @2001:1998:f00:1::1 -x 2607:fcc8:1234:5678::1234 cpe-2607-FCC8-1234-5678-0-0-0-1234.dyn6.twc.com. vom at ice:~$ dig +short @2001:1998:f00:1::1 -x 2607:fcc8:1234:5678::1234 cpe-2607-FCC8-1234-5678-0-0-0-1234.dyn6.twc.com. vom at ice:~$ dig +short @2001:1998:f00:1::1 -x 2607:fcc8:1234:5678::1234 vom at ice:~$ dig +short @2001:1998:f00:1::1 -x 2607:fcc8:1234:5678::1234 vom at ice:~$ dig +short @2001:1998:f00:1::1 -x 2607:fcc8:1234:5678::1234 cpe-2607-FCC8-1234-5678-0-0-0-1234.dyn6.twc.com. I checked 2001:1998:f00:1::1 via whoami.akamai.net and got back a handful of unique IPs. I’m guessing some inconsistent config or something else has broken on some of the instances... -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible." From sean at donelan.com Wed Oct 10 01:38:27 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 9 Oct 2018 21:38:27 -0400 (EDT) Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <20181009100555.469AD6A0@m0117568.ppops.net> References: <20181009100555.469AD6A0@m0117568.ppops.net> Message-ID: On Tue, 9 Oct 2018, Scott Weeks wrote: > --- andy at andyring.com wrote: > From: Andy Ringsmuth > > Yeah, this thread is getting somewhat removed from the > original question, so what the heck. I’ve often thought > that vehicle radios should have a location-based weather > radio built in > --------------------------------------------------- > This is coming. See IETF's ipwave. Your radio could pickup information that's being broadcast all the time. If your car has a builtin navigation systems (figuring out its location is the hard part for the radio -- cell phones already have geolocation builtin), HD radio stations send a lot of digital information in the subcarriers. https://github.com/KYDronePilot/hdfm hdfm displays weather and traffic maps received from iHeartRadio HD radio stations. It relies on nrsc5 to decode and dump the radio station data for it to process and display. Likewise, SiriusXM satellite data services has advanced digital data weather feeds as part of its aviation packages. You could install it in your car instead of your airplane. If you can afford a private airplane, you can afford the SiriusXM aviation subscription cost. The challenging part for government is creating a public warning system inexpensive enough, its available to everyone, not just people who can afford private airplanes. From andy at mbrez.com Wed Oct 10 01:59:21 2018 From: andy at mbrez.com (Andy Brezinsky) Date: Tue, 9 Oct 2018 20:59:21 -0500 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <20181009100555.469AD6A0@m0117568.ppops.net> Message-ID: <15a50867-bbb2-d5ac-8c5c-4df88b638bb0@mbrez.com> > The challenging part for government is creating a public warning > system inexpensive enough, its available to everyone, not just people > who can afford private airplanes. We could use the one that was already built for this: The NOAA All Hazards radio network (http://www.nws.noaa.gov/nwr/).  It uses 7 nationwide frequencies and 1025 radio transmitters to cover 95% of the US. It costs around $20 for a basic receiver.  A car could easily just listen to the 7 frequencies and wait for the alert tones.  If you want to get fancy you could overlay GPS to detect the county and use that to filter the alerts to the county you're currently in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcorbe at hammerfiber.com Wed Oct 10 05:06:17 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Wed, 10 Oct 2018 01:06:17 -0400 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: (Tom Ammon's message of "Sat, 6 Oct 2018 21:58:53 -0400") References: Message-ID: <87tvluxueu.fsf@hammerfiber.com> Tom Ammon writes: > Are there any CPE vendors providing MAP-T features yet? I'm working on rolling v6 to residential subscribers and am trying to > understand what the landscape looks like on the CPE side, for MAP-T specifically. > > What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been running for a while on some mobile provider networks, > but are there any vendors out there with a decent/mature CLAT implementation in a CPE product that is ready to buy right now? > Good luck. I've been barking up the MAP-T tree with cable modem vendors for a couple of years already. Since I have literally 0 buying power in comparison to the likes of Comcast and Cox, I've gotten nowhere. -Daniel From jordi.palet at consulintel.es Wed Oct 10 06:50:04 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 10 Oct 2018 08:50:04 +0200 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: Message-ID: <3AEE9DE2-A1E0-4BCE-B65E-067591B5A563@consulintel.es> You may use this document, which passed already the last-call and is in the AD/IESG review: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ My co-authors may help you to get those products … I’ve been using myself OpenWRT for such deployments. Regards, Jordi De: NANOG en nombre de Tom Ammon Fecha: miércoles, 10 de octubre de 2018, 0:14 Para: NANOG Asunto: new(ish) ipv6 transition tech status on CPE Are there any CPE vendors providing MAP-T features yet? I'm working on rolling v6 to residential subscribers and am trying to understand what the landscape looks like on the CPE side, for MAP-T specifically. What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been running for a while on some mobile provider networks, but are there any vendors out there with a decent/mature CLAT implementation in a CPE product that is ready to buy right now? Thanks, Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Wed Oct 10 07:57:50 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 10 Oct 2018 10:57:50 +0300 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> Message-ID: Hey, > Important distinction; You fire any contractor who does it *repeatedly* after communicating the requirements for securing your data. > > Zero-tolerance for genuine mistakes (we all make them) just leads to high contractor turnaround and no conceivable security improvement; A a rotating door of mediocre contractors is a much larger attack surface than a small set of contractors you actively work with to improve security. +1. Changing people is a cop out, and often blame shifting. Believing you have better people than your competitor is dangerous. Creating environment where humans can succeed is far harder than creating environment where humans systematically fail. -- ++ytti From mdavids at forfun.net Wed Oct 10 08:09:52 2018 From: mdavids at forfun.net (Marco Davids) Date: Wed, 10 Oct 2018 10:09:52 +0200 Subject: Spectrum residential IPv6 rDNS - thank you ! In-Reply-To: <91B015C6-7025-4FCB-8578-7E56335B53B9@burn.net> References: <91B015C6-7025-4FCB-8578-7E56335B53B9@burn.net> Message-ID: <1ee63112-a091-2aa0-467d-e15ee9708601@forfun.net> Op 10-10-18 om 00:42 schreef Brandon Applegate: > I’m guessing synthesized. There are a couple of dns servers out there that can do this. An interesting one I just found: > > https://all-knowing-dns.zekjur.net Or, if you prefer DNSSEC capable alternatives, try: https://github.com/cmouse/pdns-v6-autorev https://www.knot-dns.cz/docs/2.4/html/modules.html -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From endre.szabo at nanog-list-kitfvhs.redir.email Wed Oct 10 08:48:44 2018 From: endre.szabo at nanog-list-kitfvhs.redir.email (endre.szabo at nanog-list-kitfvhs.redir.email) Date: Wed, 10 Oct 2018 10:48:44 +0200 Subject: Spectrum residential IPv6 rDNS - thank you ! In-Reply-To: <1ee63112-a091-2aa0-467d-e15ee9708601@forfun.net> References: <91B015C6-7025-4FCB-8578-7E56335B53B9@burn.net> <1ee63112-a091-2aa0-467d-e15ee9708601@forfun.net> Message-ID: Hey there, On 10/10/18 10:09 AM, Marco Davids via NANOG wrote: > Op 10-10-18 om 00:42 schreef Brandon Applegate: > >> I’m guessing synthesized.  There are a couple of dns servers out >> there that can do this.  An interesting one I just found: >> >> https://all-knowing-dns.zekjur.net > > Or, if you prefer DNSSEC capable alternatives, try: > > https://github.com/cmouse/pdns-v6-autorev > https://www.knot-dns.cz/docs/2.4/html/modules.html > Thank you guys. It was just a false naive question to check if anyone's gonna mention my repository called > PowerDNS pipe dynamic backend to serve dnswall style A, AAAA and PTR > DNS records for any given CIDR ranges. which is up there since 2011. https://github.com/endreszabo/PowerDNS-Dynamic-Reverse-Backend -- Endre From Philip.Loenneker at tasmanet.com.au Wed Oct 10 00:24:58 2018 From: Philip.Loenneker at tasmanet.com.au (Philip Loenneker) Date: Wed, 10 Oct 2018 00:24:58 +0000 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: Message-ID: Hi Tom, This article is now 11 months old, but may be of interest to you: https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/ Some quotes: * The major issue is the lack of support provided by CE vendors for both older (DS-Lite, lw4o6), and newer (464XLAT, MAP T/E) transition mechanisms. Some vendors provide it ‘on-demand’ for big customers, but small and medium ISPs don’t have the same purchasing capability, creating a big issue for deployment. * All panellists said their service providers’ products supported lw4o6, MAP-E/T, and 464XLAT, but because of the lack of support for these mechanisms in RFC7084, it is not standard in retail CE. * There are no new hardware requirements that will exclude vendors supporting all these transitions mechanisms — it is really a matter of very few kilobytes. * The panel agreed that minimum orders were not considered when implementing these mechanisms. For them, the fact is that IPv6 needs to be implemented, and there is a need to support new transition mechanisms and support service providers and retail users. Also, there is a need for products to pass some certification requirements (again the idea of RFC7084-bis is strongly supported by the panellists). Telstra did a presentation as AusNOG back in September discussing their IPv6 implementation which was really great to see. They have their own branded CPEs with 464XLAT. Unfortunately I don’t think there is a video of it, only a rather short slide deck. You can see it here: https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.8_David_Woolley_AusNOG2018.pdf I have asked several vendors we deal with about the newer technologies such as 464XLAT, and have had some responses indicating they will investigate internally, however we have not made much progress yet. One vendor suggested their device supports NAT46 and NAT64 so may support 464XLAT, but since it is incidental rather than an official feature, it may not support the full CLAT requirements. I have been meaning to do some tests but haven’t had a chance yet. It is also a higher price point than our current CPEs. I have spoken to people who have looked into options such as OpenWRT (which supports several of these technolgoies), however the R&D and ongoing support is a significant roadblock to overcome. I would like to hear how others are implementing these transition technologies. Regards, Philip From: NANOG On Behalf Of Tom Ammon Sent: Sunday, 7 October 2018 12:59 PM To: NANOG Subject: new(ish) ipv6 transition tech status on CPE Are there any CPE vendors providing MAP-T features yet? I'm working on rolling v6 to residential subscribers and am trying to understand what the landscape looks like on the CPE side, for MAP-T specifically. What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been running for a while on some mobile provider networks, but are there any vendors out there with a decent/mature CLAT implementation in a CPE product that is ready to buy right now? Thanks, Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at shthead.com Wed Oct 10 01:43:33 2018 From: lists at shthead.com (Chris) Date: Wed, 10 Oct 2018 09:43:33 +0800 Subject: Spectrum residential IPv6 rDNS - thank you ! In-Reply-To: References: Message-ID: Hi, On 9/10/2018 11:37 PM, endre.szabo at nanog-list-kitfvhs.redir.email wrote: > I wonder how they generate these rDNS PTR records? I was always curious, > hope someone knows. I do it for our various IPv6 (and IPv4) allocations by using PowerDNS with a remote backend. If there is no existing PTR record defined the query gets sent to the remote backend which generates the PTR based on the IP address. The same thing happens for A/AAAA record requests, if the A/AAAA record for the PTR does not exist it will also be generated based off the hostname provided as long as the hostname matches a record that would have an automatic PTR generated. Originally I was using the pipe backend with a modified copy of "PowerDNS-Dynamic-Reverse-Backend" (https://github.com/endreszabo/PowerDNS-Dynamic-Reverse-Backend) but ended up writing my own in Perl as the backend was a bit fragile and didn't do everything I wanted. From SNaslund at medline.com Wed Oct 10 14:21:40 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 14:21:40 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> Allowing an internal server with sensitive data out to "any" is a serious mistake and so basic that I would fire that contractor immediately (or better yet impose huge monetary penalties. As long as your security policy is defaulted to "deny all" outbound that should not be difficult to accomplish. Maybe if a couple contractors feel the pain, they will straighten up. The requirements for securing government sensitive data is communicated very clearly in contractual documents. Genuine mistake can get you in very deep trouble within the military and should apply to contractors as well. I can tell you that the "oh well, it's just a mistake" gets used far too often and its why your personal data is getting compromised over and over again by all kinds of entities. For example, with tokenization there is no reason at all for any retailer to be storing your credit card data (card number, CVV, exp date) at all (let alone unencrypted) but it keeps happening over and over. There needs to be consequences especially for contractors in the age of cyber warfare. Steven Naslund Chicago IL > Important distinction; You fire any contractor who does it *repeatedly* after communicating the requirements for securing your data. > > Zero-tolerance for genuine mistakes (we all make them) just leads to high contractor turnaround and no conceivable security improvement; A a rotating door of mediocre contractors is a much larger >attack surface than a small set of contractors you actively work with to improve security. From Brian at ampr.org Wed Oct 10 14:32:14 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 10 Oct 2018 07:32:14 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> Message-ID: <20181010143214.GA73218@meow.BKantor.net> On Wed, Oct 10, 2018 at 02:21:40PM +0000, Naslund, Steve wrote: > For example, with tokenization there is no reason at all for any > retailer to be storing your credit card data (card number, CVV, exp > date) at all (let alone unencrypted) but it keeps happening over > and over. It's been a while since I've had to professionally worry about this, but as I recall, compliance with PCI [Payment Card Industry] Data Security Standards prohibit EVER storing the CVV. Companies which do may find themselves banned from being able to process card payments if they're found out (which is unlikely). - Brian From sean at donelan.com Wed Oct 10 14:36:29 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 10 Oct 2018 10:36:29 -0400 (EDT) Subject: DHS: Report on Alerting Tactics Message-ID: Communication service providers play a critical role, but too often view public alerting as "someone else's job." https://www.dhs.gov/sites/default/files/publications/1051_IAS_Report-on-Alerting-Tactics_180807-508.pdf Report on Alerting Tactics August 7, 2018 However, there was not consensus on which combination of tools is generally most effective. The alerting ecosystem consists of multiple systems alert originators can use to reach the public with alert and warning information, “as well as diverse channels of message delivery, distributed sensing devices, and feedback mechanisms.” Alerting ecosystem components include: • Alerts and warnings from Federal, state, and local alerting authorities to the public; • Coordination between alerting authorities and other governmental entities (e.g., 911); • Public information sharing to alerting authorities (e.g., social media requests); and • Public information exchange between community members From SNaslund at medline.com Wed Oct 10 14:39:59 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 14:39:59 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181010143214.GA73218@meow.BKantor.net> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC509A@MUNPRDMBXA1.medline.com> Yet this data gets compromised again and again, and I know for a fact that the CVV was compromised in at least four cases I personally am aware of. As long as the processors are getting the money, do you really think they are going to kick out someone like Macy's or Home Depot? After all, it is really only an inconvenience to you and neither of them care much about that. Steve >It's been a while since I've had to professionally worry about this, >but as I recall, compliance with PCI [Payment Card Industry] Data >Security Standards prohibit EVER storing the CVV. Companies which >do may find themselves banned from being able to process card >payments if they're found out (which is unlikely). > - Brian From cb.list6 at gmail.com Wed Oct 10 14:57:02 2018 From: cb.list6 at gmail.com (Ca By) Date: Wed, 10 Oct 2018 07:57:02 -0700 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: Message-ID: On Wed, Oct 10, 2018 at 6:50 AM Philip Loenneker < Philip.Loenneker at tasmanet.com.au> wrote: > Hi Tom, > > > > This article is now 11 months old, but may be of interest to you: > > https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/ > > > > Some quotes: > > - The major issue is the lack of support provided by CE vendors for > both older (DS-Lite, lw4o6), and newer (464XLAT, MAP T/E) transition > mechanisms. Some vendors provide it ‘on-demand’ for big customers, but > small and medium ISPs don’t have the same purchasing capability, creating a > big issue for deployment. > - All panellists said their service providers’ products supported > lw4o6, MAP-E/T, and 464XLAT, but because of the lack of support for these > mechanisms in RFC7084, it is not standard in retail CE. > - There are no new hardware requirements that will exclude vendors > supporting all these transitions mechanisms — it is really a matter of very > few kilobytes. > - The panel agreed that minimum orders were not considered when > implementing these mechanisms. For them, the fact is that IPv6 needs to be > implemented, and there is a need to support new transition mechanisms and > support service providers and retail users. Also, there is a need for > products to pass some certification requirements (again the idea of > RFC7084-bis is strongly supported by the panellists). > > > > Telstra did a presentation as AusNOG back in September discussing their > IPv6 implementation which was really great to see. They have their own > branded CPEs with 464XLAT. Unfortunately I don’t think there is a video of > it, only a rather short slide deck. You can see it here: > > > https://www.ausnog.net/sites/default/files/ausnog-2018/presentations/2.8_David_Woolley_AusNOG2018.pdf > > > > I have asked several vendors we deal with about the newer technologies > such as 464XLAT, and have had some responses indicating they will > investigate internally, however we have not made much progress yet. One > vendor suggested their device supports NAT46 and NAT64 so may support > 464XLAT, but since it is incidental rather than an official feature, it may > not support the full CLAT requirements. I have been meaning to do some > tests but haven’t had a chance yet. It is also a higher price point than > our current CPEs. > > > > I have spoken to people who have looked into options such as OpenWRT > (which supports several of these technolgoies), however the R&D and ongoing > support is a significant roadblock to overcome. > > > > I would like to hear how others are implementing these transition > technologies. > > > Just my own personal musing below There several mobile providers that planning to use 5G/4G for home broadband. Some are going to focus on urban areas while others will focus on rural areas. My expectation is that that these mobile providers will bring their existing mobile approach to the wireless home broadband space. That said, i believe 464XLAT specifically will be used in home router deployments that will have a mobile modem. These devices are likely to look more like home gateways than existing mobile hotspot pucks. Regards, > > Philip > > > > > > *From:* NANOG *On Behalf Of *Tom Ammon > *Sent:* Sunday, 7 October 2018 12:59 PM > *To:* NANOG > *Subject:* new(ish) ipv6 transition tech status on CPE > > > > Are there any CPE vendors providing MAP-T features yet? I'm working on > rolling v6 to residential subscribers and am trying to understand what the > landscape looks like on the CPE side, for MAP-T specifically. > > > > What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has > been running for a while on some mobile provider networks, but are there > any vendors out there with a decent/mature CLAT implementation in a CPE > product that is ready to buy right now? > > > > Thanks, > > Tom > > > > -- > > > ----------------------------------------------------------------------------- > Tom Ammon > M: (801) 784-2628 > thomasammon at gmail.com > > ----------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Wed Oct 10 14:58:08 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 10 Oct 2018 14:58:08 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC509A@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC509A@MUNPRDMBXA1.medline.com> Message-ID: <614790F8-A2D6-4DC1-9507-D804D2660C18@dino.hostasaurus.com> They actually profit from fraud; and my theory is that that's why issuers have mostly ceased allowing consumers to generate one time use card numbers via portal or app, even though they claim it's simply because "you're not responsible for fraud." When a stolen credit card is used, the consumer disputes the resulting fraudulent charges. The dispute makes it to the merchant account issuer, who then takes back the money their merchant had collected, and generally adds insult to injury by charging the merchant a chargeback fee for having to deal with the issue (Amex is notable for not doing this). The fee is often as high as $20, so the merchant loses whatever merchandise or service they sold, loses the money, and pays the merchant account bank a fee on top of that. Regarding CVV; PCI permits it being stored 'temporarily', but with specific conditions on how that are far more restrictive than the card number. Suffice it to say, it should not be possible for an intrusion to obtain it, and we know how that goes.... These days javascript being inserted on the payment page of a compromised site, to steal the card in real time, is becoming a more common occurrence than actually breaching an application or database. Websites have so much third party garbage loaded into them now, analytics, social media, PPC ads, etc. that it's nearly impossible to know what should or shouldn't be present, or if a given block of JS is sending the submitted card in parallel to some other entity. There's technologies like subresource integrity to ensure the correct code is served by a given page, but that doesn't stop someone from replacing the page, etc. On 10/10/18, 10:41 AM, "NANOG on behalf of Naslund, Steve" wrote: Yet this data gets compromised again and again, and I know for a fact that the CVV was compromised in at least four cases I personally am aware of. As long as the processors are getting the money, do you really think they are going to kick out someone like Macy's or Home Depot? After all, it is really only an inconvenience to you and neither of them care much about that. Steve >It's been a while since I've had to professionally worry about this, >but as I recall, compliance with PCI [Payment Card Industry] Data >Security Standards prohibit EVER storing the CVV. Companies which >do may find themselves banned from being able to process card >payments if they're found out (which is unlikely). > - Brian From SNaslund at medline.com Wed Oct 10 15:06:30 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 15:06:30 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <23483.52313.601756.711559@gargle.gargle.HOWL> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> <23483.42233.795819.818838@gargle.gargle.HOWL> <23483.52313.601756.711559@gargle.gargle.HOWL> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6497@MUNPRDMBXA1.medline.com> I am wondering if this seems common to most of you on here. In my area it seems that all cellular sites have backup generators and battery backup. Seems like the biggest issues we see are devices remote from the central offices that lose power and cause disruptions, like RSTs and SLCs. During hurricane Katrina we saw a lot of active outside plant devices underwater and that caused lots of disruption even when the CO survived. Steven Naslund Chicago IL >On October 8, 2018 at 16:37 sean at donelan.com (Sean Donelan) wrote: > A nation-wide WEA and EAS system helps warn people in both cities and > rural areas. But they still depend on carriers and broadcasters. If there > are no backup batteries in cell towers, or backup transmitters for > broadcasters, you end up with communication blackouts like in Puerto Rico > for months. From bill at herrin.us Wed Oct 10 15:09:39 2018 From: bill at herrin.us (William Herrin) Date: Wed, 10 Oct 2018 11:09:39 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> Message-ID: On Wed, Oct 10, 2018 at 10:22 AM Naslund, Steve wrote: > Allowing an internal server with sensitive data out to "any" is > a serious mistake and so basic that I would fire that contractor > immediately (or better yet impose huge monetary penalties. > As long as your security policy is defaulted to "deny all" outbound > that should not be difficult to accomplish. Hi Steve, I respectfully disagree. Deny-all-permit-by-exception incurs a substantial manpower cost both in terms of increasing the number of people needed to do the job and in terms of the reducing quality of the people willing to do the job: deny-all is a more painful environment to work in and most of us have other options. As with all security choices, that cost has to be balanced against the risk-cost of an incident which would otherwise have been contained by the deny-all rule. Indeed, the most commonplace security error is spending more resources securing something than the risk-cost of an incident. By voluntarily spending the money you've basically done the attacker's damage for them! Except with the most sensitive of data, an IDS which alerts security when an internal server generates unexpected traffic can establish risk-costs much lower than the direct and indirect costs of a deny-all rule. Thus rejecting the deny-all approach as part of a balanced and well conceived security plan is not inherently an error and does not necessarily recommend firing anyone. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Wed Oct 10 15:13:18 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 15:13:18 +0000 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> <23483.42233.795819.818838@gargle.gargle.HOWL> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC64C8@MUNPRDMBXA1.medline.com> I agree 100% and also have noticed that severe weather systems tend to more severe in rural areas due to either open spaces (the plains) or trees (forested areas) doing more damage. I can tell you from living the in Midwest that the storms in Iowa and Nebraska are way worse than the ones that hit Chicago. A weather guy I know told me it has something to do with convective heat rising from major cities which is why you rarely see tornados hitting downtown Chicago and New York. I have noticed that for some reason local weather alerts seem to be more reliable than the national level tests on cellular. Don't know if it has to do with shear volume or what. Also, like I said earlier in rural areas you are less likely to run into a bystander that knows what is going on. Steven Naslund Chicago IL >How quickly we forget. Puerto Rico's catastrophe was only a year ago. >Per capita fatalities in rural areas are usually higher than cities after >a disaster. Telecommunications are even more important in rural areas >because you have fewer disaster response resources than in cities. >Rural areas receive warnings later, have fewer emergency responders, fewer >advanced trauma hospitals. There are more neighbors helping neighbors in >cities, and more potential sources of help in densely populated areas. > >Telecommunication providers are less likely to spend money hardening >infrastructure in rural areas, because there is less business. Its easy >to find alternative telecommunications in New York City. Its hard to find >backup telecommunications in Idaho. > >A nation-wide WEA and EAS system helps warn people in both cities and >rural areas. But they still depend on carriers and broadcasters. If there >are no backup batteries in cell towers, or backup transmitters for >broadcasters, you end up with communication blackouts like in Puerto Rico >for months. From SNaslund at medline.com Wed Oct 10 15:25:02 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 15:25:02 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> You are free to disagree all you want with the default deny-all policy but it is a DoD 5200.28-STD requirement and NSA Orange Book TCSEC requirement. It is baked into all approved secure operating systems including SELINUX so it is really not open for debate if you have meet these requirements. Remember we were talking about Intel agency systems here, not the general public. It is SUPPOSED to be painful to open things to the Internet in those environments. It needs to take an affirmative act to do so. It is a simple matter of knowing what each and every connection outside the network is there for. It also reveals application vulnerabilities and compromises as well as making it easy to identify apps that are compromised. In several of the corporate networks I have worked on, they had differing policies for different network zones. For example, you might allow your users out to anywhere on the Internet (at least for common public protocols like HTTP/HTTPS) but not allow any servers out to the Internet except where they are in a DMZ offering public services or destination required for support (like patching and remote updates). Seemed like good workable policy. Steven Naslund Chicago IL >Hi Steve, > >I respectfully disagree. > >Deny-all-permit-by-exception incurs a substantial manpower cost both >in terms of increasing the number of people needed to do the job and >in terms of the reducing quality of the people willing to do the job: >deny-all is a more painful environment to work in and most of us have >other options. As with all security choices, that cost has to be >balanced against the risk-cost of an incident which would otherwise >have been contained by the deny-all rule. > >Indeed, the most commonplace security error is spending more resources >securing something than the risk-cost of an incident. By voluntarily >spending the money you've basically done the attacker's damage for >them! > >Except with the most sensitive of data, an IDS which alerts security >when an internal server generates unexpected traffic can establish >risk-costs much lower than the direct and indirect costs of a deny-all >rule. > >Thus rejecting the deny-all approach as part of a balanced and well >conceived security plan is not inherently an error and does not >necessarily recommend firing anyone. > >Regards, >Bill Herrin From ahebert at pubnix.net Wed Oct 10 15:27:52 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 10 Oct 2018 11:27:52 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181010143214.GA73218@meow.BKantor.net> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> Message-ID:     Well,     Once you get the Expiry Date (which is the most prevalent data that is not encoded with the CHD)     CVV is only 3 digits, we saw ppl using parallelizing tactics to find the correct sequence using acquirers around the world.     With the delays in the reporting pipeline, they have the time to completely abuse that CHD/Date/CVV before getting caught. For chipless markets ( You know who you are )     I'm way more worried about Pinpads carrying Track1+Track2 unencrypted thru Serial, USB, Bluetooth, Wireless custom connection...     ( I snooped Serial, USB, Bluetooth for a Pinpad PA-DSS project )     And with the PA-DSS spec being dropped by 2020 it will become worst. ----- 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 10/10/18 10:32, Brian Kantor wrote: > On Wed, Oct 10, 2018 at 02:21:40PM +0000, Naslund, Steve wrote: >> For example, with tokenization there is no reason at all for any >> retailer to be storing your credit card data (card number, CVV, exp >> date) at all (let alone unencrypted) but it keeps happening over >> and over. > It's been a while since I've had to professionally worry about this, > but as I recall, compliance with PCI [Payment Card Industry] Data > Security Standards prohibit EVER storing the CVV. Companies which > do may find themselves banned from being able to process card > payments if they're found out (which is unlikely). > - Brian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahebert at pubnix.net Wed Oct 10 15:31:07 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 10 Oct 2018 11:31:07 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> Message-ID: <87de86a3-9876-2dbc-3f9e-b47c5dd5d1f0@pubnix.net>     Well, ( I'm sorry but I cannot resist )     Seriously mate, trolling this list using "deny-all is bad m'kay" is not a good idea. ----- 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 10/10/18 11:09, William Herrin wrote: > On Wed, Oct 10, 2018 at 10:22 AM Naslund, Steve wrote: >> Allowing an internal server with sensitive data out to "any" is >> a serious mistake and so basic that I would fire that contractor >> immediately (or better yet impose huge monetary penalties. >> As long as your security policy is defaulted to "deny all" outbound >> that should not be difficult to accomplish. > Hi Steve, > > I respectfully disagree. > > Deny-all-permit-by-exception incurs a substantial manpower cost both > in terms of increasing the number of people needed to do the job and > in terms of the reducing quality of the people willing to do the job: > deny-all is a more painful environment to work in and most of us have > other options. As with all security choices, that cost has to be > balanced against the risk-cost of an incident which would otherwise > have been contained by the deny-all rule. > > Indeed, the most commonplace security error is spending more resources > securing something than the risk-cost of an incident. By voluntarily > spending the money you've basically done the attacker's damage for > them! > > Except with the most sensitive of data, an IDS which alerts security > when an internal server generates unexpected traffic can establish > risk-costs much lower than the direct and indirect costs of a deny-all > rule. > > Thus rejecting the deny-all approach as part of a balanced and well > conceived security plan is not inherently an error and does not > necessarily recommend firing anyone. > > Regards, > Bill Herrin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Oct 10 15:55:27 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 15:55:27 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> The entire point of the CVV has become useless. Recently my wife was talking to an airline ticket agent on the phone (American Airlines) and one of the things they ask for on the phone is the CVV. If you are going to read that all out over the phone with all the other data you are completely vulnerable to fraud. It would be trivial to implement a system where you make a charge over the phone like that and get a text asking you to authorize it instead of asking for a CVV. After all this time it is stupid to have the same data being used over and over. We have had SecurID and other token/pin systems in the IT world forever. I have a token on my iPhone right now that I use for certain logins to systems. The hardware tokens cost very little (especially compared to the credit card companies revenue). The soft tokens are virtually free. A token should be useful for one and only one transaction. You would be vulnerable from the time you read your token to someone (or something) until the charge hit your account. You would also not have to worry about a call center agent or waiter stealing that data because it could only be used once (and if it is not their employer it would become apparent really quickly). Recurring transactions should be unique tokens for a set amount range from a particular entity (i.e. 12 transactions, one per month, not more than $500 each, Comcast only). For example, my reusable token given to my cable company should not be usable by anyone else. Why hasn’t this been done yet…..simple there is no advantage to the retailers and processors. There has been some one-time use numbers for stuff like that but it is inconvenient for the user so it won’t be that popular. The entire system is archaic and dates back to the time of imprinting on paper. Tokenized transactions exist today between some entities and the processors but it is time to extend that all the way from card holder to processor. Steven Naslund Chicago IL > Well, > Once you get the Expiry Date (which is the most prevalent data that is not encoded with the CHD) > CVV is only 3 digits, we saw ppl using parallelizing tactics to find the correct sequence using acquirers around the world. > With the delays in the reporting pipeline, they have the time to completely abuse that CHD/Date/CVV before getting caught. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Wed Oct 10 15:55:47 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 15:55:47 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <614790F8-A2D6-4DC1-9507-D804D2660C18@dino.hostasaurus.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC509A@MUNPRDMBXA1.medline.com> <614790F8-A2D6-4DC1-9507-D804D2660C18@dino.hostasaurus.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC658D@MUNPRDMBXA1.medline.com> Having gone through this I know that it's all on you which is why no one really cares. You have to notice a fraudulent charge (in most cases), you have to dispute it, you have to prove it was not you that made the charge, and if they agree then they change all of your numbers at which point you have to contact everyone that might be auto charging your accounts for you. It is a super pain in the neck. So many merchants have been compromised that it seems to be having less and less impact on their reputation. >They actually profit from fraud; and my theory is that that's why issuers have mostly ceased allowing consumers to generate one time use card numbers via portal or app, even though they claim it's >simply because "you're not responsible for fraud." When a stolen credit card is used, the consumer disputes the resulting fraudulent charges. The dispute makes it to the merchant account issuer, who >then takes back the money their merchant had collected, and generally adds insult to injury by charging the merchant a chargeback fee for having to deal with the issue (Amex is notable for not doing >this). The fee is often as high as $20, so the merchant loses whatever merchandise or service they sold, loses the money, and pays the merchant account bank a fee on top of that. > >Regarding CVV; PCI permits it being stored 'temporarily', but with specific conditions on how that are far more restrictive than the card number. Suffice it to say, it should not be possible for an >intrusion to obtain it, and we know how that goes.... > >These days javascript being inserted on the payment page of a compromised site, to steal the card in real time, is becoming a more common occurrence than actually breaching an application or database. >Websites have so much third party garbage loaded into them now, analytics, social media, PPC ads, etc. that it's nearly impossible to know what should or shouldn't be present, or if a given block of JS >is sending the submitted card in parallel to some other entity. There's technologies like subresource integrity to ensure the correct code is served by a given page, but that doesn't stop someone from >replacing the page, etc. From SNaslund at medline.com Wed Oct 10 16:01:07 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 16:01:07 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> Sure and with the Exp Date, CVV, and number printed on every card you are open to compromise every time you stay in the hotel or go to a restaurant where you hand someone your card. Worse yet, the only option if you are compromised is to change all your numbers and put the burden on your of notifying everyone and that evening you hand your card to the waiter and the cycle starts over. The system is so monumentally stupid it’s unbelievable. Steven Naslund Chicago IL > Well, > Once you get the Expiry Date (which is the most prevalent data that is not encoded with the CHD) > CVV is only 3 digits, we saw ppl using parallelizing tactics to find the correct sequence using acquirers around the world. > With the delays in the reporting pipeline, they have the time to completely abuse that CHD/Date/CVV before getting caught. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian at ampr.org Wed Oct 10 16:17:37 2018 From: Brian at ampr.org (Brian Kantor) Date: Wed, 10 Oct 2018 09:17:37 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> Message-ID: <20181010161737.GA74135@meow.BKantor.net> I understand that in some countries the common practice is that the waiter or clerk brings the card terminal to you or you go to it at the cashier's desk, and you insert or swipe it, so the card never leaves your hand. And you have to enter the PIN as well. This seems notably more secure against point-of-sale compromise. - Brian On Wed, Oct 10, 2018 at 04:01:07PM +0000, Naslund, Steve wrote: > Sure and with the Exp Date, CVV, and number printed on every card you are open to compromise every time you stay in the hotel or go to a restaurant where you hand someone your card. Worse yet, the only option if you are compromised is to change all your numbers and put the burden on your of notifying everyone and that evening you hand your card to the waiter and the cycle starts over. The system is so monumentally stupid it’s unbelievable. > > Steven Naslund > > Chicago IL From ops.lists at gmail.com Wed Oct 10 16:22:17 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 10 Oct 2018 21:52:17 +0530 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181010161737.GA74135@meow.BKantor.net> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> <20181010161737.GA74135@meow.BKantor.net> Message-ID: This is common in India but then chip and pin has been mandatory for a good few years, as has 2fa (vbv / mastercard secure code) for online transactions. Waiters would earlier ask for people's pins so they could go back and enter it - back when a lot of the POS terminals were connected to POTS lines rather than battery operated + with a GSM sim. That's stopped now as people grew more aware. On 10/10/18, 9:49 PM, "NANOG on behalf of Brian Kantor" wrote: I understand that in some countries the common practice is that the waiter or clerk brings the card terminal to you or you go to it at the cashier's desk, and you insert or swipe it, so the card never leaves your hand. And you have to enter the PIN as well. This seems notably more secure against point-of-sale compromise. - Brian On Wed, Oct 10, 2018 at 04:01:07PM +0000, Naslund, Steve wrote: > Sure and with the Exp Date, CVV, and number printed on every card you are open to compromise every time you stay in the hotel or go to a restaurant where you hand someone your card. Worse yet, the only option if you are compromised is to change all your numbers and put the burden on your of notifying everyone and that evening you hand your card to the waiter and the cycle starts over. The system is so monumentally stupid it’s unbelievable. > > Steven Naslund > > Chicago IL From SNaslund at medline.com Wed Oct 10 16:25:26 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 16:25:26 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> <20181010161737.GA74135@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6E16@MUNPRDMBXA1.medline.com> True and that should be mandatory but does not solve the telephone agent problem. Steven Naslund Chicago IL > I understand that in some countries the common practice is that the > waiter or clerk brings the card terminal to you or you go to it at the > cashier's desk, and you insert or swipe it, so the card never leaves > your hand. And you have to enter the PIN as well. This seems > notably more secure against point-of-sale compromise. > - Brian From ops.lists at gmail.com Wed Oct 10 16:35:38 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 10 Oct 2018 22:05:38 +0530 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6E16@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> <20181010161737.GA74135@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6E16@MUNPRDMBXA1.medline.com> Message-ID: IVR credit card PIN entry is a thing For example - https://www.hdfcbank.com/personal/making-payments/security-measures/ivr-3d-secure On 10/10/18, 9:57 PM, "NANOG on behalf of Naslund, Steve" wrote: True and that should be mandatory but does not solve the telephone agent problem. Steven Naslund Chicago IL > I understand that in some countries the common practice is that the > waiter or clerk brings the card terminal to you or you go to it at the > cashier's desk, and you insert or swipe it, so the card never leaves > your hand. And you have to enter the PIN as well. This seems > notably more secure against point-of-sale compromise. > - Brian From bill at herrin.us Wed Oct 10 16:35:56 2018 From: bill at herrin.us (William Herrin) Date: Wed, 10 Oct 2018 12:35:56 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> Message-ID: On Wed, Oct 10, 2018 at 11:25 AM Naslund, Steve wrote: > You are free to disagree all you want with the default deny-all > policy but it is a DoD 5200.28-STD requirement and NSA > Orange Book TCSEC requirement. And yet I got my DoD system ATOed my way earlier this year by demonstrating to the security controls assessment team that the cost of default-deny-all exceeded the risk cost of default-allow with IDS alerts on unexpected traffic. Because not spending more on a security implementation than the amount by which it reduces the risk cost, is a CORE SECURITY PRINCIPLE while default-deny-all is merely a standard policy. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From brandon at rd.bbc.co.uk Wed Oct 10 16:37:26 2018 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 10 Oct 2018 17:37:26 +0100 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181010161737.GA74135@meow.BKantor.net> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> <20181010161737.GA74135@meow.BKantor.net> Message-ID: <20181010163726.GA21266@sunf10.rd.bbc.co.uk> On Wed Oct 10, 2018 at 09:17:37AM -0700, Brian Kantor wrote: > I understand that in some countries the common practice is that the > waiter or clerk brings the card terminal to you or you go to it at the > cashier's desk, and you insert or swipe it, so the card never leaves > your hand. And you have to enter the PIN as well. This seems > notably more secure against point-of-sale compromise. PIN is more secure but the device is wireless and may have been compromised. All (that I've seen) POS are now PIN based in UK. Internet use still asks for CVV sadly though verified by visa is still occasionally used but is only protecting the places you probably already trust. There have been cards with a OTP display but they didn't become popular. I try and use Apple pay where possible. Apple assure us that their account code and one time security codes prevent the attacker aquiring the card number/pin/cvv and any captured data can not be used to make another transaction. Really eveything should do at least this. brandon From SNaslund at medline.com Wed Oct 10 16:39:18 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 16:39:18 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC65A3@MUNPRDMBXA1.medline.com> <20181010161737.GA74135@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6E16@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6E72@MUNPRDMBXA1.medline.com> It is good but has several inherent problems (other than almost no one using it). Your card number is static and so is your pin. If they get compromised, you are done. Changing token/pin resolve the static number problem completely, compromise of a used token has no impact whatsoever. Steven Naslund Chicago IL > >IVR credit card PIN entry is a thing > >For example - https://www.hdfcbank.com/personal/making-payments/security-measures/ivr-3d-secure From SNaslund at medline.com Wed Oct 10 17:06:09 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 17:06:09 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> If there was a waiver issued for your ATO, it would have had to have been issued by a department head or the OSD and approved by the DoD CIO after Director DISA provides a recommendation and it is mandatory that it be posted at https://gtg.csd.disa.mil. Please see this DoD Instruction http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/831001p.pdf (the waiver process is on page 23). If it did not go through that process, then it is not approved not matter what anyone told you. I know your opinion did not make it through that process. Want to tell us what system this is? Steven Naslund Chicago IL >And yet I got my DoD system ATOed my way earlier this year by >demonstrating to the security controls assessment team that the cost >of default-deny-all exceeded the risk cost of default-allow with IDS >alerts on unexpected traffic. > >Because not spending more on a security implementation than the amount >by which it reduces the risk cost, is a CORE SECURITY PRINCIPLE while >default-deny-all is merely a standard policy. > >Regards, >Bill Herrin From bzs at theworld.com Wed Oct 10 17:24:41 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 10 Oct 2018 13:24:41 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> Message-ID: <23486.13785.311648.701752@gargle.gargle.HOWL> On October 10, 2018 at 15:55 SNaslund at medline.com (Naslund, Steve) wrote: > The entire point of the CVV has become useless. Recently my wife was talking > to an airline ticket agent on the phone (American Airlines) and one of the > things they ask for on the phone is the CVV. If you are going to read that all > out over the phone with all the other data you are completely vulnerable to > fraud. It would be trivial to implement a system where you make a charge over > the phone like that and get a text asking you to authorize it instead of asking > for a CVV. I'm pretty sure the "entire point" of inventing CVV was to prove you physically have the card. For example someone dumpster-diving a restaurant etc particularly in the old imprint days when this was dreamed up wouldn't have the CVV or at least not from that source. Many merchant contracts' fees are based on whether you do sales on physical cards (lower) vs not like online. I don't know off-hand how that's affected by verifying the CVV online, I suspect it's mostly used online to avoid certain kinds of fraud for all the other reasons. We're very careful with CVVs as per contract agreement and they don't go near the database, only used during the verification and gone when the app fork exits. Credit card fraud is, to the processors, a game of percentages and cost/benefit. Sure one could have the CVV w/o the card, these days a big hazard are service people (e.g., restaurants) who can trivially snap both sides of your card with their phone, they often take your card away and come back later with the receipts and your card. In Europe and probably elsewhere it's very common for them to process your card with a hand-held device right in front of you which would make that more difficult. But any proposal to improve cc security has to reflect the cost/benefit across millions of transactions. If one isn't working with that data then they're only guessing. -- -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 Wed Oct 10 17:37:45 2018 From: bill at herrin.us (William Herrin) Date: Wed, 10 Oct 2018 13:37:45 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> Message-ID: On Wed, Oct 10, 2018 at 1:06 PM Naslund, Steve wrote: > Want to tell us what system this is? Yes, I want to give you explicit information about a government system in this public forum and you should encourage me to do so. I thought you said you had some skill in the security field? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From SNaslund at medline.com Wed Oct 10 17:52:37 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 17:52:37 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> Mr Herrin, you are asking us to believe one or all of the following : 1. You believe that it is good security policy to NOT have a default DENY ALL policy in place on firewalls for DoD and Intelligence systems handling sensitive data. 2. You managed to convince DoD personnel of that fact and actually got them to approve an Authorization to Operate such a system based on cost savings. 3. You are just trolling to start a discussion. The reason I asked what system it is would be to question the authorities at DoD on who and why this was approved. If you don't want to disclose that then you are either trolling or don't want anyone to look into it. It won't be hard to determine if you actually had any government contracts since that is public data. There are very few systems whose EXISTENCE is actually classified, but you were the one that cited it as an example supporting your policy. If you cannot name the system then it doesn't support your argument very well does it. Completely unverifiable. In any case I believe the smart people here on NANOG can accept or reject your security advice based on the factors above. I'm done talking about this one. Steven Naslund >> Want to tell us what system this is? >Yes, I want to give you explicit information about a government system >in this public forum and you should encourage me to do so. I thought >you said you had some skill in the security field? > >Regards, >Bill Herrin From SNaslund at medline.com Wed Oct 10 17:58:03 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 17:58:03 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <23486.13785.311648.701752@gargle.gargle.HOWL> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC7036@MUNPRDMBXA1.medline.com> It only proves that you have seen the card at some point. Useless. Steven Naslund Chicago IL >I'm pretty sure the "entire point" of inventing CVV was to prove you >physically have the card. From eyeronic.design at gmail.com Wed Oct 10 17:58:42 2018 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 10 Oct 2018 10:58:42 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> Message-ID: To be fair, the idea that your security costs shouldn't outweigh potential harm really shouldn't be controversial. You don't spend a billion dollars to protect a million dollars worth of product. That's hardly trolling. On Wed, Oct 10, 2018 at 10:54 AM Naslund, Steve wrote: > > Mr Herrin, you are asking us to believe one or all of the following : > > 1. You believe that it is good security policy to NOT have a default DENY ALL policy in place on firewalls for DoD and Intelligence systems handling sensitive data. > > 2. You managed to convince DoD personnel of that fact and actually got them to approve an Authorization to Operate such a system based on cost savings. > > 3. You are just trolling to start a discussion. > > The reason I asked what system it is would be to question the authorities at DoD on who and why this was approved. If you don't want to disclose that then you are either trolling or don't want anyone to look into it. It won't be hard to determine if you actually had any government contracts since that is public data. There are very few systems whose EXISTENCE is actually classified, but you were the one that cited it as an example supporting your policy. If you cannot name the system then it doesn't support your argument very well does it. Completely unverifiable. > > In any case I believe the smart people here on NANOG can accept or reject your security advice based on the factors above. I'm done talking about this one. > > Steven Naslund > > > >> Want to tell us what system this is? > > >Yes, I want to give you explicit information about a government system > >in this public forum and you should encourage me to do so. I thought > >you said you had some skill in the security field? > > > >Regards, > >Bill Herrin > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From SNaslund at medline.com Wed Oct 10 18:06:59 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 10 Oct 2018 18:06:59 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40301AC70C6@MUNPRDMBXA1.medline.com> Remember we are talking about classified intelligence systems and large IT organization infrastructure (Google, Yahoo, Apple) here (in the original Supermicro post). That would be information whose unauthorized disclosure would cause grave or exceptional grave harm (definition of secret and top secret) to the National Security of the United States. Seems like that warrants a default deny all (which is DoD and NSA policy). I would argue that ANY datacenter server should be protected that way unless it is intended to be publicly accessible. Steven Naslund >To be fair, the idea that your security costs shouldn't outweigh >potential harm really shouldn't be controversial. You don't spend a >billion dollars to protect a million dollars worth of product. > >That's hardly trolling. From ler762 at gmail.com Wed Oct 10 18:19:08 2018 From: ler762 at gmail.com (Lee) Date: Wed, 10 Oct 2018 14:19:08 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> Message-ID: On 10/10/18, Mike Hale wrote: > To be fair, the idea that your security costs shouldn't outweigh > potential harm really shouldn't be controversial. You don't spend a > billion dollars to protect a million dollars worth of product. The problem with that idea is that it's almost always implemented as your security costs shouldn't outweigh _your_ potential harm Regards, Lee > On Wed, Oct 10, 2018 at 10:54 AM Naslund, Steve > wrote: >> >> Mr Herrin, you are asking us to believe one or all of the following : >> >> 1. You believe that it is good security policy to NOT have a default DENY >> ALL policy in place on firewalls for DoD and Intelligence systems handling >> sensitive data. >> >> 2. You managed to convince DoD personnel of that fact and actually got >> them to approve an Authorization to Operate such a system based on cost >> savings. >> >> 3. You are just trolling to start a discussion. >> >> The reason I asked what system it is would be to question the authorities >> at DoD on who and why this was approved. If you don't want to disclose >> that then you are either trolling or don't want anyone to look into it. >> It won't be hard to determine if you actually had any government contracts >> since that is public data. There are very few systems whose EXISTENCE is >> actually classified, but you were the one that cited it as an example >> supporting your policy. If you cannot name the system then it doesn't >> support your argument very well does it. Completely unverifiable. >> >> In any case I believe the smart people here on NANOG can accept or reject >> your security advice based on the factors above. I'm done talking about >> this one. >> >> Steven Naslund >> >> >> >> Want to tell us what system this is? >> >> >Yes, I want to give you explicit information about a government system >> >in this public forum and you should encourage me to do so. I thought >> >you said you had some skill in the security field? >> > >> >Regards, >> >Bill Herrin From bill at herrin.us Wed Oct 10 18:19:05 2018 From: bill at herrin.us (William Herrin) Date: Wed, 10 Oct 2018 14:19:05 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> Message-ID: On Wed, Oct 10, 2018 at 1:53 PM Naslund, Steve wrote: > Mr Herrin, you are asking us to believe one or all of the following : > > 1. You believe that it is good security policy to NOT > have a default DENY ALL policy in place on firewalls > for DoD and Intelligence systems handling sensitive data. Steve, I believe it's a good idea for every security control to trace to first principles not just as conceived but as implemented. Default-deny-all is not a first principle. If often traces. Often is not always. Treating often as always is the sort of lazy error that leads users to work around non-sensible security implementations, demolishing the security they would have provided. > 2. You managed to convince DoD personnel of that fact > and actually got them to approve an Authorization to > Operate such a system based on cost savings. You mischaracterize it as "cost savings" but that's essentially correct. I spent six months going through the 1100 controls they laid on me and where I thought a control would be destructive I provided a thorough analysis of the anticipated mission impact for both the control as written and the proposed alternate mitigation. The impact is far more than a dollar sign. Make it hard to use and you sap the system's utility to the mission. Make it hard to manage and you increase the probability of error, decreasing the system availability. And so on. Won some of the arguments. Lost others. Built a better system with happier users for the effort. You can believe that or not as you choose. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From eyeronic.design at gmail.com Wed Oct 10 18:22:52 2018 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 10 Oct 2018 11:22:52 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC70C6@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6FE3@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC70C6@MUNPRDMBXA1.medline.com> Message-ID: If you're only talking about classified systems, sure. But it didn't sound to me like we were only talking exclusively about those kind of systems. On Wed, Oct 10, 2018 at 11:08 AM Naslund, Steve wrote: > > Remember we are talking about classified intelligence systems and large IT organization infrastructure (Google, Yahoo, Apple) here (in the original Supermicro post). > > That would be information whose unauthorized disclosure would cause grave or exceptional grave harm (definition of secret and top secret) to the National Security of the United States. Seems like that warrants a default deny all (which is DoD and NSA policy). I would argue that ANY datacenter server should be protected that way unless it is intended to be publicly accessible. > > Steven Naslund > > > >To be fair, the idea that your security costs shouldn't outweigh > >potential harm really shouldn't be controversial. You don't spend a > >billion dollars to protect a million dollars worth of product. > > > >That's hardly trolling. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From brock at bmwl.co Wed Oct 10 19:06:53 2018 From: brock at bmwl.co (Brock Tice) Date: Wed, 10 Oct 2018 13:06:53 -0600 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: Message-ID: <4a7b1987-7263-dd0a-7061-c1e3ef9ede17@bmwl.co> On 10/09/2018 06:24 PM, Philip Loenneker wrote: > I have asked several vendors we deal with about the newer technologies > such as 464XLAT, and have had some responses indicating they will > investigate internally, however we have not made much progress yet. One > vendor suggested their device supports NAT46 and NAT64 so may support > 464XLAT, but since it is incidental rather than an official feature, it > may not support the full CLAT requirements. I have been meaning to do > some tests but haven’t had a chance yet. It is also a higher price point > than our current CPEs. > >   > > I have spoken to people who have looked into options such as OpenWRT > (which supports several of these technolgoies), however the R&D and > ongoing support is a significant roadblock to overcome. > We looked into this somewhat intently ~6 months ago and had not much luck from vendors. Barely on their radar if at all. We used our own custom OpenWRT build on a few select, tested consumer routers to do 464XLAT. In the end we went to dual-stack with CGN on IPv4. I wrote up some documentation on how we did it on my blog, but in the end I can't recommend the setup we used. I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I would be ready to give it another shot. From wmf at felter.org Wed Oct 10 19:18:20 2018 From: wmf at felter.org (Wes Felter) Date: Wed, 10 Oct 2018 14:18:20 -0500 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: Message-ID: On 10/9/18 10:35 AM, Jason Lixfeld wrote: > Has anyone played around with this? Curious if the BCM (or whatever other chip) can do this, and if not, if any of the box vendors have tried to find a way to get these things to do a bunch of NAT - say some flavour of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but not sure if there are others out there. For 10G I would use software NAT like a firewall or CGN virtual appliance. Switch ASICs generally don't support NAT well; Tofino and maybe Jericho II can probably do it but at high cost and as you discovered the market isn't trying very hard to provide "routing" or "firewalling" functionality on "switching" ASICs. From bzs at theworld.com Wed Oct 10 19:26:39 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 10 Oct 2018 15:26:39 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC7036@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B40301AC7036@MUNPRDMBXA1.medline.com> Message-ID: <23486.21103.919096.213095@gargle.gargle.HOWL> On October 10, 2018 at 17:58 SNaslund at medline.com (Naslund, Steve) wrote: > It only proves that you have seen the card at some point. Useless. > > Steven Naslund > Chicago IL > > >I'm pretty sure the "entire point" of inventing CVV was to prove you > >physically have the card. > It's not useless, it protects against what it protects. Like dumpster-diving in the imprint days or if someone gets hold of all the credit card numbers + expirations (+ names, maybe) from your database. If you don't store CVVs (which is forbidden by contract) they won't have CVVs and sites which require them won't accept transactions. It's kind of like a PIN but yes too easily stolen. A friend used to write "ASK FOR PHOTO ID" in the signature portion of his credit cards and, I saw this, cashiers would look at it, look at his signature as if they were comparing, and say OK thank you! -- -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 Jamie.S.Bowden at raytheon.com Wed Oct 10 19:55:28 2018 From: Jamie.S.Bowden at raytheon.com (Jamie Bowden) Date: Wed, 10 Oct 2018 19:55:28 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6518@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40301AC6F17@MUNPRDMBXA1.medline.com> Message-ID: <8edbc901991e4538b067113dc0d8d752@SN1F00802MB0045.008f.mgd2.msft.net> > From: NANOG On Behalf Of Naslund, Steve > Sent: Wednesday, October 10, 2018 1:06 PM > If there was a waiver issued for your ATO, it would have had to have been issued by a > department head or the OSD and approved by the DoD CIO after Director DISA provides a > recommendation and it is mandatory that it be posted at https://gtg.csd.disa.mil. Please see this > DoD Instruction http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/831001p.pdf > (the waiver process is on page 23). If it did not go through that process, then it is not approved > not matter what anyone told you. I know your opinion did not make it through that process. That only applies to RMF systems where DSS is the AO on behalf of the DoD. For anything that falls outside DSS purview you can do whatever the COTR for the Cog is willing to sign off on. Even under RMF, MUSAs and isolated LANs have those requirements tailored out by default. IWANS and UWANS that don't have connectivity to anything but themselves are also NA for the firewall requirements. At the present, contractor systems that don't connect to a USG network aren't required to implement any of the STIGs other than base OS. I don't expect things to stay that way, but I haven't heard anything from DSS to indicate it'll be changing anytime in the near future. It's less difficult than it first appears to get ATO from a technical standpoint (the paperwork hell IA is buried under is an entirely different story, but I'm not them and have no desire to be). Jamie From sean at donelan.com Wed Oct 10 20:55:40 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 10 Oct 2018 16:55:40 -0400 (EDT) Subject: Cell tower backup plans Message-ID: On Wed, 10 Oct 2018, Naslund, Steve wrote: > I am wondering if this seems common to most of you on here. In my area > it seems that all cellular sites have backup generators and battery > backup. Seems like the biggest issues we see are devices remote from > the central offices that lose power and cause disruptions, like RSTs > and SLCs. During hurricane Katrina we saw a lot of active outside > plant devices underwater and that caused lots of disruption even when > the CO survived. As Hurricane Michael moves across the southeast, cell carriers will report to the FCC how many cell sites are out of service. Generally, there are more cell sites in cities. The loss of a city cell site is less severe because neighboring cell sites are close to overlap the area. There are more sources of backup power, and fuel (natural gas, diesel, etc) for generators. In cities, cell sites are less exposed on buildings than free-standing cell towers. COWs, COLTs, etc. are also more quickly deployed in cities. COWs and COLTs need connectivity to the PSTN to work, and there are most connection options in cities. In rural areas, there are fewer cell sites, spread further apart. The loss of even a single cell sites in rural areas often has a huge impact compared to cell sites in cities because no nearby towers, difficult to reach for repairs, electical grid is sparser. Land is cheaper in rural areas, so its cheaper to install a solar panel array. But as happened in Puerto Rico, solar panels don't survive Catagory 5 hurricanes any better than cell towers. Long way to say Both city and rural cell sites have some backup power (usually batteries). You just notice the loss of a few cell towers in rural areas more than the same number of cell sites in cities. Of course, catastrophic damage such as in Puerto Rico impacts everywhere. From rsk at gsp.org Wed Oct 10 21:04:53 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 10 Oct 2018 17:04:53 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> Message-ID: <20181010210453.GA23019@gsp.org> On Wed, Oct 10, 2018 at 02:21:40PM +0000, Naslund, Steve wrote: > Allowing an internal server with sensitive data out to "any" is a > serious mistake and so basic that I would fire that contractor immediately > (or better yet impose huge monetary penalties. I concur, and have been designing/building/running based on this premise for a long time. It's usually not very difficult or painful when starting fresh; it can be much more so when modifying an already-operational environment. But even in the latter case, it's worth the effort and expense: it much more than pays for itself the first time it stops something from getting out. The most difficult part of this process is often convincing people that it's sadly necessary. I say "sadly" because it wasn't also so, and that was a kinder, happier time. But that was then and this is now. And now the worst threat often comes from the inside. It also has three perhaps-not-quite-obvious benefits. First, it forces discipline. Things don't "just work", and that's a feature, not a bug. It requires thinking through what's required to make services functional and thus (hopefully) also thinking through what the potential consequences are. I'm no longer surprised how many chief technology officers don't actually know what their technology is doing (to borrow a phrase from Ranum) and are puzzled when they find out. The clarity provided by this approach removes that puzzlement. Second, it greatly reduces the extraneous noise that might make nefarious activity harder to spot. There's an entire market sector built around products that ferret out signal from noise; I find it easier not to allow the noise. Third, every attack we see coming in, every byte of abuse we see arriving, is the consequence of someone else *not* implementing default-deny and the collective cost of that across all operations is enormous. If we can avoid contributing to that, then we've done a small bit of good for everyone else. ---rsk From surfer at mauigateway.com Wed Oct 10 21:24:44 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 10 Oct 2018 14:24:44 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181010142444.46984E30@m0117458.ppops.net> --- SNaslund at medline.com wrote: From: "Naslund, Steve" You are free to disagree all you want with the default deny-all policy but it is a DoD 5200.28-STD requirement and NSA Orange Book TCSEC requirement. It is baked into all approved secure operating systems including SELINUX so it is really not open for debate if you have meet these requirements. ------------------------------------------------------- I believe you need to specify what type of DoD networks you're talking about. NIPR is not default deny. scott From robert at ripe.net Thu Oct 11 08:17:58 2018 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 11 Oct 2018 10:17:58 +0200 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <23486.13785.311648.701752@gargle.gargle.HOWL> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> Message-ID: <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> (this is probably OT now...) > I'm pretty sure the "entire point" of inventing CVV was to prove you > physically have the card. Except that it doesn't serve that purpose. Anyone who ever had your card in their hands (e.g. waiters) can just write that down and use it later hence defeating the purpose of "physically having the card". (Call me paranoid but I usually use a black pen to make the numbers undreadable because of this, after my card (both sides) has been photocopied a number of times...) This has always been an amusing topic. At the end of the day it's a financial risk management call from the banks -- as long as they lose less money on the current system than the cost of fraud, things wiull not change. Of course, they try to push those costs onto others as much as possible, but that doesn't change the bottom line. Robert From beecher at beecher.cc Thu Oct 11 13:40:50 2018 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 11 Oct 2018 09:40:50 -0400 Subject: Oct. 3, 2018 EAS Presidential Alert test In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC64C8@MUNPRDMBXA1.medline.com> References: <2AB6F2A9-6170-494E-8A52-172DB58C3105@andyring.com> <1538610514.734110.1529964728.51DD7AD5@webmail.messagingengine.com> <23478.54718.613935.849399@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B4030082402E@WAUPRDMBXP1.medline.com> <23483.42233.795819.818838@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B40301AC64C8@MUNPRDMBXA1.medline.com> Message-ID: It's likely worth noting that this specific test was of IPAWS (Integrated Public Alert and Warning System), a system designed to integrate the Emergency Alert System, National Warning System, Wireless Emergency Alerts, and NOAA Weather Alerts. It's not intended to be cell phone only or replace anything; it's intended to unify all the pre-existing methods together. This was just the first time cell phones were included in a nationwide test. On Wed, Oct 10, 2018 at 11:15 AM Naslund, Steve wrote: > I agree 100% and also have noticed that severe weather systems tend to > more severe in rural areas due to either open spaces (the plains) or trees > (forested areas) doing more damage. I can tell you from living the in > Midwest that the storms in Iowa and Nebraska are way worse than the ones > that hit Chicago. A weather guy I know told me it has something to do with > convective heat rising from major cities which is why you rarely see > tornados hitting downtown Chicago and New York. I have noticed that for > some reason local weather alerts seem to be more reliable than the national > level tests on cellular. Don't know if it has to do with shear volume or > what. Also, like I said earlier in rural areas you are less likely to run > into a bystander that knows what is going on. > > Steven Naslund > Chicago IL > > > >How quickly we forget. Puerto Rico's catastrophe was only a year ago. > >Per capita fatalities in rural areas are usually higher than cities after > >a disaster. Telecommunications are even more important in rural areas > >because you have fewer disaster response resources than in cities. > >Rural areas receive warnings later, have fewer emergency responders, > fewer > >advanced trauma hospitals. There are more neighbors helping neighbors in > >cities, and more potential sources of help in densely populated areas. > > > >Telecommunication providers are less likely to spend money hardening > >infrastructure in rural areas, because there is less business. Its easy > >to find alternative telecommunications in New York City. Its hard to find > >backup telecommunications in Idaho. > > > >A nation-wide WEA and EAS system helps warn people in both cities and > >rural areas. But they still depend on carriers and broadcasters. If there > >are no backup batteries in cell towers, or backup transmitters for > >broadcasters, you end up with communication blackouts like in Puerto Rico > >for months. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc at ottie.org Thu Oct 11 13:41:47 2018 From: sc at ottie.org (Scott Christopher) Date: Thu, 11 Oct 2018 13:41:47 +0000 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> Message-ID: <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> Robert Kisteleki wrote: > (this is probably OT now...) > > > I'm pretty sure the "entire point" of inventing CVV was to prove you > > physically have the card. > > Except that it doesn't serve that purpose. Anyone who ever had your card > in their hands (e.g. waiters) can just write that down and use it later > hence defeating the purpose of "physically having the card". But waiters don't know your ZIP code which is the other thing needed for online verification (in the U.S.) 3D Secure is good enough. It will probably be mandatory for payment processors sometime in the future. In the meantime, it just costs the industry less to cover fraud losses. -- S.C. From matt.larson at icann.org Thu Oct 11 16:01:22 2018 From: matt.larson at icann.org (Matt Larson) Date: Thu, 11 Oct 2018 16:01:22 +0000 Subject: The root KSK roll has occurred Message-ID: <4BE40A98-EDF8-458C-AFD0-65FEA426547A@icann.org> On behalf of the root zone management partners (ICANN and Verisign), I would like to report that the root KSK rollover occurred at 1600 UTC today, 11 October, with the publication of the root zone with serial number 2018101100. For the 48 hours after the rollover, we will be monitoring several mailing lists, including this one, so please reply here with any issues or concerns. Matt -- Matt Larson, VP of Research ICANN Office of the CTO -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Oct 11 16:06:30 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 11 Oct 2018 09:06:30 -0700 Subject: The root KSK roll has occurred In-Reply-To: <4BE40A98-EDF8-458C-AFD0-65FEA426547A@icann.org> References: <4BE40A98-EDF8-458C-AFD0-65FEA426547A@icann.org> Message-ID: Congratulations for rolling the root zone KSK. On Thu, Oct 11, 2018 at 9:01 AM Matt Larson wrote: > On behalf of the root zone management partners (ICANN and Verisign), I > would like to report that the root KSK rollover occurred at 1600 UTC today, > 11 October, with the publication of the root zone with serial number > 2018101100. > > For the 48 hours after the rollover, we will be monitoring several mailing > lists, including this one, so please reply here with any issues or concerns. > > Matt > -- > Matt Larson, VP of Research > ICANN Office of the CTO > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selphie.keller at gmail.com Thu Oct 11 16:42:39 2018 From: selphie.keller at gmail.com (Selphie Keller) Date: Thu, 11 Oct 2018 10:42:39 -0600 Subject: The root KSK roll has occurred In-Reply-To: References: <4BE40A98-EDF8-458C-AFD0-65FEA426547A@icann.org> Message-ID: Pretty awesome moment in history, confirmed my DNS resolvers are showing 20326. Also, seeing the new key on public resolvers like cloudflare and level3, google 8.8.8.8 and 8.8.4.4 still have 19036, likely cache. On Thu, 11 Oct 2018 at 10:07, Mehmet Akcin wrote: > Congratulations for rolling the root zone KSK. > > On Thu, Oct 11, 2018 at 9:01 AM Matt Larson wrote: > >> On behalf of the root zone management partners (ICANN and Verisign), I >> would like to report that the root KSK rollover occurred at 1600 UTC today, >> 11 October, with the publication of the root zone with serial number >> 2018101100. >> >> For the 48 hours after the rollover, we will be monitoring several >> mailing lists, including this one, so please reply here with any issues or >> concerns. >> >> Matt >> -- >> Matt Larson, VP of Research >> ICANN Office of the CTO >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Thu Oct 11 16:50:42 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Thu, 11 Oct 2018 09:50:42 -0700 Subject: The root KSK roll has occurred In-Reply-To: References: <4BE40A98-EDF8-458C-AFD0-65FEA426547A@icann.org> Message-ID: <0255D70B-E9F3-46C0-B4D2-26637117F5DC@thenetworknerds.ca> I can also confirm that all of my internal DNS systems see the new key. I am very excited for the future of DNS especially with many public resolvers supporting DNSSEC and DNS over TLS. Bryce Wilson, AS202313 > On Oct 11, 2018, at 9:42 AM, Selphie Keller wrote: > > Pretty awesome moment in history, confirmed my DNS resolvers are showing 20326. Also, seeing the new key on public resolvers like cloudflare and level3, google 8.8.8.8 and 8.8.4.4 still have 19036, likely cache. > > > >> On Thu, 11 Oct 2018 at 10:07, Mehmet Akcin wrote: >> Congratulations for rolling the root zone KSK. >> >>> On Thu, Oct 11, 2018 at 9:01 AM Matt Larson wrote: >>> On behalf of the root zone management partners (ICANN and Verisign), I would like to report that the root KSK rollover occurred at 1600 UTC today, 11 October, with the publication of the root zone with serial number 2018101100. >>> >>> For the 48 hours after the rollover, we will be monitoring several mailing lists, including this one, so please reply here with any issues or concerns. >>> >>> Matt >>> -- >>> Matt Larson, VP of Research >>> ICANN Office of the CTO >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at heyaaron.com Thu Oct 11 16:52:35 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 11 Oct 2018 09:52:35 -0700 Subject: The root KSK roll has occurred In-Reply-To: References: <4BE40A98-EDF8-458C-AFD0-65FEA426547A@icann.org> Message-ID: Well that explains the DNS weirdness I was seeing this morning. I had just made a significant network change and initially thought I screwed something up. After 10 minutes of halfhearted troubleshooting and poking around my configs I began to suspect DNS issues. Before I could do more digging, it magically resolved itself. -A On Thu, Oct 11, 2018 at 9:44 AM Selphie Keller wrote: > > Pretty awesome moment in history, confirmed my DNS resolvers are showing 20326. Also, seeing the new key on public resolvers like cloudflare and level3, google 8.8.8.8 and 8.8.4.4 still have 19036, likely cache. > > > > On Thu, 11 Oct 2018 at 10:07, Mehmet Akcin wrote: >> >> Congratulations for rolling the root zone KSK. >> >> On Thu, Oct 11, 2018 at 9:01 AM Matt Larson wrote: >>> >>> On behalf of the root zone management partners (ICANN and Verisign), I would like to report that the root KSK rollover occurred at 1600 UTC today, 11 October, with the publication of the root zone with serial number 2018101100. >>> >>> For the 48 hours after the rollover, we will be monitoring several mailing lists, including this one, so please reply here with any issues or concerns. >>> >>> Matt >>> -- >>> Matt Larson, VP of Research >>> ICANN Office of the CTO >>> From jcurran at arin.net Thu Oct 11 18:25:49 2018 From: jcurran at arin.net (John Curran) Date: Thu, 11 Oct 2018 18:25:49 +0000 Subject: =?utf-8?B?QVJJTiBFbGVjdGlvbnMgY2xvc2UgdG9tb3Jyb3cgIOKAk8KgRnJpZGF5IDEy?= =?utf-8?Q?_October_at_18:00_eastern_time!_?= References: Message-ID: Folks - If you are an ARIN Member and have not yet voted in this year’s ARIN elections, please do so now! (To do so, log into ARIN Online and click on the “Vote Now” button; see additional details below) Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] Voting Now Open for the 2018 ARIN Board of Trustees, ARIN Advisory Council, and NRO NC Elections Date: 4 October 2018 at 6:00:26 PM EDT To: > Cast your online ballot now in the 2018 ARIN Elections to fill two seats on the ARIN Board of Trustees, five seats on the ARIN Advisory Council, and one seat on the Number Resource Organization Number Council (NRO NC). Eligible Voting Contacts from General Members in Good Standing as of the voter eligibility deadline of 20 August, may cast an online ballot now through 6:00 PM EDT, Friday, 12 October. To vote, simply log in to ARIN Online and look for the “Vote Now” link on your dashboard. To view candidate biographies, please view the ARIN Elections 2018 Voter Guide at: https://www.arin.net/participate/elections/candidate_bios.pdf To view or submit a Statement of Support, please click on the link below. Anyone, regardless of voter status, is eligible to submit a Statement of Support for a candidate. https://www.bigpulse.com/p51139/ During the week of 8 October, all eligible Voting Contacts should be aware that an ARIN representative will be personally calling them as a gentle reminder to please vote and to answer any election-related questions they may have. Participation in the election process is crucial, requires only minutes of a voter’s time, is done online, and is an important member responsibility. A single cast ballot provides eligible member organizations an opportunity to shape the future of ARIN, our community, and the Internet. For questions about voting, or if you encounter an issue with the election system, please contact a member of the Member Services team immediately via email at members at arin.net or submit a question via ARIN Online and direct it to Meetings/Elections. Regards, Wendy Leedy Member Engagement Coordinator American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Thu Oct 11 19:02:30 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 11 Oct 2018 15:02:30 -0400 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> Message-ID: <23487.40518.528431.85821@gargle.gargle.HOWL> On October 11, 2018 at 10:17 robert at ripe.net (Robert Kisteleki) wrote: > (this is probably OT now...) > > > I'm pretty sure the "entire point" of inventing CVV was to prove you > > physically have the card. > > Except that it doesn't serve that purpose. Anyone who ever had your card > in their hands (e.g. waiters) can just write that down and use it later > hence defeating the purpose of "physically having the card". (Call me > paranoid but I usually use a black pen to make the numbers undreadable > because of this, after my card (both sides) has been photocopied a > number of times...) What you're saying is they don't work as well as you might hope, not that they don't serve that purpose. If you snatched 5M credit cards numbers and expiraton dates but, as required by contract, there were no CVVs in that db how well would that work with sites which require a CVV for a transaction? Not well at all. So there's a purpose. Also, traditionally one's signature is on the back right next to that CVV for a merchant to compare against which leaves forgery a mere exercise in, well, forgery, since the example one has to reasonably match is right there. Which doesn't mean signatures don't work, it's just not much protection against anyone who can reasonably forge a signature. But many people can't or won't try, it discourages minor criminals like your boyfriend using your card surreptitously while you were sleeping. They're also some reasonable evidence that the transaction was done in person with the card in hand. I know some merchant contracts wouldn't allow forgiveness (who eats the fraud) for charges w/o a signature where their contract claims they only do in-person purchases which gets them a lower rate. There is a concern for merchant fraud also in all this, unfortunately that's very tempting. BUT IT'S ALL WORSE THAN THAT! When I had a book of checks stolen (and reported) several turned up used in major big box stores with information like driver's license number, date of birth, etc neatly written on them tho none of that info was mine. I doubt they went to the trouble of counterfeiting a driver's license, it's possible but this was small-time fraud. My suspicion was they were in cahoots with the cashier, simplest explanation, the cashier was a friend who probably got a cut. So anything in the presumed chain of events can often be suborned. > This has always been an amusing topic. At the end of the day it's a > financial risk management call from the banks -- as long as they lose > less money on the current system than the cost of fraud, things wiull > not change. Of course, they try to push those costs onto others as much > as possible, but that doesn't change the bottom line. I agree with this. Quite a few years ago I was interviewed by a start-up manufacturer of a big parallel "mini" to head their OS effort. Something which came out in the conversation, which went on for hours! (very pleasant tho), was that a major credit card company had pledged in writing to buy $150M of their machines on day one of ship if they could run a set of their anti-fraud algorithms quickly enough (their spec) to be able to reject transactions in real time. The company had done forensics and I think the estimate was if they could have run those algorithms they would have saved them some big number like $50K/hour in fraud. But they couldn't run them fast enough to allow for reasonable transaction times. And then ya sit around the bar thinking you know how this or that startup is funded or why...that would not have been one of my guesses! -- -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 Thu Oct 11 19:19:25 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 11 Oct 2018 15:19:25 -0400 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> Message-ID: <23487.41533.482408.823977@gargle.gargle.HOWL> On October 11, 2018 at 13:41 sc at ottie.org (Scott Christopher) wrote: > Robert Kisteleki wrote: > > > (this is probably OT now...) > > > > > I'm pretty sure the "entire point" of inventing CVV was to prove you > > > physically have the card. > > > > Except that it doesn't serve that purpose. Anyone who ever had your card > > in their hands (e.g. waiters) can just write that down and use it later > > hence defeating the purpose of "physically having the card". > > But waiters don't know your ZIP code which is the other thing needed for online verification (in the U.S.) So be wary if they ask you for photo id which likely has your zip code! But asking for photo id is a good thing for legitimate card holders, could reduce fraudulent in-person use of stolen cards. What a mess. > 3D Secure is good enough. It will probably be mandatory for payment processors sometime in the future. In the meantime, it just costs the industry less to cover fraud losses. > > -- > S.C. -- -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 cma at cmadams.net Thu Oct 11 19:31:36 2018 From: cma at cmadams.net (Chris Adams) Date: Thu, 11 Oct 2018 14:31:36 -0500 Subject: CVV (was: Re: bloomberg on supermicro: sky is falling) In-Reply-To: <23487.41533.482408.823977@gargle.gargle.HOWL> References: <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <96eece6e-0926-5416-8f8f-8baf3268b7cb@ripe.net> <1539265307.3026325.1538551584.1BE1FBC7@webmail.messagingengine.com> <23487.41533.482408.823977@gargle.gargle.HOWL> Message-ID: <20181011193136.GA30057@cmadams.net> Once upon a time, bzs at theworld.com said: > But asking for photo id is a good thing for legitimate card holders, > could reduce fraudulent in-person use of stolen cards. Requiring an ID is also a violation of the merchant agreements, at least for VISA and MasterCard (not sure about American Express), unless ID is otherwise required by law (like for age-limited products). I've walked out of stores that required an ID. -- Chris Adams From sean at donelan.com Thu Oct 11 21:29:06 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 11 Oct 2018 17:29:06 -0400 (EDT) Subject: Hurricane Michael: Communication Service Provider status Message-ID: Electric power outages (percentage out of service) Florida Bay County - 98% Calhoun County - 100% Franklin County - 97% Gadsden County - 100% Gulf County - 99% Holmes County - 99% Jackson County - 100% Leon County - 91% Wakulla County - 97% Washington County - 98% I haven't found power outage reports from other states yet. 1 Public Safety Answering Point out of service Jackson County FL 15 Public Safety Answering Points re-routed Counties with over 60% cell sites out of service Florida Bay County - 78.3% Gulf County - 69.6% Holmes County - 74.1% Jackson County - 77.1% Liberty County - 88.9% Washington County - 69.2% Georgia Schley County - 66.7% Webster County - 64.7% Cable and Wireline subscribers reported out of service (likely more out of service than reported) Alabama - 14,855 Florida - 185,841 Georgia - 63,473 Radio and Television 4 TV stations out of service 30 FM stations out of service 4 AM stations out of service From sean at donelan.com Fri Oct 12 01:05:46 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 11 Oct 2018 21:05:46 -0400 (EDT) Subject: Hurricane Michael: Communication Service Provider status In-Reply-To: References: Message-ID: > I haven't found power outage reports from other states yet. My bad, DOE moved its reports to a different URL on its site. Here are the electric grid status for other states, along with some other status info I found. Electric power outages as of October 11, 2018 at 4:00pm EDT Statewide averages don't reflect severe damage in specific counties: Alabama: 3% (87,706 customers) Florida: 3.7% (389,639) Georgia: 6.4% (268,461) North Carolina: 9% (361,879) South Carolina: 2.6% (117,221) Utilties in the region report 30,000 personnel in position for restoration efforts. The following sea ports are closed Panama City, FL Pensacola, FL Wimington, NC Retail gas/fuel stations shut (lack of fuel, power or both) Florida: 6.0% shut Georgia: 2.6% shut Alabama: 1.3% shut Regional fuel stocks available: 28.1 million barrels NOAA Weather Radio transmitter outages Columbus, AL Americus, GA Macon, GA Lafayette, LA New Bern, NC Beaufort, SC From thomasammon at gmail.com Fri Oct 12 03:39:19 2018 From: thomasammon at gmail.com (Tom Ammon) Date: Thu, 11 Oct 2018 23:39:19 -0400 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: <4a7b1987-7263-dd0a-7061-c1e3ef9ede17@bmwl.co> References: <4a7b1987-7263-dd0a-7061-c1e3ef9ede17@bmwl.co> Message-ID: On Wed, Oct 10, 2018 at 3:08 PM Brock Tice wrote: > On 10/09/2018 06:24 PM, Philip Loenneker wrote: > > I have asked several vendors we deal with about the newer technologies > > such as 464XLAT, and have had some responses indicating they will > > investigate internally, however we have not made much progress yet. One > > vendor suggested their device supports NAT46 and NAT64 so may support > > 464XLAT, but since it is incidental rather than an official feature, it > > may not support the full CLAT requirements. I have been meaning to do > > some tests but haven’t had a chance yet. It is also a higher price point > > than our current CPEs. > > > > > > > > I have spoken to people who have looked into options such as OpenWRT > > (which supports several of these technolgoies), however the R&D and > > ongoing support is a significant roadblock to overcome. > > > > We looked into this somewhat intently ~6 months ago and had not much > luck from vendors. Barely on their radar if at all. > > We used our own custom OpenWRT build on a few select, tested consumer > routers to do 464XLAT. In the end we went to dual-stack with CGN on > IPv4. I wrote up some documentation on how we did it on my blog, but in > the end I can't recommend the setup we used. > > I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I > would be ready to give it another shot. > It sounds like I am where you were 6 months ago. We've been looking at NAT64, MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4 side. What did you experience with the dual-stack/CGN approach that keeps you from recommending it? Academically, that setup seems the least fraught with problems among all of the options. -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philip.Loenneker at tasmanet.com.au Fri Oct 12 03:57:52 2018 From: Philip.Loenneker at tasmanet.com.au (Philip Loenneker) Date: Fri, 12 Oct 2018 03:57:52 +0000 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: <4a7b1987-7263-dd0a-7061-c1e3ef9ede17@bmwl.co> Message-ID: Hi Tom, CGNAT is the most supported by the technology available in pretty much every device. Even keeping an audit trail of IP/port mappings is relatively easy (look into deterministic NAT – it will save you a lot of headache). You can likely lab it up with gear you already have, unlike the newer transition technologies that we’ve been discussing. However, from my experience, the customer impact of going through 2 layers of NAT (NAT44) causes a lot of unhappy customers. I enabled it on my home connection for a few weeks to see how it went, and I was surprised that a lot of things just worked… Youtube, Netflix, etc had no issues. But there were key things such as Facebook Messenger voice and video calls that broke, which caused my family to get rather upset with me. Console gaming is also a common area of problems. For these types of Internet services, the profit margin can get eaten up quickly by the helpdesk calls. As a side note, from internal discussions here (ie speculation, no real evidence to back it up), home users are likely to be impacted far more than business users, due to the difference in usage. Regards, Philip From: NANOG On Behalf Of Tom Ammon Sent: Friday, 12 October 2018 2:39 PM To: NANOG Subject: Re: new(ish) ipv6 transition tech status on CPE On Wed, Oct 10, 2018 at 3:08 PM Brock Tice > wrote: On 10/09/2018 06:24 PM, Philip Loenneker wrote: > I have asked several vendors we deal with about the newer technologies > such as 464XLAT, and have had some responses indicating they will > investigate internally, however we have not made much progress yet. One > vendor suggested their device supports NAT46 and NAT64 so may support > 464XLAT, but since it is incidental rather than an official feature, it > may not support the full CLAT requirements. I have been meaning to do > some tests but haven’t had a chance yet. It is also a higher price point > than our current CPEs. > > > > I have spoken to people who have looked into options such as OpenWRT > (which supports several of these technolgoies), however the R&D and > ongoing support is a significant roadblock to overcome. > We looked into this somewhat intently ~6 months ago and had not much luck from vendors. Barely on their radar if at all. We used our own custom OpenWRT build on a few select, tested consumer routers to do 464XLAT. In the end we went to dual-stack with CGN on IPv4. I wrote up some documentation on how we did it on my blog, but in the end I can't recommend the setup we used. I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I would be ready to give it another shot. It sounds like I am where you were 6 months ago. We've been looking at NAT64, MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4 side. What did you experience with the dual-stack/CGN approach that keeps you from recommending it? Academically, that setup seems the least fraught with problems among all of the options. -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Oct 12 12:44:11 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 12 Oct 2018 07:44:11 -0500 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: <4a7b1987-7263-dd0a-7061-c1e3ef9ede17@bmwl.co> Message-ID: <004701d46229$4750dd10$d5f29730$@gvtc.com> In my CGNat environment (~11,000 subs (5,000 dsl & 6,000 cable modem)) I had to solve issues with site-to-site vpn, console gaming and some webmail and banking web sites that seem to hand off authentication to another site and try to carry over the ip address … also had to try to accomplish load sharing amongst (3) cgnat nodes on my vrf-to-vrf boundary where I do natting… here’s some things we did… APP - consistent mapping for priv to pub ip's EIM – stabilizes ports outbound EIF - stabilizes ports inbound and allows for some hold-over (actual pinhole openings) for further comms from outside---to---->inside AMS LB - ams load balancing to occur on src-ip for removing the chance for more ip change* AMS Member Failure options - more of adding resilience if/when underlying npu's fail IGP (OSPF/LDP) routing - not cgnat related at all, and i recall more for load sharing amongst my mx960....but was a big win for us when we found the (set protocols ldp track-igp-metric) trick or causing my PE's that would then use the real igp metric to route to the *igp closest* cgnat node (mx960/ms-mpc-128g) thus causing that cgnat node to always be used for that pe's set of priv ip subs... you must know that i had a triple cgnat node boundary ((3) mx960's w/ms-mpc's) and here again had an issue with all traffic going to the lowest bgp loopback ip tiebreaker since apparently inet.3 has metric 1 for every prefix... that trick ldp command copies inet.0 metric into inet.3 thus giving some real igp metric consideration to the bgp best path calculation * pub ip pool is divided up over the number for npu/vpic's that are aggregated together in an ams... so there is a chance that your priv ip's will be hashed over any and all npu's thus causing greater change of pub ip differences Btw, there are keepalives for eif and sessions limits for resource issues to be considered - Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Philip Loenneker Sent: Thursday, October 11, 2018 10:58 PM To: NANOG Subject: RE: new(ish) ipv6 transition tech status on CPE Hi Tom, CGNAT is the most supported by the technology available in pretty much every device. Even keeping an audit trail of IP/port mappings is relatively easy (look into deterministic NAT – it will save you a lot of headache). You can likely lab it up with gear you already have, unlike the newer transition technologies that we’ve been discussing. However, from my experience, the customer impact of going through 2 layers of NAT (NAT44) causes a lot of unhappy customers. I enabled it on my home connection for a few weeks to see how it went, and I was surprised that a lot of things just worked… Youtube, Netflix, etc had no issues. But there were key things such as Facebook Messenger voice and video calls that broke, which caused my family to get rather upset with me. Console gaming is also a common area of problems. For these types of Internet services, the profit margin can get eaten up quickly by the helpdesk calls. As a side note, from internal discussions here (ie speculation, no real evidence to back it up), home users are likely to be impacted far more than business users, due to the difference in usage. Regards, Philip From: NANOG On Behalf Of Tom Ammon Sent: Friday, 12 October 2018 2:39 PM To: NANOG Subject: Re: new(ish) ipv6 transition tech status on CPE On Wed, Oct 10, 2018 at 3:08 PM Brock Tice wrote: On 10/09/2018 06:24 PM, Philip Loenneker wrote: > I have asked several vendors we deal with about the newer technologies > such as 464XLAT, and have had some responses indicating they will > investigate internally, however we have not made much progress yet. One > vendor suggested their device supports NAT46 and NAT64 so may support > 464XLAT, but since it is incidental rather than an official feature, it > may not support the full CLAT requirements. I have been meaning to do > some tests but haven’t had a chance yet. It is also a higher price point > than our current CPEs. > > > > I have spoken to people who have looked into options such as OpenWRT > (which supports several of these technolgoies), however the R&D and > ongoing support is a significant roadblock to overcome. > We looked into this somewhat intently ~6 months ago and had not much luck from vendors. Barely on their radar if at all. We used our own custom OpenWRT build on a few select, tested consumer routers to do 464XLAT. In the end we went to dual-stack with CGN on IPv4. I wrote up some documentation on how we did it on my blog, but in the end I can't recommend the setup we used. I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I would be ready to give it another shot. It sounds like I am where you were 6 months ago. We've been looking at NAT64, MAP-T, potentially 464XLAT, and then dual stack with CGN on the v4 side. What did you experience with the dual-stack/CGN approach that keeps you from recommending it? Academically, that setup seems the least fraught with problems among all of the options. -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at mork.no Fri Oct 12 13:02:09 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 12 Oct 2018 15:02:09 +0200 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301AC7036@MUNPRDMBXA1.medline.com> (Steve Naslund's message of "Wed, 10 Oct 2018 17:58:03 +0000") References: <20181004151309.30BE0413@m0117458.ppops.net> <9578293AE169674F9A048B2BC9A081B403008240F1@WAUPRDMBXP1.medline.com> <1538992139.612460.1534330216.0146D0DE@webmail.messagingengine.com> <9578293AE169674F9A048B2BC9A081B40301AC5013@MUNPRDMBXA1.medline.com> <20181010143214.GA73218@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B40301AC6580@MUNPRDMBXA1.medline.com> <23486.13785.311648.701752@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B40301AC7036@MUNPRDMBXA1.medline.com> Message-ID: <87sh1b1fou.fsf@miraculix.mork.no> "Naslund, Steve" writes: > It only proves that you have seen the card at some point. Useless. It doesn't even prove that much. There is nothing preventing a rogue online shop from storing and reusing the CVV you give them. Or selling your complete card details including zip code, CVV and whatever. In practice, the CVV is just 3 more digits in the card number. No security whatsoever in that. Bjørn From brock at bmwl.co Fri Oct 12 15:19:03 2018 From: brock at bmwl.co (Brock Tice) Date: Fri, 12 Oct 2018 09:19:03 -0600 Subject: new(ish) ipv6 transition tech status on CPE In-Reply-To: References: <4a7b1987-7263-dd0a-7061-c1e3ef9ede17@bmwl.co> Message-ID: <325554a4-d1f7-6919-334c-8a9f7bbc0d3d@bmwl.co> On 10/11/2018 09:39 PM, Tom Ammon wrote: > What did you experience with the dual-stack/CGN approach that keeps you > from recommending it? Nothing, sorry if my writing was confusing. It was the 464XLAT that I don't recommend at this time, lack of vendor support by the brands we currently use (especially Mikrotik and Ubiquiti) was the main issue. From surfer at mauigateway.com Fri Oct 12 18:00:58 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Oct 2018 11:00:58 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181012110058.4699E099@m0117458.ppops.net> --- bjorn at mork.no wrote: There is nothing preventing a rogue online shop from storing and reusing the CVV you give them. Or selling your complete card details including zip code, CVV and whatever. ----------------------------------------- As a side note on the tail end of this and as someone who has had their data compromised and 1000s of dollars stolen online... ATM, though; not CC. Make a second account at your bank. One account is 'storage' and has all your money. You never use the 'storage account' ATM card for anything outside your bank's ATM machines. The second one is where you only keep $50-$100 in it. When you use your ATM card it's only this account that's used. Just before you make a purchase, move money from your 'storage account' into your 'active account' and make the purchase. If your 'active account' is compromised all they can steal is the $50-$100 in the account. scott From cscora at apnic.net Fri Oct 12 18:03:26 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Oct 2018 04:03:26 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181012180326.EFE47C450F@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, IRNOG 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 13 Oct, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 721096 Prefixes after maximum aggregation (per Origin AS): 277098 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 345929 Total ASes present in the Internet Routing Table: 62109 Prefixes per ASN: 11.61 Origin-only ASes present in the Internet Routing Table: 53619 Origin ASes announcing only one prefix: 23335 Transit ASes present in the Internet Routing Table: 8490 Transit-only ASes present in the Internet Routing Table: 261 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 44 Number of instances of unregistered ASNs: 44 Number of 32-bit ASNs allocated by the RIRs: 24423 Number of 32-bit ASNs visible in the Routing Table: 19736 Prefixes from 32-bit ASNs in the Routing Table: 83469 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 280 Number of addresses announced to Internet: 2855400963 Equivalent to 170 /8s, 49 /16s and 246 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 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: 240920 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 196490 Total APNIC prefixes after maximum aggregation: 55881 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 194140 Unique aggregates announced from the APNIC address blocks: 80052 APNIC Region origin ASes present in the Internet Routing Table: 9171 APNIC Prefixes per ASN: 21.17 APNIC Region origin ASes announcing only one prefix: 2560 APNIC Region transit ASes present in the Internet Routing Table: 1364 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4133 Number of APNIC addresses announced to Internet: 767752898 Equivalent to 45 /8s, 194 /16s and 250 /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: 214366 Total ARIN prefixes after maximum aggregation: 101616 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 213998 Unique aggregates announced from the ARIN address blocks: 101728 ARIN Region origin ASes present in the Internet Routing Table: 18266 ARIN Prefixes per ASN: 11.72 ARIN Region origin ASes announcing only one prefix: 6784 ARIN Region transit ASes present in the Internet Routing Table: 1810 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2465 Number of ARIN addresses announced to Internet: 1098532000 Equivalent to 65 /8s, 122 /16s and 68 /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: 196723 Total RIPE prefixes after maximum aggregation: 93952 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 193089 Unique aggregates announced from the RIPE address blocks: 114184 RIPE Region origin ASes present in the Internet Routing Table: 25543 RIPE Prefixes per ASN: 7.56 RIPE Region origin ASes announcing only one prefix: 11478 RIPE Region transit ASes present in the Internet Routing Table: 3539 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7477 Number of RIPE addresses announced to Internet: 714723456 Equivalent to 42 /8s, 153 /16s and 208 /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: 93596 Total LACNIC prefixes after maximum aggregation: 21418 LACNIC Deaggregation factor: 4.37 Prefixes being announced from the LACNIC address blocks: 94975 Unique aggregates announced from the LACNIC address blocks: 41374 LACNIC Region origin ASes present in the Internet Routing Table: 7640 LACNIC Prefixes per ASN: 12.43 LACNIC Region origin ASes announcing only one prefix: 2106 LACNIC Region transit ASes present in the Internet Routing Table: 1431 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5184 Number of LACNIC addresses announced to Internet: 172314144 Equivalent to 10 /8s, 69 /16s and 78 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19876 Total AfriNIC prefixes after maximum aggregation: 4192 AfriNIC Deaggregation factor: 4.74 Prefixes being announced from the AfriNIC address blocks: 24614 Unique aggregates announced from the AfriNIC address blocks: 8332 AfriNIC Region origin ASes present in the Internet Routing Table: 1203 AfriNIC Prefixes per ASN: 20.46 AfriNIC Region origin ASes announcing only one prefix: 407 AfriNIC Region transit ASes present in the Internet Routing Table: 243 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 477 Number of AfriNIC addresses announced to Internet: 101644288 Equivalent to 6 /8s, 14 /16s and 248 /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 4639 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4461 489 479 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2985 1153 93 VIETEL-AS-AP Viettel Group, VN 4766 2821 11130 764 KIXS-AS-KR Korea Telecom, KR 45899 2783 1674 159 VNPT-AS-VN VNPT Corp, VN 9829 2757 1496 550 BSNL-NIB National Internet Backbone, IN 9394 2590 4907 31 CTTNET China TieTong Telecommunications 17974 2253 936 52 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2250 8699 26 CMNET-GD Guangdong Mobile Communication 4755 2135 422 173 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 11492 3525 227 498 CABLEONE - CABLE ONE, INC., US 6327 3454 1324 83 SHAW - Shaw Communications Inc., CA 22773 3244 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2316 5005 815 AMAZON-02 - Amazon.com, Inc., US 18566 2157 405 109 MEGAPATH5-US - MegaPath Corporation, US 16625 2152 1115 1555 AKAMAI-AS - Akamai Technologies, Inc., 20115 2148 2736 522 CHARTER-NET-HKY-NC - Charter Communicat 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications 209 2041 5081 597 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 30036 1999 339 314 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 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 4932 1609 128 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3050 378 50 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2574 592 1920 AKAMAI-ASN1, US 12389 2116 2065 681 ROSTELECOM-AS, RU 34984 2049 337 509 TELLCOM-AS, TR 9121 1862 1691 17 TTNET, TR 13188 1604 100 45 TRIOLAN, UA 8402 1271 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA 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 5413 3304 611 Uninet S.A. de C.V., MX 10620 3197 490 804 Telmex Colombia S.A., CO 11830 2657 370 82 Instituto Costarricense de Electricidad 6503 1649 444 65 Axtel, S.A.B. de C.V., MX 7303 1432 955 206 Telecom Argentina S.A., AR 28573 1119 2234 197 CLARO S.A., BR 6147 1114 377 31 Telefonica del Peru S.A.A., PE 3816 1025 512 112 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 935 145 71 Alestra, S. de R.L. de C.V., MX 18881 919 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 1201 396 48 LINKdotNET-AS, EG 37611 902 107 9 Afrihost, ZA 36903 794 399 146 MT-MPLS, MA 36992 753 1411 41 ETISALAT-MISR, EG 24835 682 818 18 RAYA-AS, EG 8452 663 1728 15 TE-AS TE-AS, EG 37492 468 470 57 ORANGE-, TN 29571 465 70 12 ORANGE-COTE-IVOIRE, CI 23889 394 231 15 MauritiusTelecom, MU 37342 394 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 5413 3304 611 Uninet S.A. de C.V., MX 12479 4932 1609 128 UNI2-AS, ES 4538 4639 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4461 489 479 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3525 227 498 CABLEONE - CABLE ONE, INC., US 6327 3454 1324 83 SHAW - Shaw Communications Inc., CA 22773 3244 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3197 490 804 Telmex Colombia S.A., CO 8551 3050 378 50 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 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 4932 4804 UNI2-AS, ES 4538 4639 4565 ERX-CERNET-BKB China Education and Research Net 7545 4461 3982 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3454 3371 SHAW - Shaw Communications Inc., CA 22773 3244 3088 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11492 3525 3027 CABLEONE - CABLE ONE, INC., US 8551 3050 3000 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2985 2892 VIETEL-AS-AP Viettel Group, VN 45899 2783 2624 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 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65551 DOCUMENT 103.112.64.0/23 58889 ZOL-BD Zx Online Ltd, BD 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 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.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 45.121.32.0/22 134356 UNKNOWN 45.121.136.0/22 22552 ESITED - eSited Solutions, US 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 64.28.160.0/20 20475 AS20475 - Global Capacity, LLC, US 64.29.240.0/20 27279 -Reserved AS-, ZZ 64.30.152.0/24 15830 TELECITY-LON, GB 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:14 /9:11 /10:36 /11:98 /12:290 /13:566 /14:1103 /15:1888 /16:13336 /17:7899 /18:13790 /19:25398 /20:39664 /21:45951 /22:89509 /23:73608 /24:405721 /25:821 /26:624 /27:634 /28:36 /29:21 /30:22 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3719 4932 UNI2-AS, ES 6327 3240 3454 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2778 3525 CABLEONE - CABLE ONE, INC., US 8551 2506 3050 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2506 3244 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2051 2157 MEGAPATH5-US - MegaPath Corporation, US 11830 2007 2657 Instituto Costarricense de Electricidad y Telec 5650 1762 2085 FRONTIER-FRTR - Frontier Communications of Amer 30036 1747 1999 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1608 2:887 4:18 5:2671 6:43 7:1 8:1143 12:1864 13:219 14:1836 15:34 16:3 17:194 18:56 20:50 23:2556 24:2424 25:2 27:2517 31:2008 32:84 35:29 36:537 37:2875 38:1548 39:258 40:120 41:3265 42:717 43:1975 44:122 45:5743 46:3106 47:226 49:1346 50:1051 51:318 52:1090 54:364 55:1 56:12 57:39 58:1622 59:988 60:417 61:2086 62:1961 63:1805 64:5077 65:2208 66:4805 67:2672 68:1158 69:3366 70:1155 71:580 72:2254 74:2723 75:416 76:456 77:1652 78:1741 79:2235 80:1577 81:1423 82:1057 83:786 84:1046 85:2047 86:557 87:1455 88:929 89:2363 90:213 91:6444 92:1273 93:2393 94:2431 95:3026 96:932 97:352 98:938 99:142 100:86 101:1182 102:245 103:18974 104:3559 105:220 106:771 107:1827 108:708 109:3350 110:1673 111:1820 112:1330 113:1302 114:1171 115:1686 116:1666 117:1791 118:2203 119:1692 120:1085 121:1046 122:2387 123:1669 124:1445 125:1935 128:1186 129:692 130:500 131:1618 132:721 133:191 134:1038 135:237 136:527 137:659 138:1947 139:698 140:548 141:748 142:839 143:1014 144:845 145:496 146:1242 147:742 148:1687 149:778 150:759 151:999 152:870 153:325 154:1893 155:938 156:1494 157:814 158:660 159:1879 160:1493 161:855 162:2644 163:737 164:1088 165:1564 166:453 167:1280 168:3161 169:855 170:3842 171:495 172:1028 173:2067 174:999 175:808 176:2081 177:4045 178:2500 179:1321 180:2164 181:2427 182:2381 183:1304 184:1151 185:14203 186:3590 187:2491 188:2930 189:2018 190:8279 191:1360 192:9850 193:6282 194:5131 195:4043 196:2819 197:1625 198:5664 199:5965 200:7426 201:5048 202:10257 203:10241 204:4590 205:3001 206:3220 207:3200 208:3925 209:4159 210:3836 211:1980 212:2987 213:2822 214:1033 215:54 216:6025 217:2172 218:868 219:579 220:1796 221:1001 222:984 223:1396 End of report From bryce at thenetworknerds.ca Fri Oct 12 18:07:01 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Fri, 12 Oct 2018 11:07:01 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <20181012110058.4699E099@m0117458.ppops.net> References: <20181012110058.4699E099@m0117458.ppops.net> Message-ID: <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> > Make a second account at your bank. One account is > 'storage' and has all your money. You never use > the 'storage account' ATM card for anything outside > your bank's ATM machines. > > The second one is where you only keep $50-$100 in > it. When you use your ATM card it's only this account > that's used. Just before you make a purchase, move > money from your 'storage account' into your 'active > account' and make the purchase. I second the idea of having a storage account. I do a similar thing myself but for other reasons. I always just keep $100 and every time I make a purchase I move money from my storage account over. The only problem is that this does not work as well with credit cards. I believe that in the US there is some form of company that allows you to make temporary cards for online purchases. Thanks ~ Bryce Wilson, AS202313 -------------- next part -------------- An HTML attachment was scrubbed... URL: From endre.szabo at nanog-list-kitfvhs.redir.email Wed Oct 10 14:50:43 2018 From: endre.szabo at nanog-list-kitfvhs.redir.email (endre.szabo at nanog-list-kitfvhs.redir.email) Date: Wed, 10 Oct 2018 16:50:43 +0200 Subject: Spectrum residential IPv6 rDNS - thank you ! In-Reply-To: References: Message-ID: Hi there, On 10/10/18 3:43 AM, Chris wrote: > > Originally I was using the pipe backend with a modified copy of > "PowerDNS-Dynamic-Reverse-Backend" > (https://github.com/endreszabo/PowerDNS-Dynamic-Reverse-Backend) but > ended up writing my own in Perl as the backend was a bit fragile and > didn't do everything I wanted. I love you Chris <3 I would really like to know what made you think that it is a bit fragile? Crashes, slow responses? PowerDNS can make a great use of the so called 'packet caching' to cache pipe backend results. I admit that this code was not really in production on a public network just on some private ones. And enhancement ideas? What else did you want the script to do? Thanks for referencing. -- Endre From paulzugnoni at gmail.com Thu Oct 11 05:04:25 2018 From: paulzugnoni at gmail.com (Paul Zugnoni) Date: Wed, 10 Oct 2018 22:04:25 -0700 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: Message-ID: The key to answering the question of NAT support on a Broadcom switch forwarding chip, is... another question: What /flavour of NAT/ you're looking for. Generally Trident (1,2,3), Tomahawk(1,2) and I believe Jericho all support varying degrees of swapping parts of an IP or Eth header for other parts - i.e. TTL of 249 in, TTL of 248 out, MPLS tag 500 in, MPLS tag 513 out. And, to your benefit, SRC IP of 10.1.1.1 in, SRC IP of 10.2.2.2 out. That can be handled at line rate (yes 10G); how many of those rules depends on the chip. So that's perfectly fine for static NAT. Problem with static NAT (i.e. 1:1) isn't what I suspect most of us are looking for. PAT, or "nat overload" - i.e. your internal 10.x or 192.168.x networks to the internet using one or a few public IPv4's - requires stateful tracking, which is not what any of those chips do. So you're dependent on what route engine and software is in use to supply stateful NAT / PAT, and the requirement being higher there generally means you'll need a firewall or router (which, btw, might actually be using one of the aforementioned Broadcom switch chips for the forwarding plane!). To achieve line rate for stateful NAT / PAT there's more than the switch chip and software in the equation, and can be the limiting factor to achieving "line rate" for a set of 10G ports. PZ On Wed, Oct 10, 2018 at 12:20 PM Wes Felter wrote: > On 10/9/18 10:35 AM, Jason Lixfeld wrote: > > Has anyone played around with this? Curious if the BCM (or whatever > other chip) can do this, and if not, if any of the box vendors have tried > to find a way to get these things to do a bunch of NAT - say some flavour > of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for > it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but > not sure if there are others out there. > > For 10G I would use software NAT like a firewall or CGN virtual > appliance. Switch ASICs generally don't support NAT well; Tofino and > maybe Jericho II can probably do it but at high cost and as you > discovered the market isn't trying very hard to provide "routing" or > "firewalling" functionality on "switching" ASICs. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Oct 12 18:08:09 2018 From: randy at psg.com (Randy Bush) Date: Fri, 12 Oct 2018 11:08:09 -0700 Subject: ifIndex Message-ID: do folk have experience with platforms where ifIndexes are not stable across reboots etc? how do you deal with it? do some of those platforms trap on change? randy, who hates ifIndex changes From smeuse at mara.org Fri Oct 12 18:23:56 2018 From: smeuse at mara.org (Steve Meuse) Date: Fri, 12 Oct 2018 14:23:56 -0400 Subject: ifIndex In-Reply-To: References: Message-ID: Most platforms I've worked with have a method to make the indexes persistent, often by additional command-line options. -Steve On Fri, Oct 12, 2018 at 2:08 PM Randy Bush wrote: > do folk have experience with platforms where ifIndexes are not stable > across reboots etc? how do you deal with it? do some of those > platforms trap on change? > > randy, who hates ifIndex changes > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Fri Oct 12 18:30:39 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Oct 2018 11:30:39 -0700 Subject: ifIndex Message-ID: <20181012113039.4699E6BC@m0117458.ppops.net> --- randy at psg.com wrote: From: Randy Bush do folk have experience with platforms where ifIndexes are not stable across reboots etc? how do you deal with it? do some of those platforms trap on change? ----------------------------------- I'm surprised everyone doesn't have stable ifIndexes these days. That's straight outta the 90s! Care to name-n-shame the vendor, so we can all be aware when evaluating vendors? scott From cma at cmadams.net Fri Oct 12 18:37:43 2018 From: cma at cmadams.net (Chris Adams) Date: Fri, 12 Oct 2018 13:37:43 -0500 Subject: ifIndex In-Reply-To: References: Message-ID: <20181012183743.GA5402@cmadams.net> Once upon a time, Randy Bush said: > do folk have experience with platforms where ifIndexes are not stable > across reboots etc? how do you deal with it? do some of those > platforms trap on change? Is there any good excuse that SNMP client software can't handle a basic design of SNMP - indexed tables? ifIndex is far from the only index in SNMP, and many of them still change today at various times. It isn't that hard to fetch the indexed field in a bulk get, rewalking the table if you don't get what you expected. Cricket did this in 1999. -- Chris Adams From sean at donelan.com Fri Oct 12 20:09:07 2018 From: sean at donelan.com (Sean Donelan) Date: Fri, 12 Oct 2018 16:09:07 -0400 (EDT) Subject: Hurricane Michael: Communication Service Provider status In-Reply-To: References: Message-ID: Note: although the FCC encourages independent ISPs to report outages, none have. 13 fatalities reported as of 10/12/2018 Public Safety Answering Points (9-1-1) outages: 16 Public Safety Answering Points rerouted Curfews: Florida: Bay, Franklin, Gadsden, Gulf, Jackson, Liberty Electric grid outages: Alabama: 25,652 customers (1.01%) Florida: 351,433 customers (3.34%) Georgia: 304,862 customers (6.44%) North Carolina: 492,058 customers (9.94%) South Carolina: 7,422 customers (0.29%) Virginia 523,304 customers (13.92%) Florida Counties with more than 90% customers outage: Bradford (91%), Calhoun (100%), Franklin (97%), Gadsden (100%), Gulf (99%), Holmes (93%), Jackson (100%), Liberty (100%), Washington (100%) Airport status: All commercial airports have re-opened. Various temporary flight restrictions announced in NOTAMs. Sea port status: Panama City, FL closed Wilmington, NC closed Retail fuel stations (out of fuel, power or both): 6.3% of all Florida stations closed 41% of Florida panhandle stations closed 3.2% of Georgia stations closed 1.7% of Alabama stations closed NOAA Weather Radio transmitters out of service (hurricane area): Columbus, AL Talahassee, FL Sneads, FL Westville, FL East Point, FL Panama City, FL Pelham, GA Lafayette, LA New Bern, NC Henderson, NC Cellular Service (more than 50% out of service): Bay County, FL (72.8%) 238 sites out of service Gadsden County, FL (58.10%) 36 sites out of service Gulf County, FL (65.20%) 15 sites out of service Washington County, FL (56.40%) 22 sites out of service Cable systems and Wireline subscriber reported outages (likely more, since customers may not have reported problems yet, e.g. no outages reported in Virgina) Alabama: 18,244 Florida: 252,748 Georgia: 103,755 Broadcasters: 4 TV stations out of service 27 FM stations out of service 5 AM stations out of service From SNaslund at medline.com Fri Oct 12 20:32:54 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 12 Oct 2018 20:32:54 +0000 Subject: ifIndex In-Reply-To: <20181012183743.GA5402@cmadams.net> References: <20181012183743.GA5402@cmadams.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40301ACAF44@MUNPRDMBXA1.medline.com> I see this all the time. Especially in module chassis. It seems like sometimes it has to do with when each board goes to a ready state as the system boots. We also see renumbering due to virtual interface and board additions. While you are running they seem to get the next ifindex available but when you reboot the seem to be in the order they come up or the order they are in the configuration. It is a real pain and some software allows us to rescan a device and other software we have no easy way other than to delete and the re-add the device. I feel your pain on this one. I have no idea why most NMS systems can't seem to understand this and just rescan at a set interval or after an up/down device event. Steven Naslund Chicago IL > do folk have experience with platforms where ifIndexes are not stable > across reboots etc? how do you deal with it? do some of those > platforms trap on change? From mel at beckman.org Fri Oct 12 20:36:14 2018 From: mel at beckman.org (Mel Beckman) Date: Fri, 12 Oct 2018 20:36:14 +0000 Subject: ifIndex In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301ACAF44@MUNPRDMBXA1.medline.com> References: <20181012183743.GA5402@cmadams.net>, <9578293AE169674F9A048B2BC9A081B40301ACAF44@MUNPRDMBXA1.medline.com> Message-ID: Cisco has a feature you can enable called “Interface Index Persistence”: https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/28420-ifIndex-Persistence.html This solves the problem, at least with Cisco gear. -mel beckman On Oct 12, 2018, at 1:33 PM, Naslund, Steve > wrote: I see this all the time. Especially in module chassis. It seems like sometimes it has to do with when each board goes to a ready state as the system boots. We also see renumbering due to virtual interface and board additions. While you are running they seem to get the next ifindex available but when you reboot the seem to be in the order they come up or the order they are in the configuration. It is a real pain and some software allows us to rescan a device and other software we have no easy way other than to delete and the re-add the device. I feel your pain on this one. I have no idea why most NMS systems can't seem to understand this and just rescan at a set interval or after an up/down device event. Steven Naslund Chicago IL do folk have experience with platforms where ifIndexes are not stable across reboots etc? how do you deal with it? do some of those platforms trap on change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Fri Oct 12 20:37:50 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 12 Oct 2018 20:37:50 +0000 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> References: <20181012110058.4699E099@m0117458.ppops.net> <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> Message-ID: <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> >Make a second account at your bank. One account is >'storage' and has all your money. You never use >the 'storage account' ATM card for anything outside >your bank's ATM machines. Doubling the service fees from your bank. >The second one is where you only keep $50-$100 in >it. When you use your ATM card it's only this account >that's used. Just before you make a purchase, move >money from your 'storage account' into your 'active >account' and make the purchase. Don’t really want to be doing transfers with service fees every time I decide to fill up the gas tank. Also, lots of banks will allow overdrafts which creates even more fees and some even auto transfer from one account to another to cover your overdrafts. Also, does nothing for credit cards at all. Steven Naslund Chicago IL -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Fri Oct 12 20:46:16 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Fri, 12 Oct 2018 13:46:16 -0700 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> References: <20181012110058.4699E099@m0117458.ppops.net> <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> Message-ID: <39B5FD9E-F0DB-4841-BBC6-E7361CC42676@thenetworknerds.ca> > Doubling the service fees from your bank. Depends on the bank. At my bank if you have a checking account, you can get a basic savings acolytes for free. They also have free transfers between accounts (which is very nice because on the basic savings account you are not allowed and other type of transfer for free). Your second point about the overdraft fees is again dependent on banks. For mine if you don’t have enough money it will just decline the transaction. It’s true that this does nothing for credit cards though and the constant transferring on money is rather annoying. Thanks ~ Bryce Wilson, AS202313 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Oct 12 20:53:19 2018 From: bill at herrin.us (William Herrin) Date: Fri, 12 Oct 2018 16:53:19 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> References: <20181012110058.4699E099@m0117458.ppops.net> <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Oct 12, 2018 at 4:39 PM Naslund, Steve wrote: > >Make a second account at your bank. One account is > >'storage' and has all your money. You never use > >the 'storage account' ATM card for anything outside > >your bank's ATM machines. > > Doubling the service fees from your bank. Hi Steve, Your bank charges you service fees? When I opened an additional checking account so I'd have something to link paypal to, it was free. > >The second one is where you only keep $50-$100 in > >it. When you use your ATM card it's only this account > >that's used. Just before you make a purchase, move > >money from your 'storage account' into your 'active > >account' and make the purchase. > > Don’t really want to be doing transfers with service fees > every time I decide to fill up the gas tank. Your bank charges you a service fee to move money from one account to another at the same bank? Weird. Also, why would you buy gas (or anything else) with a debit card? Your legal liability protections with a credit card are better. Under the Fair Credit Billing Act, the consumer's maximum liability for a credit card breach is $50 and most banks waive that as well. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From surfer at mauigateway.com Fri Oct 12 21:36:53 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Oct 2018 14:36:53 -0700 Subject: bloomberg on supermicro: sky is falling Message-ID: <20181012143653.4699F3DA@m0117458.ppops.net> --- SNaslund at medline.com wrote: From: "Naslund, Steve" >Make a second account at your bank. One account is >'storage' and has all your money. You never use >the 'storage account' ATM card for anything outside >your bank's ATM machines. Doubling the service fees from your bank. ---------------------------------------------------- No, it's free. It also depends on the type of accounts you set up. Most banks I have heard of do this for free. >The second one is where you only keep $50-$100 in >it. When you use your ATM card it's only this account >that's used. Just before you make a purchase, move >money from your 'storage account' into your 'active >account' and make the purchase. Don’t really want to be doing transfers with service fees every time I decide to fill up the gas tank. Also, lots of banks will allow overdrafts which creates even more fees and some even auto transfer from one account to another to cover your overdrafts. Also, does nothing for credit cards at all. -------------------------------------------------- This is all under your control. I don't use ATM cards at gas stations or other places like that. Mostly it's for online purchases and to get money from non-bank ATM machines and I pay nothing extra. Last, I don't allow overdrafts. No money in the account; nothing can be bought. scott From matt at netfire.net Fri Oct 12 21:38:32 2018 From: matt at netfire.net (Matt Harris) Date: Fri, 12 Oct 2018 16:38:32 -0500 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181012110058.4699E099@m0117458.ppops.net> <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Oct 12, 2018 at 3:53 PM William Herrin wrote: > > Your bank charges you service fees? > > When I opened an additional checking account so I'd have something to > link paypal to, it was free. > Plus you don't earn rewards points. I use an amex charge card for just about everything, never pay a dime in interest, and my annual fee is offset by about 5x by my points earnings. Any bank that charges for basic transfers and such is terrible - and yeah I know it's fairly common amongst the largest banks in the US... I use a small credit union and they're great. The only time I've ever paid them a fee for a service was when I did a very large wire transfer when I bought my house. I'd recommend checking out some local credit unions to find better, more consumer-friendly policies and fee schedules. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dedelman at iname.com Fri Oct 12 21:52:44 2018 From: dedelman at iname.com (David Edelman) Date: Fri, 12 Oct 2018 17:52:44 -0400 Subject: bloomberg on supermicro: sky is falling In-Reply-To: References: <20181012110058.4699E099@m0117458.ppops.net> <592976FD-2A37-4B4F-9247-FCB3DA2FDA41@thenetworknerds.ca> <9578293AE169674F9A048B2BC9A081B40301ACAF8B@MUNPRDMBXA1.medline.com> Message-ID: <02a601d46275$eaa0a800$bfe1f800$@iname.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree that bank fees for transfers between accounts is unusual. There may be a limit on the number of transfers you can do each month but typically no fees. I agree with the point about using a credit card for gas purchases, since you are currently using a debit card, you are going to be paying the credit card off each month and there is no interest charge, this assumes that you have a credit card already. If you do have a credit card and it isn't one that has awards, consider switching to one that does have awards that are useful to you. Switch all of the stuff that you would normally pay with the ATM card to the credit card but remember treat the credit card like an ATM card and pay in full each billing cycle. I would argue that the liability protections are actually better with an ATM card since there is a requirement for the bank to make you whole without even a $50 maximum liability. The user experience may be better with the credit card. Dave Edelman - -----Original Message----- From: NANOG On Behalf Of William Herrin Sent: Friday, October 12, 2018 4:53 PM To: Naslund, Steve Cc: nanog at nanog.org Subject: Re: bloomberg on supermicro: sky is falling On Fri, Oct 12, 2018 at 4:39 PM Naslund, Steve wrote: > >Make a second account at your bank. One account is 'storage' and has > >all your money. You never use the 'storage account' ATM card for > >anything outside your bank's ATM machines. > > Doubling the service fees from your bank. Hi Steve, Your bank charges you service fees? When I opened an additional checking account so I'd have something to link paypal to, it was free. > >The second one is where you only keep $50-$100 in it. When you use > >your ATM card it's only this account that's used. Just before you > >make a purchase, move money from your 'storage account' into your > >'active account' and make the purchase. > > Don’t really want to be doing transfers with service fees every time I > decide to fill up the gas tank. Your bank charges you a service fee to move money from one account to another at the same bank? Weird. Also, why would you buy gas (or anything else) with a debit card? Your legal liability protections with a credit card are better. Under the Fair Credit Billing Act, the consumer's maximum liability for a credit card breach is $50 and most banks waive that as well. Regards, Bill Herrin - -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCW8EXowAKCRCXCCyZOY1F Ib9nAKDKOUa+9HbWpWUxLqjHKe+BqQfJQACfbSNVz1rI2RNx004qw3B299L/E8Q= =LUpC -----END PGP SIGNATURE----- From saku at ytti.fi Sat Oct 13 09:57:17 2018 From: saku at ytti.fi (Saku Ytti) Date: Sat, 13 Oct 2018 12:57:17 +0300 Subject: ifIndex In-Reply-To: <20181012183743.GA5402@cmadams.net> References: <20181012183743.GA5402@cmadams.net> Message-ID: On Fri, 12 Oct 2018 at 21:40, Chris Adams wrote: > Is there any good excuse that SNMP client software can't handle a basic > design of SNMP - indexed tables? ifIndex is far from the only index in > SNMP, and many of them still change today at various times. > > It isn't that hard to fetch the indexed field in a bulk get, rewalking > the table if you don't get what you expected. Cricket did this in 1999. It's never going to be provably correct, depending on what stability means. You fetch relation at t0, then at t1 you fetch data. Was the relation same at t0 and t1? You can gain some confidence by fetching relation again at t2 and disregard data if t0 != t2. But this becomes polling expensive quite fast, and still not provably correct. This may be nitpicking, but I've always felt uneasy about the lack of guarantee. I wonder if those who have stable indeces, have them for all cases, all logical interfaces and virtual interfaces? -- ++ytti From mel at beckman.org Sat Oct 13 12:45:29 2018 From: mel at beckman.org (Mel Beckman) Date: Sat, 13 Oct 2018 12:45:29 +0000 Subject: ifIndex In-Reply-To: References: <20181012183743.GA5402@cmadams.net>, Message-ID: Saku, The issue isn't that ifindexes change during operation. That would truly make SNMP useless. The issue is that they change across reboots. That's where features such as Cisco's Interface Index Persistence helps out. -mel via cell > On Oct 13, 2018, at 2:59 AM, Saku Ytti wrote: > >> On Fri, 12 Oct 2018 at 21:40, Chris Adams wrote: >> >> Is there any good excuse that SNMP client software can't handle a basic >> design of SNMP - indexed tables? ifIndex is far from the only index in >> SNMP, and many of them still change today at various times. >> >> It isn't that hard to fetch the indexed field in a bulk get, rewalking >> the table if you don't get what you expected. Cricket did this in 1999. > > It's never going to be provably correct, depending on what stability means. > > You fetch relation at t0, then at t1 you fetch data. Was the relation > same at t0 and t1? You can gain some confidence by fetching relation > again at t2 and disregard data if t0 != t2. But this becomes polling > expensive quite fast, and still not provably correct. This may be > nitpicking, but I've always felt uneasy about the lack of guarantee. > > I wonder if those who have stable indeces, have them for all cases, > all logical interfaces and virtual interfaces? > > -- > ++ytti From jcurran at istaff.org Sat Oct 13 13:35:36 2018 From: jcurran at istaff.org (John Curran) Date: Sat, 13 Oct 2018 09:35:36 -0400 Subject: Software installation tools retrieving ARIN TAL (was: Re: ARIN RPKI TAL deployment issues) In-Reply-To: <20180925193451.GM77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> Message-ID: On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > ... > What I'm hoping for is that there is a way for the ARIN TAL to be > included in software distributions, without compromising ARIN's legal > position. > > Perhaps an exception for software distributors would already go a long > way? > > "You can include the ARIN TAL in your software distribution as long > as you also include an unmodified copy of the > https://www.arin.net/resources/rpki/rpa.pdf file alongside it." > > Kind regards, Job - While not exactly what you seek, we can get a bit closer to the goal – i.e. by eliminating the need for the user installing a software package to first go get the ARIN TAL and put it in the right place prior to running the installation software. To that end, the ARIN TAL page > has been revised with specific guidance – Software Installation Tools Software installation tools may download the ARIN TAL on behalf of a user after the user has confirmed their acceptance of the ARIN Relying Party Agreement (RPA) on the ARIN website. This acceptance must require "agreement to the ARIN Relying Party Agreement (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a non-ambiguous affirmative action by clicking on, or the entry of, a word of agreement (such as "yes" or "accept") Example: Attention: This package requires the download of the ARIN TAL and agreement to the ARIN Relying Party Agreement (RPA) (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree, and you can proceed with the ARIN TAL download: yes We will continue to explore mechanisms for making ARIN’s RPKI repository more accessible to the community, but felt that this interim step could be accomplished promptly and was worth noting in a timely manner to those distributing RPKI software. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Sat Oct 13 13:48:17 2018 From: job at ntt.net (Job Snijders) Date: Sat, 13 Oct 2018 15:48:17 +0200 Subject: Software installation tools retrieving ARIN TAL (was: Re: ARIN RPKI TAL deployment issues) In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> Message-ID: <20181013134817.GE5430@hanna.meerval.net> Dear John, I'd like to thank you and the ARIN team for these efforts - in doing so I feel that ARIN recognises issues & concerns related to the distribution of the ARIN RPKI TAL. Acknowledging a problem is the first step to solving it! On Sat, Oct 13, 2018 at 09:35:36AM -0400, John Curran wrote: > On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > > ... > > What I'm hoping for is that there is a way for the ARIN TAL to be > > included in software distributions, without compromising ARIN's > > legal position. > > > > Perhaps an exception for software distributors would already go a > > long way? > > While not exactly what you seek, we can get a bit closer to the goal – > i.e. by eliminating the need for the user installing a software > package to first go get the ARIN TAL and put it in the right place > prior to running the installation software. > > To that end, the ARIN TAL page > https://www.arin.net/resources/rpki/tal.html has been revised with > specific guidance – > > Software Installation Tools > > Software installation tools may download the ARIN TAL on behalf of a > user after the user has confirmed their acceptance of the ARIN > Relying Party Agreement (RPA) on the ARIN website. This acceptance > must require "agreement to the ARIN Relying Party Agreement > (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a > non-ambiguous affirmative action by clicking on, or the entry of, a > word of agreement (such as "yes" or "accept") > > Example: Attention: This package requires the download of the ARIN TAL > and agreement to the ARIN Relying Party Agreement (RPA) > (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree, > and you can proceed with the ARIN TAL download: yes In this approach I still observe an institutional barrier. If we take DNSSEC as analogous concept, when installing & starting BIND, unbound, NSD, knot, Microsoft DNS, or PowerDNS, no affirmative actions are required. It is also not clear to me how in context of fully automated installation & deployment the paradigm of 'non-ambiguous affirmative action' can exist. If we instruct orchastration software to say 'yes' to whatever questions pop up what does that actually mean? It certainly no longer adheres to the spirit of whatever it is that ARIN seeks. Lastly - having to download a file ('requiring specific network connectivity') in context of installation & deployment is always inferior compared to bundling all required pieces into coherent software packages. > We will continue to explore mechanisms for making ARIN’s RPKI > repository more accessible to the community, but felt that this > interim step could be accomplished promptly and was worth noting in a > timely manner to those distributing RPKI software. Yes - please do. Providing guidance to software distributors does not change some of the challenging contents of the RPA, nor does it address the fundamental institutional barrier that separates the ARIN TAL from the other RIR TALs. Kind regards, Job From dhubbard at dino.hostasaurus.com Sat Oct 13 16:19:33 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 13 Oct 2018 16:19:33 +0000 Subject: ifIndex In-Reply-To: References: <20181012183743.GA5402@cmadams.net> Message-ID: Cisco tries very hard to make such useless data occur in XR. If you have a gigE SFP in an SFP+ port, a new ifindex will appear for the resulting GigabitEthernetX port, then it remains even if both the config and SFP have been removed. Automated systems will keep querying it as if it were a downed port, but wait, reboot, and suddenly it vanishes. I went back and forth with TAC for weeks explaining that SNMP interfaces should not disappear as a result of a reboot, I should either be able to remove it, or it's stuck there forever, but a reboot should not cause a change. They didn't care; it is 'by design'. On 10/13/18, 8:47 AM, "NANOG on behalf of Mel Beckman" wrote: Saku, The issue isn't that ifindexes change during operation. That would truly make SNMP useless. The issue is that they change across reboots. That's where features such as Cisco's Interface Index Persistence helps out. -mel via cell > On Oct 13, 2018, at 2:59 AM, Saku Ytti wrote: > >> On Fri, 12 Oct 2018 at 21:40, Chris Adams wrote: >> >> Is there any good excuse that SNMP client software can't handle a basic >> design of SNMP - indexed tables? ifIndex is far from the only index in >> SNMP, and many of them still change today at various times. >> >> It isn't that hard to fetch the indexed field in a bulk get, rewalking >> the table if you don't get what you expected. Cricket did this in 1999. > > It's never going to be provably correct, depending on what stability means. > > You fetch relation at t0, then at t1 you fetch data. Was the relation > same at t0 and t1? You can gain some confidence by fetching relation > again at t2 and disregard data if t0 != t2. But this becomes polling > expensive quite fast, and still not provably correct. This may be > nitpicking, but I've always felt uneasy about the lack of guarantee. > > I wonder if those who have stable indeces, have them for all cases, > all logical interfaces and virtual interfaces? > > -- > ++ytti From jason at unlimitednet.us Sat Oct 13 16:35:39 2018 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 13 Oct 2018 12:35:39 -0400 Subject: Hulu / ESPN: Commercial IP Address Message-ID: Hello, I have a customer that is using Hulu Live to stream ESPN, however it isn't showing up in their Channel list.  They reached out to Hulu and it's because their IP address is 'commercial'.  We have many customers using Hulu without problems, but it seems specific to ESPN.  Anyone else have this issue?  Do you reach out to ESPN or Hulu? If anyone has any information, please share it.  Appreciate your help in advance! Best Regards, Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure From dcorbe at hammerfiber.com Sat Oct 13 18:39:37 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Sat, 13 Oct 2018 14:39:37 -0400 Subject: Hulu / ESPN: Commercial IP Address In-Reply-To: References: Message-ID: I had a customer with a similar issue. I statically assigned them a different IP and it didn’t resolve it. The problem turned out to be tied to their Hulu account. The customer is going to need to keep pressing the issue with Hulu’s technical support group. Make sure they’re not using a VPN to connect to the Internet and have them keep calling Hulu back until they get someone clueful on the phone. In my customer’s case, they eventually had to “re-home” them to resolve it. I have no idea what that entails. -Daniel at 12:35 PM, Jason Canady wrote: > Hello, > > I have a customer that is using Hulu Live to stream ESPN, however it > isn't showing up in their Channel list. They reached out to Hulu and > it's because their IP address is 'commercial'. We have many customers > using Hulu without problems, but it seems specific to ESPN. Anyone else > have this issue? Do you reach out to ESPN or Hulu? > > If anyone has any information, please share it. Appreciate your help in > advance! > > Best Regards, > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure From mel at beckman.org Sat Oct 13 20:46:00 2018 From: mel at beckman.org (Mel Beckman) Date: Sat, 13 Oct 2018 20:46:00 +0000 Subject: ifIndex In-Reply-To: References: <20181012183743.GA5402@cmadams.net> , Message-ID: <7FB9A052-9E33-42EB-8DB3-B00293B2CF5C@beckman.org> David, All you have to do is turn on IFindex persistence: https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/system_management/command/reference/b_sysman_cr42crs/b_sysman_cr42crs_chapter_01101.html#wp2192797756 We do this on our XRs and it works perfectly. -mel via cell On Oct 13, 2018, at 9:20 AM, David Hubbard > wrote: Cisco tries very hard to make such useless data occur in XR. If you have a gigE SFP in an SFP+ port, a new ifindex will appear for the resulting GigabitEthernetX port, then it remains even if both the config and SFP have been removed. Automated systems will keep querying it as if it were a downed port, but wait, reboot, and suddenly it vanishes. I went back and forth with TAC for weeks explaining that SNMP interfaces should not disappear as a result of a reboot, I should either be able to remove it, or it's stuck there forever, but a reboot should not cause a change. They didn't care; it is 'by design'. On 10/13/18, 8:47 AM, "NANOG on behalf of Mel Beckman" on behalf of mel at beckman.org> wrote: Saku, The issue isn't that ifindexes change during operation. That would truly make SNMP useless. The issue is that they change across reboots. That's where features such as Cisco's Interface Index Persistence helps out. -mel via cell On Oct 13, 2018, at 2:59 AM, Saku Ytti > wrote: On Fri, 12 Oct 2018 at 21:40, Chris Adams > wrote: Is there any good excuse that SNMP client software can't handle a basic design of SNMP - indexed tables? ifIndex is far from the only index in SNMP, and many of them still change today at various times. It isn't that hard to fetch the indexed field in a bulk get, rewalking the table if you don't get what you expected. Cricket did this in 1999. It's never going to be provably correct, depending on what stability means. You fetch relation at t0, then at t1 you fetch data. Was the relation same at t0 and t1? You can gain some confidence by fetching relation again at t2 and disregard data if t0 != t2. But this becomes polling expensive quite fast, and still not provably correct. This may be nitpicking, but I've always felt uneasy about the lack of guarantee. I wonder if those who have stable indeces, have them for all cases, all logical interfaces and virtual interfaces? -- ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Sat Oct 13 21:43:35 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 13 Oct 2018 21:43:35 +0000 Subject: ifIndex In-Reply-To: <7FB9A052-9E33-42EB-8DB3-B00293B2CF5C@beckman.org> References: <20181012183743.GA5402@cmadams.net> <7FB9A052-9E33-42EB-8DB3-B00293B2CF5C@beckman.org> Message-ID: <49D2CD4C-6308-4834-BFE1-6886C3044C40@dino.hostasaurus.com> I do that too, but I’m referring to XR when you use different speed optics in a multi-speed port; if you have a SFP+ port and 10gig SFP, you’ll get one ifindex. New use case requires swapping to a gigE SFP and you’ll get a new ifindex. Take the port out of service, remove the GigE SFP and the related config, yet both ifindexes remain; until the device is reloaded. At that the gigE ifindex goes away leaving just the native-speed ifindex. It’s a pain for management because we’re forced to make exclusions in our NMS for ifindex’s that may disappear at some point, because they show as down with no way to make that not the case. Worse, if that port is put to use again at the non-native speed, and has such an exclusion in place, we don’t auto learn the new usage because of the exclusion. I tried to argue with TAC that if the gigE SFP has been removed from the SFP+ port, and its config has been deleted, the corresponding ifindex and related counters should be gone; it no longer exists in any form. If you reload, it will disappear, but that’s the only way. From: Mel Beckman Date: Saturday, October 13, 2018 at 4:46 PM To: David Hubbard Cc: "nanog at nanog.org" Subject: Re: ifIndex David, All you have to do is turn on IFindex persistence: https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/system_management/command/reference/b_sysman_cr42crs/b_sysman_cr42crs_chapter_01101.html#wp2192797756 We do this on our XRs and it works perfectly. -mel via cell On Oct 13, 2018, at 9:20 AM, David Hubbard > wrote: Cisco tries very hard to make such useless data occur in XR. If you have a gigE SFP in an SFP+ port, a new ifindex will appear for the resulting GigabitEthernetX port, then it remains even if both the config and SFP have been removed. Automated systems will keep querying it as if it were a downed port, but wait, reboot, and suddenly it vanishes. I went back and forth with TAC for weeks explaining that SNMP interfaces should not disappear as a result of a reboot, I should either be able to remove it, or it's stuck there forever, but a reboot should not cause a change. They didn't care; it is 'by design'. On 10/13/18, 8:47 AM, "NANOG on behalf of Mel Beckman" on behalf of mel at beckman.org> wrote: Saku, The issue isn't that ifindexes change during operation. That would truly make SNMP useless. The issue is that they change across reboots. That's where features such as Cisco's Interface Index Persistence helps out. -mel via cell On Oct 13, 2018, at 2:59 AM, Saku Ytti > wrote: On Fri, 12 Oct 2018 at 21:40, Chris Adams > wrote: Is there any good excuse that SNMP client software can't handle a basic design of SNMP - indexed tables? ifIndex is far from the only index in SNMP, and many of them still change today at various times. It isn't that hard to fetch the indexed field in a bulk get, rewalking the table if you don't get what you expected. Cricket did this in 1999. It's never going to be provably correct, depending on what stability means. You fetch relation at t0, then at t1 you fetch data. Was the relation same at t0 and t1? You can gain some confidence by fetching relation again at t2 and disregard data if t0 != t2. But this becomes polling expensive quite fast, and still not provably correct. This may be nitpicking, but I've always felt uneasy about the lack of guarantee. I wonder if those who have stable indeces, have them for all cases, all logical interfaces and virtual interfaces? -- ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyler at exospec.us Sat Oct 13 20:06:17 2018 From: tyler at exospec.us (Tyler Harden) Date: Sat, 13 Oct 2018 16:06:17 -0400 Subject: Hulu / ESPN: Commercial IP Address In-Reply-To: References: Message-ID: This happens a lot with people who share their Hulu with friends. Your IP can get tagged as commercial for abuse of their service, especially if using their TV service. > On Oct 13, 2018, at 14:39, Daniel Corbe wrote: > > I had a customer with a similar issue. I statically assigned them a different IP and it didn’t resolve it. The problem turned out to be tied to their Hulu account. > > The customer is going to need to keep pressing the issue with Hulu’s technical support group. Make sure they’re not using a VPN to connect to the Internet and have them keep calling Hulu back until they get someone clueful on the phone. > > In my customer’s case, they eventually had to “re-home” them to resolve it. I have no idea what that entails. > > -Daniel > > at 12:35 PM, Jason Canady wrote: > >> Hello, >> >> I have a customer that is using Hulu Live to stream ESPN, however it isn't showing up in their Channel list. They reached out to Hulu and it's because their IP address is 'commercial'. We have many customers using Hulu without problems, but it seems specific to ESPN. Anyone else have this issue? Do you reach out to ESPN or Hulu? >> >> If anyone has any information, please share it. Appreciate your help in advance! >> >> Best Regards, >> >> Jason Canady >> Unlimited Net, LLC >> Responsive, Reliable, Secure > > From baldur.norddahl at gmail.com Sun Oct 14 21:17:11 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 14 Oct 2018 23:17:11 +0200 Subject: Software installation tools retrieving ARIN TAL (was: Re: ARIN RPKI TAL deployment issues) In-Reply-To: <20181013134817.GE5430@hanna.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <20181013134817.GE5430@hanna.meerval.net> Message-ID: Is the ARIN TAL copyrighted? Is it even copyrightable? It has no creative value, which is a requirement in european law. Why would not RIPE just include it like they do for every other RIR TAL? lør. 13. okt. 2018 15.49 skrev Job Snijders : > Dear John, > > I'd like to thank you and the ARIN team for these efforts - in doing so > I feel that ARIN recognises issues & concerns related to the > distribution of the ARIN RPKI TAL. Acknowledging a problem is the first > step to solving it! > > On Sat, Oct 13, 2018 at 09:35:36AM -0400, John Curran wrote: > > On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > > > ... > > > What I'm hoping for is that there is a way for the ARIN TAL to be > > > included in software distributions, without compromising ARIN's > > > legal position. > > > > > > Perhaps an exception for software distributors would already go a > > > long way? > > > > While not exactly what you seek, we can get a bit closer to the goal – > > i.e. by eliminating the need for the user installing a software > > package to first go get the ARIN TAL and put it in the right place > > prior to running the installation software. > > > > To that end, the ARIN TAL page > > https://www.arin.net/resources/rpki/tal.html has been revised with > > specific guidance – > > > > Software Installation Tools > > > > Software installation tools may download the ARIN TAL on behalf of > a > > user after the user has confirmed their acceptance of the ARIN > > Relying Party Agreement (RPA) on the ARIN website. This acceptance > > must require "agreement to the ARIN Relying Party Agreement > > (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a > > non-ambiguous affirmative action by clicking on, or the entry of, a > > word of agreement (such as "yes" or "accept") > > > > Example: Attention: This package requires the download of the ARIN TAL > > and agreement to the ARIN Relying Party Agreement (RPA) > > (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree, > > and you can proceed with the ARIN TAL download: yes > > In this approach I still observe an institutional barrier. If we take > DNSSEC as analogous concept, when installing & starting BIND, unbound, > NSD, knot, Microsoft DNS, or PowerDNS, no affirmative actions are > required. > > It is also not clear to me how in context of fully automated > installation & deployment the paradigm of 'non-ambiguous affirmative > action' can exist. If we instruct orchastration software to say 'yes' to > whatever questions pop up what does that actually mean? It certainly no > longer adheres to the spirit of whatever it is that ARIN seeks. > > Lastly - having to download a file ('requiring specific network > connectivity') in context of installation & deployment is always > inferior compared to bundling all required pieces into coherent software > packages. > > > We will continue to explore mechanisms for making ARIN’s RPKI > > repository more accessible to the community, but felt that this > > interim step could be accomplished promptly and was worth noting in a > > timely manner to those distributing RPKI software. > > Yes - please do. Providing guidance to software distributors does not > change some of the challenging contents of the RPA, nor does it address > the fundamental institutional barrier that separates the ARIN TAL from > the other RIR TALs. > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Mon Oct 15 01:03:38 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 14 Oct 2018 20:03:38 -0500 Subject: Hulu / ESPN: Commercial IP Address In-Reply-To: References: Message-ID: <7D4BF095-E028-4D4B-8983-972FA6F8F5CC@dataix.net> Exactly ... blocked or rate limited from.a /20 or /18 but it’s pretty hard to diff from same customer that is also watching from a full routed VPN’d service for privacy which I find quite often being implemented in services like AdBlock, AdGuard and the like which becomes a point of confusion for the svc providers. It’s not necessarily sharing when you find the user in the US also logging in from Italy or France for example. -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Oct 13, 2018, at 15:06, Tyler Harden wrote: > > This happens a lot with people who share their Hulu with friends. Your IP can get tagged as commercial for abuse of their service, especially if using their TV service. > >> On Oct 13, 2018, at 14:39, Daniel Corbe wrote: >> >> I had a customer with a similar issue. I statically assigned them a different IP and it didn’t resolve it. The problem turned out to be tied to their Hulu account. >> >> The customer is going to need to keep pressing the issue with Hulu’s technical support group. Make sure they’re not using a VPN to connect to the Internet and have them keep calling Hulu back until they get someone clueful on the phone. >> >> In my customer’s case, they eventually had to “re-home” them to resolve it. I have no idea what that entails. >> >> -Daniel >> >> at 12:35 PM, Jason Canady wrote: >> >>> Hello, >>> >>> I have a customer that is using Hulu Live to stream ESPN, however it isn't showing up in their Channel list. They reached out to Hulu and it's because their IP address is 'commercial'. We have many customers using Hulu without problems, but it seems specific to ESPN. Anyone else have this issue? Do you reach out to ESPN or Hulu? >>> >>> If anyone has any information, please share it. Appreciate your help in advance! >>> >>> Best Regards, >>> >>> Jason Canady >>> Unlimited Net, LLC >>> Responsive, Reliable, Secure >> >> From mark.tinka at seacom.mu Mon Oct 15 06:17:01 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 15 Oct 2018 08:17:01 +0200 Subject: Fwd: [apops] APRICOT 2019 PC call for volunteers In-Reply-To: <13509111-9a18-966a-a461-292c6b67fe88@gmail.com> References: <13509111-9a18-966a-a461-292c6b67fe88@gmail.com> Message-ID: <5910a924-0cc1-2127-317c-d9a103ce48ce@seacom.mu> FYI. Mark. -------- Forwarded Message -------- Subject: [apops] APRICOT 2019 PC call for volunteers Date: Mon, 8 Oct 2018 20:26:42 +1000 From: Philip Smith To: apops at apops.net Hi everyone, The APRICOT 2019 Programme Committee is responsible for the solicitation and selection of suitable presentation and tutorial content for the APRICOT 2019 conference (https://2019.apricot.net/). The APRICOT PC Chairs are now seeking nominations from the community to join the APRICOT 2019 PC to assist with the development of the programme for APRICOT 2019. Eligible PC candidates are those who have attended APRICOT conferences in the recent past, have broad technical knowledge of Internet operations, and have reasonable familiarity with the format of APRICOT conferences. Having constructive opinions and ideas about how the programme content might be improved is of high value too. PC members are expected to work actively to solicit content and review submissions for technical merit. The PC meets by conference call, weekly in frequency during the three months prior to APRICOT. If you are interested in joining the PC and meet the above eligibility criteria, please send a brief note to "pc-chairs at apricot.net". The note should include affiliation (if any) and contact details (including e-mail address), and a brief description of why you would make a good addition to the PC. PC members who are active, successfully solicit content, contribute to regular PC meetings and submit reviews receive complimentary registration for APRICOT 2019. The PC Chairs will accept nominations received by 17:00 UTC+8 on Monday 22nd October, 2018, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka, Marijana Novakovic & Philip Smith APRICOT 2019 PC Chairs -- _______________________________________________ apops mailing list apops at apops.net https://mailman.apnic.net/mailman/listinfo/apops Website: www.apops.net . -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Oct 15 06:45:36 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 15 Oct 2018 08:45:36 +0200 Subject: Fwd: [apops] APRICOT 2019 Call for Presentations In-Reply-To: <4410edb7-97b3-286b-671a-51b605b0442f@gmail.com> References: <4410edb7-97b3-286b-671a-51b605b0442f@gmail.com> Message-ID: <3afaaffd-08da-e954-2a05-d0d6c00c6eac@seacom.mu> FYI - APRICOT 2019 Call for Presentations. Thanks. Mark. -------- Forwarded Message -------- Subject: [apops] APRICOT 2019 Call for Presentations Date: Fri, 12 Oct 2018 14:43:08 +1000 From: Philip Smith To: apops at apops.net Hi everyone, The call for presentations for APRICOT 2019 has been published - we are all looking forward to receiving your presentation and tutorial proposals and welcoming you to APRICOT 2019 in Daejeon, Korea, in February. Thanks! Mark, Marijana, Philip APRICOT 2019 PC Chairs -- Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 25th - 28th February 2019, Daejeon, Korea https://2019.apricot.net CALL FOR PAPERS =============== The APRICOT 2019 Programme Committee is now seeking contributions for Presentations and Tutorials for the APRICOT 2019 Conference. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics; - Lead informal Birds of Feather break out sessions. Please submit on-line at: http://papers.apricot.net/user/login.php?event=79 CONFERENCE MILESTONES --------------------- Call for Papers Opens: Now Draft Program Published: As Papers Confirmed Final Deadline for Submissions: 25 January 2019 Final Program Published: 1 February 2019 Final Slides Received: 15 February 2019 *NOTE THAT REGARDLESS OF DEADLINES, SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS* PROGRAMME CONTENT ----------------- The APRICOT Conference Programme consists of three parts, these being the Peering Forum, Tutorials, and Conference Tracks. Topics proposed must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and Operations - Internet backbone operations - Peering, Interconnects and IXPs - Content Distribution Network technology & operations - Research on Internet Operations and Deployment - Network security (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - IPv6 deployment on fixed and Wireless/Cellular networks - DNS / DNSSEC - Access and Transport Technologies, including Cable/DSL, LTE/5G, wireless, metro ethernet, fibre, segment routing - Software Defined Networking / Network Function Virtualisaton - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing CfP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the submission will be rejected immediately. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Slides must be of original work, with all company confidential marks removed. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC may, at their discretion, retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Every year we turn away submissions, due to filling up all available programme slots before the deadline. Presenters should endeavour to get material into the PC sooner rather than later. Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Marijana Novakovic & Philip Smith Co-Chairs, APRICOT 2019 Programme Committee -- _______________________________________________ apops mailing list apops at apops.net https://mailman.apnic.net/mailman/listinfo/apops Website: www.apops.net . -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon at rd.bbc.co.uk Mon Oct 15 08:02:28 2018 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 15 Oct 2018 09:02:28 +0100 Subject: Hulu / ESPN: Commercial IP Address In-Reply-To: References: Message-ID: <20181015080227.GA25884@sunf10.rd.bbc.co.uk> On Sat Oct 13, 2018 at 02:39:37PM -0400, Daniel Corbe wrote: > I had a customer with a similar issue. I statically assigned them a > different IP and it didn???t resolve it. The problem turned out to be > tied to their Hulu account. I had a similar issue with wifi calling on O2 in the UK. it worked on some wifi but not others. After pressing O2 support for quite some time they admitted "you're on commercial IP space which we don't support" but would say no more. After a little puzzling I realised the working wifis were NATed to 1918 so I added NAT to one that wasn't working and the phone registered OK for wifi calling. The address it was NATed to was the same range so it appears their test is for 1918 space on the client. I'm not saying HULU is the same, I've never has access to it, but companies cook up some wierd ideas of what is accepable for client access. I've still got no idea why having a public IP makes it unnaceptable to make phone calls where their coverage is poor. brandon From cdel at firsthand.net Mon Oct 15 08:10:08 2018 From: cdel at firsthand.net (Christian de Larrinaga) Date: Mon, 15 Oct 2018 09:10:08 +0100 Subject: Hulu / ESPN: Commercial IP Address In-Reply-To: <20181015080227.GA25884@sunf10.rd.bbc.co.uk> References: <20181015080227.GA25884@sunf10.rd.bbc.co.uk> Message-ID: <5BC44B60.1000408@firsthand.net> Brandon, That is odd. Might this be an artefact of cellular carriers being fixated on revenue protection of their inter carrier rates. Are they (wrongly) assuming a public IP might be a grey market termination risk onto their networks? best Christian Brandon Butterworth wrote: > > On Sat Oct 13, 2018 at 02:39:37PM -0400, Daniel Corbe wrote: >> >> I had a customer with a similar issue. I statically assigned them a >> different IP and it didn???t resolve it. The problem turned out to be >> tied to their Hulu account. > > > I had a similar issue with wifi calling on O2 in the UK. it > worked on some wifi but not others. After pressing O2 support > for quite some time they admitted "you're on commercial IP space > which we don't support" but would say no more. > > After a little puzzling I realised the working wifis were > NATed to 1918 so I added NAT to one that wasn't working and the > phone registered OK for wifi calling. The address it was NATed > to was the same range so it appears their test is for 1918 space > on the client. > > I'm not saying HULU is the same, I've never has access to it, > but companies cook up some wierd ideas of what is accepable for > client access. I've still got no idea why having a public IP makes > it unnaceptable to make phone calls where their coverage is poor. > > brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at gt86car.org.uk Mon Oct 15 08:18:59 2018 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 15 Oct 2018 09:18:59 +0100 Subject: Hulu / ESPN: Commercial IP Address In-Reply-To: <5BC44B60.1000408@firsthand.net> References: <20181015080227.GA25884@sunf10.rd.bbc.co.uk> <5BC44B60.1000408@firsthand.net> Message-ID: <5F8EA34E-AB8A-4DA6-8674-3B151AA1B06D@gt86car.org.uk> nhs public wifi seems weird for hulu and wifi calling, uses sophos i see so wondered if right rules enabled... col Sent from my iPod > On 15 Oct 2018, at 09:10, Christian de Larrinaga wrote: > > Brandon, That is odd. Might this be an artefact of cellular carriers being fixated on revenue protection of their inter carrier rates. Are they (wrongly) assuming a public IP might be a grey market termination risk onto their networks? > > best > > Christian > > Brandon Butterworth wrote: >> >>> On Sat Oct 13, 2018 at 02:39:37PM -0400, Daniel Corbe wrote: >>> >>> I had a customer with a similar issue. I statically assigned them a >>> different IP and it didn???t resolve it. The problem turned out to be >>> tied to their Hulu account. >> >> >> I had a similar issue with wifi calling on O2 in the UK. it >> worked on some wifi but not others. After pressing O2 support >> for quite some time they admitted "you're on commercial IP space >> which we don't support" but would say no more. >> >> After a little puzzling I realised the working wifis were >> NATed to 1918 so I added NAT to one that wasn't working and the >> phone registered OK for wifi calling. The address it was NATed >> to was the same range so it appears their test is for 1918 space >> on the client. >> >> I'm not saying HULU is the same, I've never has access to it, >> but companies cook up some wierd ideas of what is accepable for >> client access. I've still got no idea why having a public IP makes >> it unnaceptable to make phone calls where their coverage is poor. >> >> brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.dore at freethought-internet.co.uk Mon Oct 15 08:40:13 2018 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 15 Oct 2018 08:40:13 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <311684FC-A45C-4F99-B560-0F6BDDBC4CAE@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <20180926122109.GR77517@vurt.meerval.net> <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> <311684FC-A45C-4F99-B560-0F6BDDBC4CAE@arin.net> Message-ID: <519AC25E-1609-40EB-8F60-7A5D0CC91F60@freethought-internet.co.uk> From: NANOG on behalf of John Curran Date: Wednesday, 26 September 2018 at 16:51 To: Tony Finch Cc: David Wishnick , nanog list , "Ben at benjojo.co.uk" , Job Snijders Subject: Re: ARIN RPKI TAL deployment issues On 26 Sep 2018, at 11:02 AM, Tony Finch > wrote: John Curran > wrote: From "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ... • The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.” That's about certificates, not about trust anchors. It applies to APNIC members and account holders, not to relying parties. Tony - Interesting assertion… while APNIC does issue digital certificates to APNIC customers for identity authentication purposes, it also issues digital certificates for RPKI. It’s possible that the intent that the term “Digital Certificates” (capitalized) in the CA Terms and Conditions refers to only to those within APNIC’s identity CA, but the argument against that would be APNIC’s online information about "Digital Certificates" - === From ) What is a Digital Certificate? Digital Certificates bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. APNIC uses electronic certificates to prove its own identity, the identity of its Members, and the right-of-use over Internet resources. APNIC issues regular Public Key Infrastructure (PKI) certificates for access control to APNIC services such as the MyAPNIC Member services website. In the case of Resource Certification, APNIC issues Resource Public Key Infrastructure (RPKI) certificates that have ‘Certificate Extensions’ added. These Certificate Extensions carry the Internet number resources allocated or assigned to the APNIC Member who is the subject of the Resource Certificate. These Resource Certificates are different to the identity certificates used for Web system access, and may only be used in the context of verifying an entity’s “right-of-use” over an IP address or AS. As a result, APNIC now manages two independent certificate authorities, one for Member services, and the second for Resource Certification. … === Given that APNIC explicitly mentions the RPKI electronic certificates in their explanation of what Digital Certificates are (and further noting that ROA’s do indeed contain within them end-entity resource certificates with keys for verification), APNIC”s overall CA Terms and Conditions, including the referenced indemnification clause, would appear to be applicable to their RPKI CA services. If the intent was indeed to limit the scope, then then APNIC could have easily used the term “Identity Certificates” in the indemnification clause to make clear its limited scope; i.e. if you’re particularly concerned about liability from the resulting indemnification, it might be best to get this clarified one way or the other from APNIC. Thanks! /John John Curran President and CEO ARIN I asked APNIC about this and they confirmed that making use of their RPKI TAL does not bind you to their CA terms and conditions, so there’s no indemnity requirement. Edward Dore Freethought Internet -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Mon Oct 15 09:05:23 2018 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Mon, 15 Oct 2018 10:05:23 +0100 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: Message-ID: <000a01d46466$351aaf10$9f500d30$@netconsultings.com> Interesting, but isn’t stateful tracking once again just swapping, but in this case port 123 in port 32123 out? So none of the chips you named below support swapping parts of L4 header and that part is actually done with SW assistance please? So for example the following: https://eos.arista.com/7150s-nat-practical-guide-source-nat-dynamic/#2Dynamic_Source_NATOverload_Many_to_one - wouldn’t be at line-rate please? Thank you adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Paul Zugnoni Sent: Thursday, October 11, 2018 6:04 AM To: wmf at felter.org Cc: nanog at nanog.org Subject: Re: NAT on a Trident/Qumran(/or other?) equipped whitebox? The key to answering the question of NAT support on a Broadcom switch forwarding chip, is... another question: What /flavour of NAT/ you're looking for. Generally Trident (1,2,3), Tomahawk(1,2) and I believe Jericho all support varying degrees of swapping parts of an IP or Eth header for other parts - i.e. TTL of 249 in, TTL of 248 out, MPLS tag 500 in, MPLS tag 513 out. And, to your benefit, SRC IP of 10.1.1.1 in, SRC IP of 10.2.2.2 out. That can be handled at line rate (yes 10G); how many of those rules depends on the chip. So that's perfectly fine for static NAT. Problem with static NAT (i.e. 1:1) isn't what I suspect most of us are looking for. PAT, or "nat overload" - i.e. your internal 10.x or 192.168.x networks to the internet using one or a few public IPv4's - requires stateful tracking, which is not what any of those chips do. So you're dependent on what route engine and software is in use to supply stateful NAT / PAT, and the requirement being higher there generally means you'll need a firewall or router (which, btw, might actually be using one of the aforementioned Broadcom switch chips for the forwarding plane!). To achieve line rate for stateful NAT / PAT there's more than the switch chip and software in the equation, and can be the limiting factor to achieving "line rate" for a set of 10G ports. PZ On Wed, Oct 10, 2018 at 12:20 PM Wes Felter > wrote: On 10/9/18 10:35 AM, Jason Lixfeld wrote: > Has anyone played around with this? Curious if the BCM (or whatever other chip) can do this, and if not, if any of the box vendors have tried to find a way to get these things to do a bunch of NAT - say some flavour of NAT, line-rate @ 10G. If so, anyone know of a NOS that has support for it? OcNOS, Cumulus Linux, PicOS and Switch Light OS seem to have none, but not sure if there are others out there. For 10G I would use software NAT like a firewall or CGN virtual appliance. Switch ASICs generally don't support NAT well; Tofino and maybe Jericho II can probably do it but at high cost and as you discovered the market isn't trying very hard to provide "routing" or "firewalling" functionality on "switching" ASICs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Oct 15 13:25:42 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 15 Oct 2018 08:25:42 -0500 (CDT) Subject: Hurricane Michael: Communication Service Provider status In-Reply-To: References: Message-ID: <794140666.709.1539609940231.JavaMail.mhammett@ThunderFuck> " Note: although the FCC encourages independent ISPs to report outages, none have." Where to? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Friday, October 12, 2018 3:09:07 PM Subject: Re: Hurricane Michael: Communication Service Provider status Note: although the FCC encourages independent ISPs to report outages, none have. 13 fatalities reported as of 10/12/2018 Public Safety Answering Points (9-1-1) outages: 16 Public Safety Answering Points rerouted Curfews: Florida: Bay, Franklin, Gadsden, Gulf, Jackson, Liberty Electric grid outages: Alabama: 25,652 customers (1.01%) Florida: 351,433 customers (3.34%) Georgia: 304,862 customers (6.44%) North Carolina: 492,058 customers (9.94%) South Carolina: 7,422 customers (0.29%) Virginia 523,304 customers (13.92%) Florida Counties with more than 90% customers outage: Bradford (91%), Calhoun (100%), Franklin (97%), Gadsden (100%), Gulf (99%), Holmes (93%), Jackson (100%), Liberty (100%), Washington (100%) Airport status: All commercial airports have re-opened. Various temporary flight restrictions announced in NOTAMs. Sea port status: Panama City, FL closed Wilmington, NC closed Retail fuel stations (out of fuel, power or both): 6.3% of all Florida stations closed 41% of Florida panhandle stations closed 3.2% of Georgia stations closed 1.7% of Alabama stations closed NOAA Weather Radio transmitters out of service (hurricane area): Columbus, AL Talahassee, FL Sneads, FL Westville, FL East Point, FL Panama City, FL Pelham, GA Lafayette, LA New Bern, NC Henderson, NC Cellular Service (more than 50% out of service): Bay County, FL (72.8%) 238 sites out of service Gadsden County, FL (58.10%) 36 sites out of service Gulf County, FL (65.20%) 15 sites out of service Washington County, FL (56.40%) 22 sites out of service Cable systems and Wireline subscriber reported outages (likely more, since customers may not have reported problems yet, e.g. no outages reported in Virgina) Alabama: 18,244 Florida: 252,748 Georgia: 103,755 Broadcasters: 4 TV stations out of service 27 FM stations out of service 5 AM stations out of service -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Mon Oct 15 16:13:11 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 15 Oct 2018 18:13:11 +0200 Subject: ARIN TAL copyright Message-ID: <28f31c17-0a20-c9a0-c98d-ac5a1069d6dc@gmail.com> Hi, The URL to the ARIN TAL nor the ARIN TAL document itself is not copyrightable. The ARIN TAL document contains a URL and a key, which is a machine generated random number. Neither is based on any creative work whatsoever, and so can not be copyrighted. Also would be protected by free speech and fair use. The service itself can have terms and conditions, but access the the TAL document is not an effective enforcement. Bundlers of software can include this information at will. No need to download it. I understand the issue is that ARIN wants protection from being sued, should I somehow harm myself with this service. However ARIN already offers a similar service without any terms and conditions: The reverse DNS. As reverse DNS is often used by SMTP mail servers and mail clients to stop spam, I might not receive an important mail due to the failure of the ARIN reverse DNS service. And then sue ARIN for my financial loss. As a compromise, I suggest that ARIN outsource the service to somewhere with a less hostile legal environment. For example, maybe RIPE could mirror the ARIN service. The ARIN service may still require terms and conditions, while automatically installed software would use the RIPE mirror. Regards, Baldur From m4rtntns at gmail.com Mon Oct 15 19:06:42 2018 From: m4rtntns at gmail.com (Martin T) Date: Mon, 15 Oct 2018 22:06:42 +0300 Subject: some shallow statistics about finding the name/netname for IP address using RDAP and WHOIS Message-ID: Hi! For testing a script I generated 10000 random IPv4 and global unicast IPv6 addresses. For all those addresses I tried to find the netname/name attribute value from WHOIS servers using the latest version of https://github.com/rfc1036/whois and RDAP servers using the curl. Basically 'whois -H ' and 'curl -L "https://rdap.db.ripe.net/ip/"'. Out of those 10000 random IPv4 and IPv6 addresses, 7351 gave the same name/netname using RDAP and WHOIS. In case of 2285 addresses, the RDAP was able to find the name while WHOIS was not. Probably thanks to bootstrap feature. In case of 364 addresses, the WHOIS found a different netname than RDAP. Those cases can be seen here: http://termbin.com/p6u7 Left column is the RDAP and the right one is the WHOIS. If "IANA-BLK" WHOIS results for IPv6 are excluded, then only <1% of queries did not return a result using RDAP while they did return a result using WHOIS. In short, based on this small test, the RDAP is much more reliable than WHOIS for finding the name/netname for an IP address. Maybe those results are interesting or useful for somebody. PS. IPv4 and IPv6 addresses were generated like this: if (( $(($RANDOM % 2)) == 0 )); then # Generate random IPv4 address. printf -v ip '%d.%d.%d.%d' \ "$(($RANDOM % 256))" \ "$(($RANDOM % 256))" \ "$(($RANDOM % 256))" \ "$(($RANDOM % 256))" else # Gnerate random IPv6 global unicast address. hex_digit=( 0 1 2 3 4 5 6 7 8 9 a b c d e f ) ip= for i in {1..7}; do nibble= for i in {1..4}; do nibble="$nibble""${hex_digit[$(($RANDOM % 16))]}" done ip="$ip":"$nibble" done ip=2001"$ip" fi Martin From stu at spacehopper.org Mon Oct 15 14:19:02 2018 From: stu at spacehopper.org (Stuart Henderson) Date: Mon, 15 Oct 2018 14:19:02 +0000 (UTC) Subject: Hulu / ESPN: Commercial IP Address References: <20181015080227.GA25884@sunf10.rd.bbc.co.uk> Message-ID: On 2018-10-15, Brandon Butterworth wrote: > On Sat Oct 13, 2018 at 02:39:37PM -0400, Daniel Corbe wrote: >> I had a customer with a similar issue. I statically assigned them a >> different IP and it didn???t resolve it. The problem turned out to be >> tied to their Hulu account. > > I had a similar issue with wifi calling on O2 in the UK. it > worked on some wifi but not others. After pressing O2 support > for quite some time they admitted "you're on commercial IP space > which we don't support" but would say no more. > > After a little puzzling I realised the working wifis were > NATed to 1918 so I added NAT to one that wasn't working and the > phone registered OK for wifi calling. The address it was NATed > to was the same range so it appears their test is for 1918 space > on the client. Wifi calling (and femtocells and UMA) use IPsec. If NAT is detected (rewriting just the port number is probably enough) it will trigger using UDP encapsulation, without NAT perhaps they are trying to do ESP and they've blocked that somewhere. They usually have geolocation / ISP whitelists too, presumably to stop people trying to use it to get around roaming charges. (I've also seen a Vodafone femtocell do something funny with frequent NTP packets which makes me suspect they may do latency checks sometimes as well). From jcurran at istaff.org Tue Oct 16 01:40:11 2018 From: jcurran at istaff.org (John Curran) Date: Tue, 16 Oct 2018 03:40:11 +0200 Subject: ARIN TAL copyright In-Reply-To: <28f31c17-0a20-c9a0-c98d-ac5a1069d6dc@gmail.com> References: <28f31c17-0a20-c9a0-c98d-ac5a1069d6dc@gmail.com> Message-ID: <73929A18-036E-4CC0-9B63-753709AFAF72@istaff.org> On 15 Oct 2018, at 6:13 PM, Baldur Norddahl wrote: > > I understand the issue is that ARIN wants protection from being sued, should I somehow harm myself with this service. To be clear, ARIN would like to make sure that should any network operators impact their services through use of the ARIN RPKI repository [something that really shouldn’t really be possible given network operators following best practices e.g. RFC 7115] that when such operators are litigated by their customers (or those trying to reach their customers), the liability remains with the network operator. Obviously if ARIN is acting with malfeasance or is grossly negligent, then the liability should be with ARIN, but indemnification clauses are generally inapplicable in such circumstances. Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjoffe at centergate.com Tue Oct 16 02:00:33 2018 From: rjoffe at centergate.com (Rodney Joffe) Date: Mon, 15 Oct 2018 22:00:33 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. Message-ID: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> At NANOG two weeks ago, we had an interesting discussion at one of the lunch tables. One of the subjects we discussed was the original IANA, and RFC Editor, Jon Postel. Seven of the ten people at the table had never heard of him. Maybe these days it no longer matters who he was, and what he meant to where we are today. For those who care about the history of the Internet, and routing and addressing. And protocols… https://tools.ietf.org/html/rfc2468 Oct 16, 1998. From suzworldwide at gmail.com Tue Oct 16 02:11:25 2018 From: suzworldwide at gmail.com (Suzanne Woolf) Date: Mon, 15 Oct 2018 22:11:25 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> References: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> Message-ID: <21C4E4B2-CCA4-4235-952F-240F9471F8C5@gmail.com> > On Oct 15, 2018, at 10:00 PM, Rodney Joffe wrote: > > At NANOG two weeks ago, we had an interesting discussion at one of the lunch tables. One of the subjects we discussed was the original IANA, and RFC Editor, Jon Postel. > > Seven of the ten people at the table had never heard of him. Maybe these days it no longer matters who he was, and what he meant to where we are today. > > > > For those who care about the history of the Internet, and routing and addressing. And protocols… And the principles that make it “the Internet”, not just “some internets.” > > https://tools.ietf.org/html/rfc2468 > Suzanne From Brian at ampr.org Tue Oct 16 03:16:18 2018 From: Brian at ampr.org (Brian Kantor) Date: Mon, 15 Oct 2018 20:16:18 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> References: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> Message-ID: <20181016031618.GA4660@meow.BKantor.net> How soon we forget! It was a telephone call to Jon (there was no email) in 1981 that got my group the network that I still manage. He was the editor for the three RFCs that have my name on them. I remember him as a brilliant, kindly, efficient, helpful, and dedicated giant of the early Internet. - Brian On Mon, Oct 15, 2018 at 10:00:33PM -0400, Rodney Joffe wrote: > At NANOG two weeks ago, we had an interesting discussion at one of the lunch tables. One of the subjects we discussed was the original IANA, and RFC Editor, Jon Postel. > > Seven of the ten people at the table had never heard of him. Maybe these days it no longer matters who he was, and what he meant to where we are today. > > > > For those who care about the history of the Internet, and routing and addressing. And protocols… > > https://tools.ietf.org/html/rfc2468 > > Oct 16, 1998. From web at typo.org Tue Oct 16 03:32:58 2018 From: web at typo.org (Wayne Bouchard) Date: Mon, 15 Oct 2018 20:32:58 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> References: <17D100DB-556B-4752-9171-7827A2463D19@centergate.com> Message-ID: <20181016033258.GA86860@spider.typo.org> It is a fact that I learned much of what I initially knew about internetworking by reading the protocols outlined in many of the offical RFC documents. You couldn't pick one of these up without seeing the name Postel at the top. I never met him but give due deference and respect to his work and what it ultimately produced. On Mon, Oct 15, 2018 at 10:00:33PM -0400, Rodney Joffe wrote: > At NANOG two weeks ago, we had an interesting discussion at one of the lunch tables. One of the subjects we discussed was the original IANA, and RFC Editor, Jon Postel. > > Seven of the ten people at the table had never heard of him. Maybe these days it no longer matters who he was, and what he meant to where we are today. > > > > For those who care about the history of the Internet, and routing and addressing. And protocols??? > > https://tools.ietf.org/html/rfc2468 > > Oct 16, 1998. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From ryan.g at atwgpc.net Tue Oct 16 10:02:59 2018 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Tue, 16 Oct 2018 05:02:59 -0500 Subject: Whats going on at Cogent Message-ID: Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From j0hn.hurl3y at gmail.com Tue Oct 16 10:22:27 2018 From: j0hn.hurl3y at gmail.com (John Hurley) Date: Tue, 16 Oct 2018 06:22:27 -0400 Subject: Whats going on at Cogent In-Reply-To: References: Message-ID: I am glad I'm not the only one. I've noticed similar. Just when I get used to one rep it seems I have a new one. On Tue, Oct 16, 2018, 6:04 AM Ryan Gelobter wrote: > Anyone else seen terrible support and high turnover of sales/account > people at Cogent the last few months? Is there something going on over > there internally? I'm sure some people will say Cogent has always been crap > but in the past their account reps and support were pretty good. It seems > to have gone downhill the last 12 months really bad. > > Regards, > Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j0hn.hurl3y at gmail.com Tue Oct 16 10:24:23 2018 From: j0hn.hurl3y at gmail.com (John Hurley) Date: Tue, 16 Oct 2018 06:24:23 -0400 Subject: Whats going on at Cogent In-Reply-To: References: Message-ID: I think I noticed this actually start a bit longer than that. Around the time they started charging for BGP sessions and IP blocks on existing customers. So at least a year but I think closer to two years ago. On Tue, Oct 16, 2018, 6:22 AM John Hurley wrote: > I am glad I'm not the only one. I've noticed similar. Just when I get used > to one rep it seems I have a new one. > > On Tue, Oct 16, 2018, 6:04 AM Ryan Gelobter wrote: > >> Anyone else seen terrible support and high turnover of sales/account >> people at Cogent the last few months? Is there something going on over >> there internally? I'm sure some people will say Cogent has always been crap >> but in the past their account reps and support were pretty good. It seems >> to have gone downhill the last 12 months really bad. >> >> Regards, >> Ryan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Oct 16 12:07:21 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Oct 2018 14:07:21 +0200 Subject: SAFNOG-4/EANOG/tzNOG: Thank You & Survey Message-ID: Hello all. On behalf of the SAFNOG Management Committee, EANOG and tzNOG, I'd like to extend my sincere thanks to all of you that attended this year's meeting in Dar Es Salaam, physically and remotely. To our host (TISPA), our sponsors, our speakers and of course, you, our delegates, that supported this year's meeting... we would not have been able to do it without you. We look forward to seeing you again in 2019, details of which will be communicated in the coming months. I would like to ask you to take a few minutes and complete the 10-question survey at the link below, so that we know where to improve for future meetings:     https://www.surveymonkey.com/r/JQTKVVF Thank you all, and see you in 2019. Mark Tinka -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Tue Oct 16 12:14:55 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 16 Oct 2018 12:14:55 +0000 Subject: Whats going on at Cogent In-Reply-To: References: Message-ID: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. From: NANOG on behalf of Ryan Gelobter Date: Tuesday, October 16, 2018 at 6:04 AM To: NANOG Subject: Whats going on at Cogent Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Oct 16 13:04:04 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Oct 2018 08:04:04 -0500 (CDT) Subject: Whats going on at Cogent In-Reply-To: References: Message-ID: <2106783410.67.1539695037409.JavaMail.mhammett@ThunderFuck> That's *ALWAYS* been my experience with Cogent. *cue e-mail from Cogent rep* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ryan Gelobter" To: "NANOG" Sent: Tuesday, October 16, 2018 5:02:59 AM Subject: Whats going on at Cogent Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Tue Oct 16 13:29:17 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 16 Oct 2018 06:29:17 -0700 Subject: Whats going on at Cogent In-Reply-To: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> Message-ID: On Tue, Oct 16, 2018 at 5:16 AM David Hubbard wrote: > Have had the same sales rep for several years now; unfortunately he has no > ability to fix their IPv6 peering issue so we’re slowly removing circuits, > but otherwise for a handful of 10gig DIA circuits it’s been stable. > > > Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. *From: *NANOG on behalf of Ryan Gelobter < > ryan.g at atwgpc.net> > *Date: *Tuesday, October 16, 2018 at 6:04 AM > *To: *NANOG > *Subject: *Whats going on at Cogent > > > > Anyone else seen terrible support and high turnover of sales/account > people at Cogent the last few months? Is there something going on over > there internally? I'm sure some people will say Cogent has always been crap > but in the past their account reps and support were pretty good. It seems > to have gone downhill the last 12 months really bad. > > > > Regards, > > Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Tue Oct 16 13:54:17 2018 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 16 Oct 2018 09:54:17 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> Message-ID: They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: > > > On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> Have had the same sales rep for several years now; unfortunately he has >> no ability to fix their IPv6 peering issue so we’re slowly removing >> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >> stable. >> >> >> > > Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing > HE and Google ipv6 traffic, which is what they do if i use a default route > from them, is dead on arrival. Shows they make bad decisions and dont put > the customer first, or even create such an illusion. > > > *From: *NANOG on behalf of Ryan Gelobter < >> ryan.g at atwgpc.net> >> *Date: *Tuesday, October 16, 2018 at 6:04 AM >> *To: *NANOG >> *Subject: *Whats going on at Cogent >> >> >> >> Anyone else seen terrible support and high turnover of sales/account >> people at Cogent the last few months? Is there something going on over >> there internally? I'm sure some people will say Cogent has always been crap >> but in the past their account reps and support were pretty good. It seems >> to have gone downhill the last 12 months really bad. >> >> >> >> Regards, >> >> Ryan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daknob.mac at gmail.com Tue Oct 16 14:04:25 2018 From: daknob.mac at gmail.com (DaKnOb) Date: Tue, 16 Oct 2018 17:04:25 +0300 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> Message-ID: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. > On 16 Oct 2018, at 16:54, Dovid Bender wrote: > > They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... > > >> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >> >> >>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard wrote: >>> Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. >>> >> >> Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. >> >> >>> From: NANOG on behalf of Ryan Gelobter >>> Date: Tuesday, October 16, 2018 at 6:04 AM >>> To: NANOG >>> Subject: Whats going on at Cogent >>> >>> >>> >>> Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. >>> >>> >>> >>> Regards, >>> >>> Ryan >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Tue Oct 16 14:05:55 2018 From: jwbensley at gmail.com (James Bensley) Date: Tue, 16 Oct 2018 15:05:55 +0100 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: <000a01d46466$351aaf10$9f500d30$@netconsultings.com> References: <000a01d46466$351aaf10$9f500d30$@netconsultings.com> Message-ID: On Mon, 15 Oct 2018 at 10:07, wrote: > > Interesting, but isn’t stateful tracking once again just swapping, but in this case port 123 in port 32123 out? > > So none of the chips you named below support swapping parts of L4 header and that part is actually done with SW assistance please? > > So for example the following: > > https://eos.arista.com/7150s-nat-practical-guide-source-nat-dynamic/#2Dynamic_Source_NATOverload_Many_to_one > > - wouldn’t be at line-rate please? Hi Adam, NAT/PAT is an N:1 swapping (map) though so a state/translation table is required to correctly "swap" back the return traffic. MPLS for example is 1:1 mapping/action. NAT/PAT state tables tend to fill quickly so to aid with this we also have timers to time out the translations and free up space in the translation table, and also track e.g. TCP RST or TCP FIN to remove entries from the table, so it's not "just swapping". Cheers, James. From edugas at unknowndevice.ca Tue Oct 16 14:10:28 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 16 Oct 2018 10:10:28 -0400 Subject: Whats going on at Cogent In-Reply-To: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> I don't really get the Cogent/Google peering issues. I've been hearing this for years... How about fixing it already? Telling customer to get other transit providers to get to a given network is really bad. On a side note, HE is still HE but they're trying really hard to be a good netcitizen. They've finally pushed filtering for peers: http://routing.he.net. I wouldn't get transit from them, but in some markets, they're the only affordable IP transit providers. On Oct 16 2018, at 10:04 am, DaKnOb wrote: > > > When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. > > About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. > > On 16 Oct 2018, at 16:54, Dovid Bender wrote: > > They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... > > > > > > On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: > > > > > > > > > On Tue, Oct 16, 2018 at 5:16 AM David Hubbard wrote: > > > > Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. > > > > > > > > > > Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. > > > > > > > > > > > > > > > > > > From: NANOG on behalf of Ryan Gelobter > > > > Date: Tuesday, October 16, 2018 at 6:04 AM > > > > To: NANOG > > > > Subject: Whats going on at Cogent > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Ryan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Tue Oct 16 14:12:26 2018 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 16 Oct 2018 10:12:26 -0400 Subject: Whats going on at Cogent In-Reply-To: <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> Message-ID: We have been very happy with HE. It was a no brainer over cogent. They are smaller (so are we). When there are issues they are real fast to fix them, you also get the personal touch which you don't get with others. On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas wrote: > I don't really get the Cogent/Google peering issues. I've been hearing > this for years... How about fixing it already? Telling customer to get > other transit providers to get to a given network is really bad. > > On a side note, HE is still HE but they're trying really hard to be a good > netcitizen. They've finally pushed filtering for peers: > http://routing.he.net. I wouldn't get transit from them, but in some > markets, they're the only affordable IP transit providers. > > On Oct 16 2018, at 10:04 am, DaKnOb wrote: > > > > When I call and mention it I’m told that it’s HE’s fault (despite the > lovely cake), but when I also bring Google, then they tell me to get a > different provider just for this traffic, or meet them at an IX and send my > traffic from there. > > About the staff rotation I’ve seen it too, and I’ve also seen an increase > in salespeople calling, for example when an AS is registered etc. in > addition to the normal calls.. > > On 16 Oct 2018, at 16:54, Dovid Bender wrote: > > They call me every few months. the last time they emailed me I said I > wasn't interested because of the HE issue. I have yet to get another > email....... > > > On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: > > > > On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > Have had the same sales rep for several years now; unfortunately he has no > ability to fix their IPv6 peering issue so we’re slowly removing circuits, > but otherwise for a handful of 10gig DIA circuits it’s been stable. > > > > > Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing > HE and Google ipv6 traffic, which is what they do if i use a default route > from them, is dead on arrival. Shows they make bad decisions and dont put > the customer first, or even create such an illusion. > > > > > *From: *NANOG on behalf of Ryan Gelobter < > ryan.g at atwgpc.net> > *Date: *Tuesday, October 16, 2018 at 6:04 AM > *To: *NANOG > *Subject: *Whats going on at Cogent > > Anyone else seen terrible support and high turnover of sales/account > people at Cogent the last few months? Is there something going on over > there internally? I'm sure some people will say Cogent has always been crap > but in the past their account reps and support were pretty good. It seems > to have gone downhill the last 12 months really bad. > > Regards, > Ryan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From walt at wollny.org Tue Oct 16 14:20:26 2018 From: walt at wollny.org (Walt) Date: Tue, 16 Oct 2018 14:20:26 +0000 Subject: Whats going on at Cogent In-Reply-To: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: HE is happy to peer with Cogent and would love to solve this issue. Thanks Walt From: NANOG > on behalf of DaKnOb > Date: Tuesday, October 16, 2018 at 7:04 AM To: Dovid Bender > Cc: NANOG > Subject: Re: Whats going on at Cogent When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. On 16 Oct 2018, at 16:54, Dovid Bender > wrote: They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... On Tue, Oct 16, 2018 at 9:29 AM, Ca By > wrote: On Tue, Oct 16, 2018 at 5:16 AM David Hubbard > wrote: Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. From: NANOG > on behalf of Ryan Gelobter > Date: Tuesday, October 16, 2018 at 6:04 AM To: NANOG > Subject: Whats going on at Cogent Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Tue Oct 16 14:37:40 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 16 Oct 2018 10:37:40 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: I'm in the process of turning up a Cogent circuit in Cologix (Columbus) and hope to be finished in the next week or so. So far my experience has been great. The only thing I didn't like was the monthly sales call asking me to sign the contract, reminding me they are available. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Oct 16, 2018 at 10:20 AM, Walt wrote: > HE is happy to peer with Cogent and would love to solve this issue. > > Thanks > > Walt > > From: NANOG on behalf of DaKnOb < > daknob.mac at gmail.com> > Date: Tuesday, October 16, 2018 at 7:04 AM > To: Dovid Bender > Cc: NANOG > Subject: Re: Whats going on at Cogent > > When I call and mention it I’m told that it’s HE’s fault (despite the > lovely cake), but when I also bring Google, then they tell me to get a > different provider just for this traffic, or meet them at an IX and send my > traffic from there. > > About the staff rotation I’ve seen it too, and I’ve also seen an increase > in salespeople calling, for example when an AS is registered etc. in > addition to the normal calls.. > > On 16 Oct 2018, at 16:54, Dovid Bender wrote: > > They call me every few months. the last time they emailed me I said I > wasn't interested because of the HE issue. I have yet to get another > email....... > > > On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: > >> >> >> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >> dhubbard at dino.hostasaurus.com> wrote: >> >>> Have had the same sales rep for several years now; unfortunately he has >>> no ability to fix their IPv6 peering issue so we’re slowly removing >>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>> stable. >>> >>> >>> >> >> Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing >> HE and Google ipv6 traffic, which is what they do if i use a default route >> from them, is dead on arrival. Shows they make bad decisions and dont put >> the customer first, or even create such an illusion. >> >> >> *From: *NANOG on behalf of Ryan Gelobter < >>> ryan.g at atwgpc.net> >>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>> *To: *NANOG >>> *Subject: *Whats going on at Cogent >>> >>> >>> >>> Anyone else seen terrible support and high turnover of sales/account >>> people at Cogent the last few months? Is there something going on over >>> there internally? I'm sure some people will say Cogent has always been crap >>> but in the past their account reps and support were pretty good. It seems >>> to have gone downhill the last 12 months really bad. >>> >>> >>> >>> Regards, >>> >>> Ryan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Oct 16 14:55:14 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 16 Oct 2018 10:55:14 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: <48672757-CA54-4FEB-80A3-5FB1D88D6725@puck.nether.net> > On Oct 16, 2018, at 10:20 AM, Walt wrote: > > HE is happy to peer with Cogent and would love to solve this issue. > > Thanks > As someone who really depends upon full internet access I can’t purchase from either supplier due to this. This mirrors what Ca By said, need a place where there’s full reachability. I would factor that into your purchases/network design. You can design around this, but it also may be too much effort. - Jared From dhubbard at dino.hostasaurus.com Tue Oct 16 15:01:58 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 16 Oct 2018 15:01:58 +0000 Subject: Whats going on at Cogent In-Reply-To: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: Yeah google is the issue for us. We provide web services and a LOT of our customers have software that is making calls of various types to Google services, or even just email delivery to Google hosted email; if all but a Cogent transit link to a given data center were down, all of those customers’ sites would begin failing at some level because the servers generally try v6 if the application level wasn’t explicit. Cogent doesn’t seem to care since their CEO is in some pissing match with Google. They must be deriving enough revenue from last mile v4-only turn ups that they don’t really care about dual stack customers. That being said, can’t say I’ve been impressed with their MPLS / metroE offerings either. When doing the pricing/sizing routine on a project, I learned that they have an internal concept of src-dst flows on those types of circuits, and if they can’t see your labels, or otherwise hash the traffic, or it all truly is point to point, you may not get the full bandwidth, or may need to buy a capacity larger than what the flow will be. From: NANOG on behalf of DaKnOb Date: Tuesday, October 16, 2018 at 10:06 AM To: Dovid Bender Cc: NANOG Subject: Re: Whats going on at Cogent When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. On 16 Oct 2018, at 16:54, Dovid Bender > wrote: They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... On Tue, Oct 16, 2018 at 9:29 AM, Ca By > wrote: On Tue, Oct 16, 2018 at 5:16 AM David Hubbard > wrote: Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. From: NANOG > on behalf of Ryan Gelobter > Date: Tuesday, October 16, 2018 at 6:04 AM To: NANOG > Subject: Whats going on at Cogent Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daknob.mac at gmail.com Tue Oct 16 15:34:33 2018 From: daknob.mac at gmail.com (DaKnOb) Date: Tue, 16 Oct 2018 18:34:33 +0300 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: That’s also true.. If you have a 10G connection between two DCs, and they can’t hash the traffic, you can only use 1/4th or 1/5th of the connection. Basically it is 10G but only 2G per flow. If you get transit at both places and then use a tunnel, which is a different service and may not satisfy all requirements, then you can use the full 10G, even with one flow. Otherwise you need to split it into 5 or more flows. I guess people really don’t like Cogent judging by the fact that one unrelated email caused all this to happen again.. :-) > On 16 Oct 2018, at 18:01, David Hubbard wrote: > > Yeah google is the issue for us. We provide web services and a LOT of our customers have software that is making calls of various types to Google services, or even just email delivery to Google hosted email; if all but a Cogent transit link to a given data center were down, all of those customers’ sites would begin failing at some level because the servers generally try v6 if the application level wasn’t explicit. Cogent doesn’t seem to care since their CEO is in some pissing match with Google. They must be deriving enough revenue from last mile v4-only turn ups that they don’t really care about dual stack customers. > > That being said, can’t say I’ve been impressed with their MPLS / metroE offerings either. When doing the pricing/sizing routine on a project, I learned that they have an internal concept of src-dst flows on those types of circuits, and if they can’t see your labels, or otherwise hash the traffic, or it all truly is point to point, you may not get the full bandwidth, or may need to buy a capacity larger than what the flow will be. > > From: NANOG on behalf of DaKnOb > Date: Tuesday, October 16, 2018 at 10:06 AM > To: Dovid Bender > Cc: NANOG > Subject: Re: Whats going on at Cogent > > When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. > > About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. > > On 16 Oct 2018, at 16:54, Dovid Bender wrote: > > They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... > > > On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: > > > On Tue, Oct 16, 2018 at 5:16 AM David Hubbard wrote: > Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. > > > Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. > > > From: NANOG on behalf of Ryan Gelobter > Date: Tuesday, October 16, 2018 at 6:04 AM > To: NANOG > Subject: Whats going on at Cogent > > Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. > > Regards, > Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcorbe at hammerfiber.com Tue Oct 16 15:44:10 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 16 Oct 2018 11:44:10 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> Message-ID: <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> at 11:34 AM, DaKnOb wrote: > I guess people really don’t like Cogent judging by the fact that one > unrelated email caused all this to happen again.. :-) Cogent have more pain points on average but they’re still the best option for getting to other Cogent customers. It’s not really hard to design around their shortcomings. I’d rather have 30 small links and be well-connected than two large ones and be SOL because someone refuses to peer. I can’t speak to their MPLS service, because cogent’s the last company I’d ever trust with my backbone. From lists.nanog at monmotha.net Tue Oct 16 15:55:58 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 16 Oct 2018 11:55:58 -0400 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: <000a01d46466$351aaf10$9f500d30$@netconsultings.com> Message-ID: On 10/16/18 10:05 AM, James Bensley wrote: > NAT/PAT is an N:1 swapping (map) though so a state/translation table > is required to correctly "swap" back the return traffic. MPLS for > example is 1:1 mapping/action. NAT/PAT state tables tend to fill > quickly so to aid with this we also have timers to time out the > translations and free up space in the translation table, and also > track e.g. TCP RST or TCP FIN to remove entries from the table, so > it's not "just swapping". I do wonder, though, if these popular switching ASICs are flexible enough in terms of their header matching and manipulation capabilities to handle packet mangling and forwarding in hardware for a given NAT state entry while punting anything that requires a state change to a CPU for inspection and state update. You'd need a somewhat more powerful CPU than your typical L3 switch might have, but it seems like you'd still be able to offload the vast majority of the actual packet processing to hardware. State table size (on a typical "switching" ASIC) might be an issue before you could actually fill up a 10Gbps+ link with typical SP multi-user traffic flows, I guess, and given that a moderate-spec PC can keep up with 10Gbps without much issue these days, maybe it's a non-starter. -- Brandon Martin From joelja at bogus.com Tue Oct 16 16:23:37 2018 From: joelja at bogus.com (joel jaeggli) Date: Tue, 16 Oct 2018 09:23:37 -0700 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: <000a01d46466$351aaf10$9f500d30$@netconsultings.com> Message-ID: On 10/16/18 08:55, Brandon Martin wrote: > On 10/16/18 10:05 AM, James Bensley wrote: >> NAT/PAT is an N:1 swapping (map) though so a state/translation table >> is required to correctly "swap" back the return traffic. MPLS for >> example is 1:1 mapping/action. NAT/PAT state tables tend to fill >> quickly so to aid with this we also have timers to time out the >> translations and free up space in the translation table, and also >> track e.g. TCP RST or TCP FIN to remove entries from the table, so >> it's not "just swapping". > > I do wonder, though, if these popular switching ASICs are flexible > enough in terms of their header matching and manipulation capabilities > to handle packet mangling and forwarding in hardware for a given NAT > state entry while punting anything that requires a state change to a CPU > for inspection and state update. > > You'd need a somewhat more powerful CPU than your typical L3 switch > might have, but it seems like you'd still be able to offload the vast > majority of the actual packet processing to hardware. This is a flow cached router fundamentally. They exist. In that design you burn your fib on flow entries rather than on nexthop routes. They tend to explode at forwarding rates far lower than a typical ethernet switch when their ability to accumulate new state is exercised. riverstone RS circa 1999-2004 and various cisco products (sup 1a cat6k?) did follow that model. > State table size (on a typical "switching" ASIC) might be an issue > before you could actually fill up a 10Gbps+ link with typical SP > multi-user traffic flows, I guess, and given that a moderate-spec PC can > keep up with 10Gbps without much issue these days, maybe it's a > non-starter. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From nanog at ics-il.net Tue Oct 16 17:08:25 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Oct 2018 12:08:25 -0500 (CDT) Subject: Whats going on at Cogent In-Reply-To: <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> Message-ID: <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> Agreed. A couple IXes, Cogent, HE, and a couple others. Add more IXes and others as needed. Eyeballs should be fine with the above. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Daniel Corbe" To: "DaKnOb" Cc: "NANOG" Sent: Tuesday, October 16, 2018 10:44:10 AM Subject: Re: Whats going on at Cogent at 11:34 AM, DaKnOb wrote: > I guess people really don’t like Cogent judging by the fact that one > unrelated email caused all this to happen again.. :-) Cogent have more pain points on average but they’re still the best option for getting to other Cogent customers. It’s not really hard to design around their shortcomings. I’d rather have 30 small links and be well-connected than two large ones and be SOL because someone refuses to peer. I can’t speak to their MPLS service, because cogent’s the last company I’d ever trust with my backbone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Oct 16 17:11:21 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 16 Oct 2018 10:11:21 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. Message-ID: <20181016101121.469B8F56@m0117568.ppops.net> --- rjoffe at centergate.com wrote: From: Rodney Joffe At NANOG two weeks ago, we had an interesting discussion at one of the lunch tables. One of the subjects we discussed was the original IANA, and RFC Editor, Jon Postel. Seven of the ten people at the table had never heard of him. Maybe these days it no longer matters who he was, and what he meant to where we are today. ------------------------------------------------ Wow, was it a table of folks new to network engineering? If so, then schooling; if not, then clue bat... :-) scott From dcorbe at hammerfiber.com Tue Oct 16 18:01:48 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 16 Oct 2018 14:01:48 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <20181016101121.469B8F56@m0117568.ppops.net> References: <20181016101121.469B8F56@m0117568.ppops.net> Message-ID: at 1:11 PM, Scott Weeks wrote: > > Wow, was it a table of folks new to network engineering? > If so, then schooling; if not, then clue bat... :-) > > scott The one thing I remember about Postel, other than the fact that he had his fingers in a lot of DNS pies, is be liberal about what you accept, be conservative about what you send. It’s a notion that creates undo burden on the implementor, because it places the expectation on the that you need to account for every conceivable ambiguous corner case and that’s not always the best approach when implementing a standard; and it mostly arises from the lack of adherence to the second part of that statement. From Brian at ampr.org Tue Oct 16 18:10:31 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 16 Oct 2018 11:10:31 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: References: <20181016101121.469B8F56@m0117568.ppops.net> Message-ID: <20181016181030.GA8414@meow.BKantor.net> On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote: > The one thing I remember about Postel, other than the fact that he had his > fingers in a lot of DNS pies, is be liberal about what you accept, be > conservative about what you send. It’s a notion that creates undo burden > on the implementor, because it places the expectation on the that you need > to account for every conceivable ambiguous corner case and that’s not > always the best approach when implementing a standard; and it mostly arises > from the lack of adherence to the second part of that statement. I think that his aphorism is simply a recognition that NO standard can cover all cases that might arise when dealing with complex matters, no matter how much thought went into it. People are fallible, and the standards they write are inevitably flawed in some way, so a realistic implementor has to allow some slack or be continually engaged in finger-pointing when something doesn't work. - Brian From sean at donelan.com Tue Oct 16 21:08:54 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 16 Oct 2018 17:08:54 -0400 (EDT) Subject: Hurricane Michael: Communication Service Provider status In-Reply-To: References: Message-ID: 26 fatalities reported so far, 4 hospitals closed. Telecommunications: FCC Chairman Pai and Florida Governor Scott issued loud complaints about the speed of restoration of cell sites and telecommunications after Hurricane Michael. This seems to be an over-reaction to the lack of action after Puerto Rico last year. This issued several demands for actions that cellular providers almost always do after major disasters. So I expect them to claim victory when the carriers do the standard thing. 1. After disasters cell providers almost always implement "open roaming" allowing customers to use any working cell tower, even of different carriers. This was implemented in Puerto Rico for months. If cellular carriers in Florida haven't already done this, I expect they will. 2. Waive subscriber bills in the disaster area. Again, due to how open roaming works, most carriers will waive bills during the disaster. Mostly because billing doesn't work with open roaming, so make it a public relations benefit. 3. Deploy more disaster cell sites (COWs, COLTs, flying cell sites, etc.) AT&T put out a happy, happy, joy, joy press release saying "nearly fully restored in most affected areas." AT&T provide no details what that means, what affected areas, or what is not restored yet. https://about.att.com/pages/hurricane_michael Verizon put out more details about the impact on their network. https://www.verizon.com/about/news/hurricane-michael-network-updates Bay County, Florida still appears the most affected. Major fiber and roadway damage in the county. Verizon is using flying cell sites in Bay County, and deployed several satellite connected COWs/COLTs. Spectrum Cable (Charter, Time-Warner, etc. merged) Spectrum has some generic informatino that its service has been interrupted by damaged from Hurrican Michael. https://www.spectrum.net/page/weather-center/ Electric Power: Braford County: 56% out of service (65,859 customers) Calhoun County: 98% out of service (6,930 customers) Gasden County: 68% out of service (14,781 customers) Gulf County: 88% out of service (9,695 customers) Jackson County: 83% out of service (21,621 customers) Liberty County: 69% out of service (2,796 customers) From sean at donelan.com Tue Oct 16 22:10:40 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 16 Oct 2018 18:10:40 -0400 (EDT) Subject: Hurricane Michael: Communication Service Provider status In-Reply-To: References: Message-ID: Gosh, I can predict the future (by minutes). Verizon has issued a statement. It will automatically issue 3 months of mobile service credits for each consumer and business line in the affected areas (Bay and Gulf counties). I predict similar statements from the other major carriers shortly :-) https://www.verizon.com/about/news/statement-issued-ronan-dunne-hurricane-michael-network-recovery Oct 16, 2018 5:10pm Statement issued by Ronan Dunne, on Hurricane Michael network recovery Verizon is 100 percent focused on repairing our network in the Florida Panhandle. We are making progress every hour, and we expect that trend to continue at a rapid pace. We won’t rest until service is completely restored. Every Verizon customer in Bay and Gulf counties will be automatically credited for 3 months of mobile service for each line. This free service is for both consumer and business accounts. We will continue to regularly update our network recovery information at: https://www.verizon.com/about/news/hurricane-michael-network-updates/ As our recovery work continues, we have deployed portable cells to support the critical effort of first responders and other mission critical organizations, including: Bay County Emergency Operations Center and 911 Center Bay County Sheriff’s Office Blakely Emergency Operations Center City of Parker Police Department FDOT Chipley Office FEMA Office Gulf Coast Regional Medical Center Gulf County Emergency Operations Center Lynn Haven Emergency Operations Center Mexico Beach Miller County 911 Panama City Police Department Springfield Police Department TECO Peoples Gas, Panama City Tyndall Air Force Base Washington Emergency Operations Center in Chipley From aaron1 at gvtc.com Tue Oct 16 22:17:17 2018 From: aaron1 at gvtc.com (Aaron1) Date: Tue, 16 Oct 2018 17:17:17 -0500 Subject: Whats going on at Cogent In-Reply-To: <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> Message-ID: As an eyeball network operator, Cogent has served me well for several years, I can say that they are probably the easiest and most relaxed and most accessible to work with from my experience compared to my other providers, I’m comparing to 3 other well-known providers It seems like when I call Cogent the person that answers the phone is the person that solves my problem, other providers I have to go through multiple layers of people to get to someone who knows how to do what I need them to do Cogent has typically been the cheapest also However Cogent seems to be the dirtiest in regards to DDOS... however Telia might be catching up... in times past when I receive volumetric DDOS, Cogent typically ranks with the highest on my providers ... AT&T and spectrum seem to be a bit cleaner I also have the long-standing v6 google issue So yeah, pros and cons, but that’s true about most things, pros and cons Aaron > On Oct 16, 2018, at 12:08 PM, Mike Hammett wrote: > > Agreed. A couple IXes, Cogent, HE, and a couple others. Add more IXes and others as needed. Eyeballs should be fine with the above. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > From: "Daniel Corbe" > To: "DaKnOb" > Cc: "NANOG" > Sent: Tuesday, October 16, 2018 10:44:10 AM > Subject: Re: Whats going on at Cogent > > at 11:34 AM, DaKnOb wrote: > > > I guess people really don’t like Cogent judging by the fact that one > > unrelated email caused all this to happen again.. :-) > > Cogent have more pain points on average but they’re still the best option > for getting to other Cogent customers. It’s not really hard to design > around their shortcomings. I’d rather have 30 small links and be > well-connected than two large ones and be SOL because someone refuses to > peer. > > I can’t speak to their MPLS service, because cogent’s the last company I’d > ever trust with my backbone. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merculiani at gmail.com Tue Oct 16 22:20:47 2018 From: merculiani at gmail.com (Matt Erculiani) Date: Tue, 16 Oct 2018 17:20:47 -0500 Subject: Whats going on at Cogent In-Reply-To: <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> Message-ID: Speaking of Cogent service (and I know you guys are watching), I'd love to get someone's help off-list turning up a p2p that has been moved to billing despite being told loud and clear it doesn't work. I half-expected it to not work when I found out there was a type 2 provider involved, but I definitely did not expect to be billed for it... -Matt On Tue, Oct 16, 2018 at 12:09 PM Mike Hammett wrote: > > Agreed. A couple IXes, Cogent, HE, and a couple others. Add more IXes and others as needed. Eyeballs should be fine with the above. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ________________________________ > From: "Daniel Corbe" > To: "DaKnOb" > Cc: "NANOG" > Sent: Tuesday, October 16, 2018 10:44:10 AM > Subject: Re: Whats going on at Cogent > > at 11:34 AM, DaKnOb wrote: > > > I guess people really don’t like Cogent judging by the fact that one > > unrelated email caused all this to happen again.. :-) > > Cogent have more pain points on average but they’re still the best option > for getting to other Cogent customers. It’s not really hard to design > around their shortcomings. I’d rather have 30 small links and be > well-connected than two large ones and be SOL because someone refuses to > peer. > > I can’t speak to their MPLS service, because cogent’s the last company I’d > ever trust with my backbone. > > > > From paulzugnoni at gmail.com Tue Oct 16 22:22:39 2018 From: paulzugnoni at gmail.com (Paul Zugnoni) Date: Tue, 16 Oct 2018 15:22:39 -0700 Subject: NAT on a Trident/Qumran(/or other?) equipped whitebox? In-Reply-To: References: <000a01d46466$351aaf10$9f500d30$@netconsultings.com> Message-ID: The problem asking whether this can be done "at line rate" in a specific switch platform ignores these critical measurements: - what's the packet rate expected for the nat flows? - will the control plane add a forwarding plane rule for every new session? if so, how quickly can that rule be pushed to the ASIC? how many per second can be done? I think you'll quickly find that new session rate will be a more limiting factor to the thruput than the bandwidth of the involved ports. An architecture to support that would be far more expensive. Maybe this was the case on the platforms Joel noted, and I believe modern "hardware based" firewall like higher end SRX and some Fortinet. - If not with the architecture above, then every packet needs to be punted to the CPU. What's the bw between ASIC and CPU? Consider the CPU is doing the decision making based on flows; the control plane usually has only 1G to the ASIC, sometimes and probably increasingly common is 10G. For these reasons I doubt the 7150s in the original email can dynamically NAT at line rate PZ On Tue, Oct 16, 2018 at 9:25 AM joel jaeggli wrote: > On 10/16/18 08:55, Brandon Martin wrote: > > On 10/16/18 10:05 AM, James Bensley wrote: > >> NAT/PAT is an N:1 swapping (map) though so a state/translation table > >> is required to correctly "swap" back the return traffic. MPLS for > >> example is 1:1 mapping/action. NAT/PAT state tables tend to fill > >> quickly so to aid with this we also have timers to time out the > >> translations and free up space in the translation table, and also > >> track e.g. TCP RST or TCP FIN to remove entries from the table, so > >> it's not "just swapping". > > > > I do wonder, though, if these popular switching ASICs are flexible > > enough in terms of their header matching and manipulation capabilities > > to handle packet mangling and forwarding in hardware for a given NAT > > state entry while punting anything that requires a state change to a CPU > > for inspection and state update. > > > > You'd need a somewhat more powerful CPU than your typical L3 switch > > might have, but it seems like you'd still be able to offload the vast > > majority of the actual packet processing to hardware. > > This is a flow cached router fundamentally. They exist. In that design > you burn your fib on flow entries rather than on nexthop routes. They > tend to explode at forwarding rates far lower than a typical ethernet > switch when their ability to accumulate new state is exercised. > riverstone RS circa 1999-2004 and various cisco products (sup 1a cat6k?) > did follow that model. > > > State table size (on a typical "switching" ASIC) might be an issue > > before you could actually fill up a 10Gbps+ link with typical SP > > multi-user traffic flows, I guess, and given that a moderate-spec PC can > > keep up with 10Gbps without much issue these days, maybe it's a > > non-starter. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Tue Oct 16 23:23:13 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 16 Oct 2018 16:23:13 -0700 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> Message-ID: <38CE723B-8055-4CCA-B18D-57A4F9B9375F@6by7.net> Oh how funny I’m working on a billing issue with them for a circuit they turned up but didn’t connect to the MMR for 2 months... -Ben > On Oct 16, 2018, at 3:20 PM, Matt Erculiani wrote: > > Speaking of Cogent service (and I know you guys are watching), I'd love > to get someone's help off-list turning up a p2p that has been moved to > billing despite being told loud and clear it doesn't work. I > half-expected it to not work when I found out there was a type 2 > provider involved, but I definitely did not expect to be billed for > it... > > -Matt >> On Tue, Oct 16, 2018 at 12:09 PM Mike Hammett wrote: >> >> Agreed. A couple IXes, Cogent, HE, and a couple others. Add more IXes and others as needed. Eyeballs should be fine with the above. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ________________________________ >> From: "Daniel Corbe" >> To: "DaKnOb" >> Cc: "NANOG" >> Sent: Tuesday, October 16, 2018 10:44:10 AM >> Subject: Re: Whats going on at Cogent >> >> at 11:34 AM, DaKnOb wrote: >> >>> I guess people really don’t like Cogent judging by the fact that one >>> unrelated email caused all this to happen again.. :-) >> >> Cogent have more pain points on average but they’re still the best option >> for getting to other Cogent customers. It’s not really hard to design >> around their shortcomings. I’d rather have 30 small links and be >> well-connected than two large ones and be SOL because someone refuses to >> peer. >> >> I can’t speak to their MPLS service, because cogent’s the last company I’d >> ever trust with my backbone. >> >> >> >> From matt at spectrum.com.au Tue Oct 16 23:51:16 2018 From: matt at spectrum.com.au (Matt Perkins) Date: Wed, 17 Oct 2018 10:51:16 +1100 Subject: Whats going on at Cogent In-Reply-To: <38CE723B-8055-4CCA-B18D-57A4F9B9375F@6by7.net> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <38CE723B-8055-4CCA-B18D-57A4F9B9375F@6by7.net> Message-ID: Oh that's disturbing . We just signed up a few months ago for a circuit at an MMR and are still waiting for delivery. Matt. On 17/10/18 10:23 am, Ben Cannon wrote: > Oh how funny I’m working on a billing issue with them for a circuit they turned up but didn’t connect to the MMR for 2 months... > > > -Ben > >> On Oct 16, 2018, at 3:20 PM, Matt Erculiani wrote: >> >> Speaking of Cogent service (and I know you guys are watching), I'd love >> to get someone's help off-list turning up a p2p that has been moved to >> billing despite being told loud and clear it doesn't work. I >> half-expected it to not work when I found out there was a type 2 >> provider involved, but I definitely did not expect to be billed for >> it... >> >> -Matt >>> On Tue, Oct 16, 2018 at 12:09 PM Mike Hammett wrote: >>> >>> Agreed. A couple IXes, Cogent, HE, and a couple others. Add more IXes and others as needed. Eyeballs should be fine with the above. >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ________________________________ >>> From: "Daniel Corbe" >>> To: "DaKnOb" >>> Cc: "NANOG" >>> Sent: Tuesday, October 16, 2018 10:44:10 AM >>> Subject: Re: Whats going on at Cogent >>> >>> at 11:34 AM, DaKnOb wrote: >>> >>>> I guess people really don’t like Cogent judging by the fact that one >>>> unrelated email caused all this to happen again.. :-) >>> Cogent have more pain points on average but they’re still the best option >>> for getting to other Cogent customers. It’s not really hard to design >>> around their shortcomings. I’d rather have 30 small links and be >>> well-connected than two large ones and be SOL because someone refuses to >>> peer. >>> >>> I can’t speak to their MPLS service, because cogent’s the last company I’d >>> ever trust with my backbone. >>> >>> >>> >>> -- /* Matt Perkins Direct 1300 137 379 Spectrum Networks Ptd. Ltd. Office 1300 133 299 matt at spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance & TIO */ From web at typo.org Tue Oct 16 23:57:31 2018 From: web at typo.org (Wayne Bouchard) Date: Tue, 16 Oct 2018 16:57:31 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <20181016181030.GA8414@meow.BKantor.net> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> Message-ID: <20181016235731.GA91203@spider.typo.org> Well, simply put, the idea is that you should be able to compensate for a certain amount of deviation from accepted usage as long as its still within what the protocol allows (or can be read to allow) but that you yourself should act with a fairly strict interpretation. In others, don't be the one *causing* the problems... On Tue, Oct 16, 2018 at 11:10:31AM -0700, Brian Kantor wrote: > On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote: > > The one thing I remember about Postel, other than the fact that he had his > > fingers in a lot of DNS pies, is be liberal about what you accept, be > > conservative about what you send. It???s a notion that creates undo burden > > on the implementor, because it places the expectation on the that you need > > to account for every conceivable ambiguous corner case and that???s not > > always the best approach when implementing a standard; and it mostly arises > > from the lack of adherence to the second part of that statement. > > I think that his aphorism is simply a recognition that NO standard > can cover all cases that might arise when dealing with complex > matters, no matter how much thought went into it. People are > fallible, and the standards they write are inevitably flawed in > some way, so a realistic implementor has to allow some slack or be > continually engaged in finger-pointing when something doesn't work. > - Brian --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From ben at 6by7.net Wed Oct 17 00:02:22 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 16 Oct 2018 17:02:22 -0700 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <38CE723B-8055-4CCA-B18D-57A4F9B9375F@6by7.net> Message-ID: <648302E5-3F66-43CB-ADF4-6C2276AF66A1@6by7.net> But their support daily. They blamed the DC, our suite, the MMR, all in that order. Don’t let them, it was Mia-parched at their core router... -Ben > On Oct 16, 2018, at 4:51 PM, Matt Perkins wrote: > > Oh that's disturbing . We just signed up a few months ago for a circuit at an MMR and are still waiting for delivery. > > Matt. > > >> On 17/10/18 10:23 am, Ben Cannon wrote: >> Oh how funny I’m working on a billing issue with them for a circuit they turned up but didn’t connect to the MMR for 2 months... >> >> >> -Ben >> >>> On Oct 16, 2018, at 3:20 PM, Matt Erculiani wrote: >>> >>> Speaking of Cogent service (and I know you guys are watching), I'd love >>> to get someone's help off-list turning up a p2p that has been moved to >>> billing despite being told loud and clear it doesn't work. I >>> half-expected it to not work when I found out there was a type 2 >>> provider involved, but I definitely did not expect to be billed for >>> it... >>> >>> -Matt >>>> On Tue, Oct 16, 2018 at 12:09 PM Mike Hammett wrote: >>>> >>>> Agreed. A couple IXes, Cogent, HE, and a couple others. Add more IXes and others as needed. Eyeballs should be fine with the above. >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> Midwest-IX >>>> http://www.midwest-ix.com >>>> >>>> ________________________________ >>>> From: "Daniel Corbe" >>>> To: "DaKnOb" >>>> Cc: "NANOG" >>>> Sent: Tuesday, October 16, 2018 10:44:10 AM >>>> Subject: Re: Whats going on at Cogent >>>> >>>> at 11:34 AM, DaKnOb wrote: >>>> >>>>> I guess people really don’t like Cogent judging by the fact that one >>>>> unrelated email caused all this to happen again.. :-) >>>> Cogent have more pain points on average but they’re still the best option >>>> for getting to other Cogent customers. It’s not really hard to design >>>> around their shortcomings. I’d rather have 30 small links and be >>>> well-connected than two large ones and be SOL because someone refuses to >>>> peer. >>>> >>>> I can’t speak to their MPLS service, because cogent’s the last company I’d >>>> ever trust with my backbone. >>>> >>>> >>>> >>>> > > -- > /* Matt Perkins > Direct 1300 137 379 Spectrum Networks Ptd. Ltd. > Office 1300 133 299 matt at spectrum.com.au > Level 6, 350 George Street Sydney 2000 > Spectrum Networks is a member of the Communications Alliance & TIO > */ > From fredbaker.ietf at gmail.com Wed Oct 17 00:08:25 2018 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Tue, 16 Oct 2018 17:08:25 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <20181016235731.GA91203@spider.typo.org> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <20181016235731.GA91203@spider.typo.org> Message-ID: On Oct 16, 2018, at 4:57 PM, Wayne Bouchard wrote: > Well, simply put, the idea is that you should be able to compensate > for a certain amount of deviation from accepted usage as long as its > still within what the protocol allows (or can be read to allow) but > that you yourself should act with a fairly strict interpretation. In > others, don't be the one *causing* the problems... Indeed. To give a TCP example, the opening exchange is theoretically SYN, SYN ACK, ACK. A common case is that it is SYN, SYN ACK, data, either because the ACK got lost, or because someone cut a corner. The issue is to note that the SYN might have been duplicated in flight, and the receiver might therefore have the appearance of two sessions. Which one? The ACK (or data segment) - any segment within the sessions - clarifies that. So, if there is a minor protocol violation but the intent it clear, follow the intent. The alternative version of the Robustness Principle: "S**t happens; deal with it." Says someone who has implemented such things... -------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From niels=nanog at bakker.net Wed Oct 17 01:20:25 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 17 Oct 2018 03:20:25 +0200 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> Message-ID: <20181017012025.GB7993@jima.tpb.net> * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: >However Cogent seems to be the dirtiest in regards to DDOS... >however Telia might be catching up... in times past when I receive >volumetric DDOS, Cogent typically ranks with the highest on my >providers ... AT&T and spectrum seem to be a bit cleaner So you're saying, Cogent and Telia have the best backbones and interconnects and thus deliver the most of your traffic to you, even at times of peak utilization? -- Niels. From michael at wi-fiber.io Wed Oct 17 01:36:46 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 16 Oct 2018 19:36:46 -0600 Subject: Whats going on at Cogent In-Reply-To: <20181017012025.GB7993@jima.tpb.net> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> Message-ID: Or he's saying that cogent has the biggest network of compromised users. Usually ipv4 only eyeball networks tend to have the most bots on net. On Tue, 16 Oct 2018 at 19:22, Niels Bakker wrote: > * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: > >However Cogent seems to be the dirtiest in regards to DDOS... > >however Telia might be catching up... in times past when I receive > >volumetric DDOS, Cogent typically ranks with the highest on my > >providers ... AT&T and spectrum seem to be a bit cleaner > > So you're saying, Cogent and Telia have the best backbones and > interconnects and thus deliver the most of your traffic to you, > even at times of peak utilization? > > > -- Niels. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.mcrae at me.com Wed Oct 17 01:39:51 2018 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Tue, 16 Oct 2018 18:39:51 -0700 Subject: Youtube Outage Message-ID: Is this widespread? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ross at tajvar.io Wed Oct 17 01:42:35 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 16 Oct 2018 21:42:35 -0400 Subject: Youtube Outage In-Reply-To: References: Message-ID: You beat my email by seconds. Yes, it is widespread. On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: > Is this widespread? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Wed Oct 17 01:44:48 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 16 Oct 2018 19:44:48 -0600 Subject: Youtube Outage In-Reply-To: References: Message-ID: Tmobile, and syringa no youtube On Tue, 16 Oct 2018 at 19:42, Kenneth McRae via NANOG wrote: > Is this widespread? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Wed Oct 17 01:45:10 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Tue, 16 Oct 2018 18:45:10 -0700 Subject: Youtube Outage In-Reply-To: References: Message-ID: <3CB6A6DC-3B06-4FC6-88AA-B91CDCC75BFA@thenetworknerds.ca> Same issue for me in Vancouver. My direct peering in Germany has the same issue. Thanks ~ Bryce Wilson, AS202313 > On Oct 16, 2018, at 6:42 PM, Ross Tajvar wrote: > > You beat my email by seconds. Yes, it is widespread. > >> On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: >> Is this widespread? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marshall.eubanks at gmail.com Wed Oct 17 01:46:58 2018 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Tue, 16 Oct 2018 21:46:58 -0400 Subject: Youtube Outage In-Reply-To: References: Message-ID: Reports (and humor) are flooding twitter. On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: > > You beat my email by seconds. Yes, it is widespread. > > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: >> >> Is this widespread? > > From oliver.oboyle at gmail.com Wed Oct 17 02:07:43 2018 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Tue, 16 Oct 2018 22:07:43 -0400 Subject: Youtube Outage In-Reply-To: References: Message-ID: Same in Montreal. On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks wrote: > Reports (and humor) are flooding twitter. > On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: > > > > You beat my email by seconds. Yes, it is widespread. > > > > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG < > nanog at nanog.org> wrote: > >> > >> Is this widespread? > > > > > -- :o@> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nathan.Brookfield at simtronic.com.au Wed Oct 17 02:12:39 2018 From: Nathan.Brookfield at simtronic.com.au (Nathan Brookfield) Date: Wed, 17 Oct 2018 02:12:39 +0000 Subject: Youtube Outage In-Reply-To: References: Message-ID: Australia too…. From: NANOG On Behalf Of Oliver O'Boyle Sent: Wednesday, October 17, 2018 1:08 PM To: marshall.eubanks at gmail.com Cc: North American Network Operators' Group Subject: Re: Youtube Outage Same in Montreal. On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks > wrote: Reports (and humor) are flooding twitter. On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar > wrote: > > You beat my email by seconds. Yes, it is widespread. > > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG > wrote: >> >> Is this widespread? > > -- :o@> -------------- next part -------------- An HTML attachment was scrubbed... URL: From w3yni1 at gmail.com Wed Oct 17 02:15:34 2018 From: w3yni1 at gmail.com (Charles Mills) Date: Tue, 16 Oct 2018 22:15:34 -0400 Subject: Youtube Outage In-Reply-To: References: Message-ID: The reports I've seen showing it as a worldwide outage. On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield < Nathan.Brookfield at simtronic.com.au> wrote: > Australia too…. > > > > *From:* NANOG *On Behalf Of *Oliver O'Boyle > *Sent:* Wednesday, October 17, 2018 1:08 PM > *To:* marshall.eubanks at gmail.com > *Cc:* North American Network Operators' Group > *Subject:* Re: Youtube Outage > > > > Same in Montreal. > > > > On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks < > marshall.eubanks at gmail.com> wrote: > > Reports (and humor) are flooding twitter. > On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: > > > > You beat my email by seconds. Yes, it is widespread. > > > > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG < > nanog at nanog.org> wrote: > >> > >> Is this widespread? > > > > > > > > > -- > > :o@> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.w.kuehl at gmail.com Wed Oct 17 02:18:50 2018 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Tue, 16 Oct 2018 22:18:50 -0400 Subject: Youtube Outage In-Reply-To: References: Message-ID: Nothing on the homepage but search is working. (boston) On Tue, Oct 16, 2018 at 10:17 PM Charles Mills wrote: > The reports I've seen showing it as a worldwide outage. > > On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield < > Nathan.Brookfield at simtronic.com.au> wrote: > >> Australia too…. >> >> >> >> *From:* NANOG *On Behalf Of *Oliver O'Boyle >> *Sent:* Wednesday, October 17, 2018 1:08 PM >> *To:* marshall.eubanks at gmail.com >> *Cc:* North American Network Operators' Group >> *Subject:* Re: Youtube Outage >> >> >> >> Same in Montreal. >> >> >> >> On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks < >> marshall.eubanks at gmail.com> wrote: >> >> Reports (and humor) are flooding twitter. >> On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: >> > >> > You beat my email by seconds. Yes, it is widespread. >> > >> > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG < >> nanog at nanog.org> wrote: >> >> >> >> Is this widespread? >> > >> > >> >> >> >> >> -- >> >> :o@> >> >> >> > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Wed Oct 17 02:22:01 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 16 Oct 2018 21:22:01 -0500 Subject: Youtube Outage In-Reply-To: References: Message-ID: <008d01d465c0$302e3d90$908ab8b0$@gvtc.com> Oh yeah, hitting me hard in South Central Texas... no youtube videos at all for my customers. -Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ross Tajvar Sent: Tuesday, October 16, 2018 8:43 PM To: Kenneth McRae Cc: NANOG Subject: Re: Youtube Outage You beat my email by seconds. Yes, it is widespread. On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: Is this widespread? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Oct 17 02:22:46 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 16 Oct 2018 22:22:46 -0400 Subject: Youtube Outage In-Reply-To: References: Message-ID: I think it's clear they're having problems worldwide - could we maybe refrain from the "me too"s unless someone has insight on what the problem is? On Tue, Oct 16, 2018, 10:21 PM Jason Kuehl wrote: > Nothing on the homepage but search is working. (boston) > > On Tue, Oct 16, 2018 at 10:17 PM Charles Mills wrote: > >> The reports I've seen showing it as a worldwide outage. >> >> On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield < >> Nathan.Brookfield at simtronic.com.au> wrote: >> >>> Australia too…. >>> >>> >>> >>> *From:* NANOG *On Behalf Of *Oliver O'Boyle >>> *Sent:* Wednesday, October 17, 2018 1:08 PM >>> *To:* marshall.eubanks at gmail.com >>> *Cc:* North American Network Operators' Group >>> *Subject:* Re: Youtube Outage >>> >>> >>> >>> Same in Montreal. >>> >>> >>> >>> On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks < >>> marshall.eubanks at gmail.com> wrote: >>> >>> Reports (and humor) are flooding twitter. >>> On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: >>> > >>> > You beat my email by seconds. Yes, it is widespread. >>> > >>> > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG < >>> nanog at nanog.org> wrote: >>> >> >>> >> Is this widespread? >>> > >>> > >>> >>> >>> >>> >>> -- >>> >>> :o@> >>> >>> >>> >> > > -- > Sincerely, > > Jason W Kuehl > Cell 920-419-8983 > jason.w.kuehl at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.DeLaCruz at CenturyLink.com Wed Oct 17 02:24:28 2018 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Wed, 17 Oct 2018 02:24:28 +0000 Subject: Youtube Outage In-Reply-To: References: Message-ID: <398B250423578A4E97AFE1B8B67C686C651723C9@PDDCWMBXEX503.ctl.intranet> Well at least the BGP looks good this time and it's not being sent to Pakistan. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kenneth McRae via NANOG Sent: Tuesday, October 16, 2018 8:40 PM To: NANOG Subject: Youtube Outage Is this widespread? This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From bzs at theworld.com Wed Oct 17 02:18:30 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 16 Oct 2018 22:18:30 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <20181016181030.GA8414@meow.BKantor.net> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> Message-ID: <23494.39926.405612.48460@gargle.gargle.HOWL> What it's trying to say is that you have control over your own code but not others', in general. So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you. I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it. And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect. For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood. -- -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 ben at 6by7.net Wed Oct 17 02:33:44 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 16 Oct 2018 19:33:44 -0700 Subject: Youtube Outage In-Reply-To: References: Message-ID: Confirmed outage in Windsor CA -Ben > On Oct 16, 2018, at 7:15 PM, Charles Mills wrote: > > The reports I've seen showing it as a worldwide outage. > >> On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield wrote: >> Australia too…. >> >> >> >> From: NANOG On Behalf Of Oliver O'Boyle >> Sent: Wednesday, October 17, 2018 1:08 PM >> To: marshall.eubanks at gmail.com >> Cc: North American Network Operators' Group >> Subject: Re: Youtube Outage >> >> >> >> Same in Montreal. >> >> >> >> On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks wrote: >> >> Reports (and humor) are flooding twitter. >> On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: >> > >> > You beat my email by seconds. Yes, it is widespread. >> > >> > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: >> >> >> >> Is this widespread? >> > >> > >> >> >> >> >> >> -- >> >> :o@> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Wed Oct 17 02:35:24 2018 From: mike at mtcc.com (Michael Thomas) Date: Tue, 16 Oct 2018 19:35:24 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <23494.39926.405612.48460@gargle.gargle.HOWL> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others. Mike On 10/16/2018 07:18 PM, bzs at theworld.com wrote: > What it's trying to say is that you have control over your own code > but not others', in general. > > So make your own code (etc) robust and forgiving since you can't edit > others' code to conform to your own understanding of what they should > be sending you. > > I suppose that pre-dates github but nonetheless much of the code which > generates bits flung at you is proprietary and otherwise out of your > control but what you can control is your code's reaction to it. > > And of course the bits you generate which should try to make > conservative assumptions about what they might accept and interpret as > you expect. > > For example just because they sent you a seemingly malformed HTTP > request, and given that 4xx is for error codes, doesn't mean you > should return "420 You must be high!" and expect to be understood. > From sakamura at gmail.com Wed Oct 17 02:40:08 2018 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 16 Oct 2018 21:40:08 -0500 Subject: Youtube Outage In-Reply-To: References: Message-ID: Should be coming back online On Tue, Oct 16, 2018 at 9:35 PM Ben Cannon wrote: > Confirmed outage in Windsor CA > > -Ben > > On Oct 16, 2018, at 7:15 PM, Charles Mills wrote: > > The reports I've seen showing it as a worldwide outage. > > On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield < > Nathan.Brookfield at simtronic.com.au> wrote: > >> Australia too…. >> >> >> >> *From:* NANOG *On Behalf Of *Oliver O'Boyle >> *Sent:* Wednesday, October 17, 2018 1:08 PM >> *To:* marshall.eubanks at gmail.com >> *Cc:* North American Network Operators' Group >> *Subject:* Re: Youtube Outage >> >> >> >> Same in Montreal. >> >> >> >> On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks < >> marshall.eubanks at gmail.com> wrote: >> >> Reports (and humor) are flooding twitter. >> On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: >> > >> > You beat my email by seconds. Yes, it is widespread. >> > >> > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG < >> nanog at nanog.org> wrote: >> >> >> >> Is this widespread? >> > >> > >> >> >> >> >> -- >> >> :o@> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryce at thenetworknerds.ca Wed Oct 17 02:41:54 2018 From: bryce at thenetworknerds.ca (Bryce Wilson) Date: Tue, 16 Oct 2018 19:41:54 -0700 Subject: Youtube Outage In-Reply-To: References: Message-ID: <9FAD13EB-6B72-4B2C-B386-A316976DE360@thenetworknerds.ca> I concur, all of my systems have it as back up. Thanks ~ Bryce Wilson, AS202313 > On Oct 16, 2018, at 7:40 PM, Ishmael Rufus wrote: > > Should be coming back online > >> On Tue, Oct 16, 2018 at 9:35 PM Ben Cannon wrote: >> Confirmed outage in Windsor CA >> >> -Ben >> >>> On Oct 16, 2018, at 7:15 PM, Charles Mills wrote: >>> >>> The reports I've seen showing it as a worldwide outage. >>> >>>> On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield wrote: >>>> Australia too…. >>>> >>>> >>>> >>>> From: NANOG On Behalf Of Oliver O'Boyle >>>> Sent: Wednesday, October 17, 2018 1:08 PM >>>> To: marshall.eubanks at gmail.com >>>> Cc: North American Network Operators' Group >>>> Subject: Re: Youtube Outage >>>> >>>> >>>> >>>> Same in Montreal. >>>> >>>> >>>> >>>> On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks wrote: >>>> >>>> Reports (and humor) are flooding twitter. >>>> On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: >>>> > >>>> > You beat my email by seconds. Yes, it is widespread. >>>> > >>>> > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: >>>> >> >>>> >> Is this widespread? >>>> > >>>> > >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> :o@> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Wed Oct 17 02:45:36 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 16 Oct 2018 21:45:36 -0500 Subject: Youtube Outage In-Reply-To: <9FAD13EB-6B72-4B2C-B386-A316976DE360@thenetworknerds.ca> References: <9FAD13EB-6B72-4B2C-B386-A316976DE360@thenetworknerds.ca> Message-ID: <000c01d465c3$7bfaa940$73effbc0$@gvtc.com> Back up in south central texas -Aaron From: NANOG [mailto:nanog-bounces+aaron1=gvtc.com at nanog.org] On Behalf Of Bryce Wilson Sent: Tuesday, October 16, 2018 9:42 PM To: Ishmael Rufus Cc: NANOG Subject: Re: Youtube Outage I concur, all of my systems have it as back up. Thanks ~ Bryce Wilson, AS202313 On Oct 16, 2018, at 7:40 PM, Ishmael Rufus wrote: Should be coming back online On Tue, Oct 16, 2018 at 9:35 PM Ben Cannon wrote: Confirmed outage in Windsor CA -Ben On Oct 16, 2018, at 7:15 PM, Charles Mills wrote: The reports I've seen showing it as a worldwide outage. On Tue, Oct 16, 2018 at 10:14 PM Nathan Brookfield wrote: Australia too…. From: NANOG On Behalf Of Oliver O'Boyle Sent: Wednesday, October 17, 2018 1:08 PM To: marshall.eubanks at gmail.com Cc: North American Network Operators' Group Subject: Re: Youtube Outage Same in Montreal. On Tue, Oct 16, 2018 at 9:52 PM Marshall Eubanks wrote: Reports (and humor) are flooding twitter. On Tue, Oct 16, 2018 at 9:44 PM Ross Tajvar wrote: > > You beat my email by seconds. Yes, it is widespread. > > On Tue, Oct 16, 2018 at 9:39 PM, Kenneth McRae via NANOG wrote: >> >> Is this widespread? > > -- :o@> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Wed Oct 17 03:20:16 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 16 Oct 2018 23:20:16 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: <23494.43632.718135.903988@gargle.gargle.HOWL> On October 16, 2018 at 19:35 mike at mtcc.com (Michael Thomas) wrote: > I believe that the IETF party line these days is that Postel was wrong > on this point. Security is one consideration, but there are others. Security fits into all this, being liberal in what you accept doesn't mean you do whatever they ask. Quite the contrary it means make sure your code doesn't roll over dead or misbehaving just because you received an unexpected input. Not doing that was exactly what allowed for example buffer overflow attacks. The target software wasn't liberal in what it accepts which is to say anticipated that someone might send them a very long string and should either buffer it correctly or truncate it. They assumed they'd only be sent reasonably short strings. > Mike > > On 10/16/2018 07:18 PM, bzs at theworld.com wrote: > > What it's trying to say is that you have control over your own code > > but not others', in general. > > > > So make your own code (etc) robust and forgiving since you can't edit > > others' code to conform to your own understanding of what they should > > be sending you. > > > > I suppose that pre-dates github but nonetheless much of the code which > > generates bits flung at you is proprietary and otherwise out of your > > control but what you can control is your code's reaction to it. > > > > And of course the bits you generate which should try to make > > conservative assumptions about what they might accept and interpret as > > you expect. > > > > For example just because they sent you a seemingly malformed HTTP > > request, and given that 4xx is for error codes, doesn't mean you > > should return "420 You must be high!" and expect to be understood. > > -- -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 scott.brim at gmail.com Wed Oct 17 03:36:33 2018 From: scott.brim at gmail.com (Scott Brim) Date: Tue, 16 Oct 2018 23:36:33 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: On Tue, Oct 16, 2018, 22:37 Michael Thomas wrote: > I believe that the IETF party line these days is that Postel was wrong > on this point. Security is one consideration, but there are others. > > Mike > I saw just a small swing of the pendulum toward the center, a nuanced meaning for "liberal". The adage wasn't tossed out. Operationally it can't be. Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Wed Oct 17 03:36:46 2018 From: mike at mtcc.com (Michael Thomas) Date: Tue, 16 Oct 2018 20:36:46 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <23494.43632.718135.903988@gargle.gargle.HOWL> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> <23494.43632.718135.903988@gargle.gargle.HOWL> Message-ID: <81650178-e065-0c05-0c08-a5f841d9e31c@mtcc.com> On 10/16/2018 08:20 PM, bzs at theworld.com wrote: > On October 16, 2018 at 19:35 mike at mtcc.com (Michael Thomas) wrote: > > I believe that the IETF party line these days is that Postel was wrong > > on this point. Security is one consideration, but there are others. > > Security fits into all this, being liberal in what you accept doesn't > mean you do whatever they ask. > > Quite the contrary it means make sure your code doesn't roll over dead > or misbehaving just because you received an unexpected input. That's not the same thing. That's never acceptable. Trying to educe what a sender really meant is a good way to create exploitable spaghetti though. But don't take my word for it, reach out to people who pay more attention to such things than me. Mike From mike at mtcc.com Wed Oct 17 03:43:10 2018 From: mike at mtcc.com (Michael Thomas) Date: Tue, 16 Oct 2018 20:43:10 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: <87f9e481-3946-2f1f-57c0-50c922f13f80@mtcc.com> On 10/16/2018 08:36 PM, Scott Brim wrote: > > > On Tue, Oct 16, 2018, 22:37 Michael Thomas > wrote: > > I believe that the IETF party line these days is that Postel was > wrong > on this point. Security is one consideration, but there are others. > > Mike > > > I saw just a small swing of the pendulum toward the center, a nuanced > meaning for "liberal". The adage wasn't tossed out. Operationally it > can't be. > All of the security types were pretty unanimous when this came up during all of the dkim stuff i worked on. I was a fan, and I got schooled. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at timetraveller.org Wed Oct 17 03:49:08 2018 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 17 Oct 2018 13:49:08 +1000 (AEST) Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: On Tue, 16 Oct 2018, Michael Thomas wrote: > I believe that the IETF party line these days is that Postel was wrong on > this point. Security is one consideration, but there are others. Postel's Law is about robustness of network communications. As such it can *increase* network security by improving availability [CIA triad] although it could potentially reduce confidentiality and integrity in some circumstances. Whether or not Postel's Law improves or degrades security would need to be assessed on a case by case basis. Cheers, Rob From kmedcalf at dessus.com Wed Oct 17 04:44:05 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 16 Oct 2018 22:44:05 -0600 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: >For example just because they sent you a seemingly malformed HTTP >request, and given that 4xx is for error codes, doesn't mean you >should return "420 You must be high!" and expect to be understood. Actually, you can, and the sender of the request MUST understand. The relevant part of the applicable RFC says: HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From laszlo at heliacal.net Wed Oct 17 13:04:19 2018 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 17 Oct 2018 13:04:19 +0000 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: <1e450a72-1448-67d1-021c-5b20d88ba68c@heliacal.net> On 2018-10-17 02:35, Michael Thomas wrote: > I believe that the IETF party line these days is that Postel was wrong > on this point. Security is one consideration, but there are others. Postel's maxim also allowed extensibility.  If our network code rejects (or crashes) on things we don't currently understand and use, it ensures that they can't be used by apps that come along later either.  The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS. > > Mike > > On 10/16/2018 07:18 PM, bzs at theworld.com wrote: >> What it's trying to say is that you have control over your own code >> but not others', in general. >> >> So make your own code (etc) robust and forgiving since you can't edit >> others' code to conform to your own understanding of what they should >> be sending you. >> >> I suppose that pre-dates github but nonetheless much of the code which >> generates bits flung at you is proprietary and otherwise out of your >> control but what you can control is your code's reaction to it. >> >> And of course the bits you generate which should try to make >> conservative assumptions about what they might accept and interpret as >> you expect. >> >> For example just because they sent you a seemingly malformed HTTP >> request, and given that 4xx is for error codes, doesn't mean you >> should return "420 You must be high!" and expect to be understood. >> > From josh at imaginenetworksllc.com Wed Oct 17 15:47:27 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 Oct 2018 11:47:27 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) Message-ID: Has anyone else dealt with this mess? Even my Cogent rep admits it's unique to their business. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at unlimitednet.us Wed Oct 17 15:49:10 2018 From: jason at unlimitednet.us (Jason Canady) Date: Wed, 17 Oct 2018 11:49:10 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: Message-ID: Yes.  Our service didn't start out this way, but a few years ago they added that.  At least my rep at the time quoted me out with the fee added into it.  I believe IPv6 BGP is free. On 10/17/18 11:47 AM, Josh Luthman wrote: > Has anyone else dealt with this mess?  Even my Cogent rep admits it's > unique to their business. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Wed Oct 17 15:53:47 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 17 Oct 2018 15:53:47 +0000 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: Message-ID: Yep we pay it on our circuits, begrudgingly. Wouldn’t mind it as much if it actually delivered me every BGP prefix in the global routing table… From: NANOG on behalf of Josh Luthman Date: Wednesday, October 17, 2018 at 11:49 AM To: NANOG list Subject: Cogent charging 50/mo for BGP (not IPs, the service) Has anyone else dealt with this mess? Even my Cogent rep admits it's unique to their business. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Oct 17 15:58:55 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 17 Oct 2018 11:58:55 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: Message-ID: <14930.1539791935@turing-police.cc.vt.edu> On Wed, 17 Oct 2018 15:53:47 -0000, David Hubbard said: > Yep we pay it on our circuits, begrudgingly. Wouldn’t mind it as much if it > actually delivered me every BGP prefix in the global routing table… On Wed, 17 Oct 2018 11:49:10 -0400, Jason Canady said: >  I believe IPv6 BGP is free. Draw your own conclusions... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From bruns at 2mbit.com Wed Oct 17 15:59:43 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 17 Oct 2018 09:59:43 -0600 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: Message-ID: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> On 10/17/2018 9:47 AM, Josh Luthman wrote: > Has anyone else dealt with this mess?  Even my Cogent rep admits it's > unique to their business. That sounds like the BS the first company I worked for tried to pull. One would think they'd welcome customers bringing their own IP space since it saves them money by not using up precious Cogent IPv4 address space. Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and its available as part of the enhanced package they offer with no extra fees. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jeff+nanog at waddellsolutions.com Wed Oct 17 16:00:50 2018 From: jeff+nanog at waddellsolutions.com (Jeff Waddell) Date: Wed, 17 Oct 2018 12:00:50 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: Message-ID: Yes - we just renewed/ upgraded and they hit us with it - pushed back at the lower the bandwidth cost a little bit to compensate for it On Wed, Oct 17, 2018 at 11:55 AM David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Yep we pay it on our circuits, begrudgingly. Wouldn’t mind it as much if > it actually delivered me every BGP prefix in the global routing table… > > > > *From: *NANOG on behalf of Josh Luthman < > josh at imaginenetworksllc.com> > *Date: *Wednesday, October 17, 2018 at 11:49 AM > *To: *NANOG list > *Subject: *Cogent charging 50/mo for BGP (not IPs, the service) > > > > Has anyone else dealt with this mess? Even my Cogent rep admits it's > unique to their business. > > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Wed Oct 17 16:05:57 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 Oct 2018 12:05:57 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> Message-ID: I view Cogent IP space as a way to lock customers to their service, ie make them sticky. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns wrote: > On 10/17/2018 9:47 AM, Josh Luthman wrote: > > Has anyone else dealt with this mess? Even my Cogent rep admits it's > > unique to their business. > > That sounds like the BS the first company I worked for tried to pull. > > One would think they'd welcome customers bringing their own IP space > since it saves them money by not using up precious Cogent IPv4 address > space. > > Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and > its available as part of the enhanced package they offer with no extra > fees. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhubbard at dino.hostasaurus.com Wed Oct 17 16:12:01 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 17 Oct 2018 16:12:01 +0000 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> Message-ID: <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> They charge it even if you’re using your own address space. It’s a fee simply for establishing BGP with them on a given circuit. I believe if you used static routes and their space, you would not have to pay it. From: NANOG on behalf of Josh Luthman Date: Wednesday, October 17, 2018 at 12:10 PM To: Brielle Bruns Cc: NANOG list Subject: Re: Cogent charging 50/mo for BGP (not IPs, the service) I view Cogent IP space as a way to lock customers to their service, ie make them sticky. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns > wrote: On 10/17/2018 9:47 AM, Josh Luthman wrote: > Has anyone else dealt with this mess? Even my Cogent rep admits it's > unique to their business. That sounds like the BS the first company I worked for tried to pull. One would think they'd welcome customers bringing their own IP space since it saves them money by not using up precious Cogent IPv4 address space. Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and its available as part of the enhanced package they offer with no extra fees. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at wpi.edu Wed Oct 17 16:24:39 2018 From: cra at wpi.edu (Anderson, Charles R) Date: Wed, 17 Oct 2018 16:24:39 +0000 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> Message-ID: <20181017162435.t3wgs5uymkdm7biq@angus.ind.wpi.edu> I was told they only charge it if you have bigger than a /29 from them. On Wed, Oct 17, 2018 at 04:12:01PM +0000, David Hubbard wrote: > They charge it even if you’re using your own address space. It’s a fee simply for establishing BGP with them on a given circuit. I believe if you used static routes and their space, you would not have to pay it. > > From: NANOG on behalf of Josh Luthman > Date: Wednesday, October 17, 2018 at 12:10 PM > To: Brielle Bruns > Cc: NANOG list > Subject: Re: Cogent charging 50/mo for BGP (not IPs, the service) > > I view Cogent IP space as a way to lock customers to their service, ie make them sticky. > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns > wrote: > On 10/17/2018 9:47 AM, Josh Luthman wrote: > > Has anyone else dealt with this mess? Even my Cogent rep admits it's > > unique to their business. > > That sounds like the BS the first company I worked for tried to pull. > > One would think they'd welcome customers bringing their own IP space > since it saves them money by not using up precious Cogent IPv4 address > space. > > Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and > its available as part of the enhanced package they offer with no extra fees. From josh at imaginenetworksllc.com Wed Oct 17 16:36:39 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Wed, 17 Oct 2018 12:36:39 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: <20181017162435.t3wgs5uymkdm7biq@angus.ind.wpi.edu> References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> <20181017162435.t3wgs5uymkdm7biq@angus.ind.wpi.edu> Message-ID: They gave me a free /29 and then when I reminded them about BGP they popped up another agreement for $50/mo. This was today. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Oct 17, 2018, 12:25 PM Anderson, Charles R wrote: > I was told they only charge it if you have bigger than a /29 from them. > > On Wed, Oct 17, 2018 at 04:12:01PM +0000, David Hubbard wrote: > > They charge it even if you’re using your own address space. It’s a fee > simply for establishing BGP with them on a given circuit. I believe if you > used static routes and their space, you would not have to pay it. > > > > From: NANOG on behalf of Josh Luthman < > josh at imaginenetworksllc.com> > > Date: Wednesday, October 17, 2018 at 12:10 PM > > To: Brielle Bruns > > Cc: NANOG list > > Subject: Re: Cogent charging 50/mo for BGP (not IPs, the service) > > > > I view Cogent IP space as a way to lock customers to their service, ie > make them sticky. > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns bruns at 2mbit.com>> wrote: > > On 10/17/2018 9:47 AM, Josh Luthman wrote: > > > Has anyone else dealt with this mess? Even my Cogent rep admits it's > > > unique to their business. > > > > That sounds like the BS the first company I worked for tried to pull. > > > > One would think they'd welcome customers bringing their own IP space > > since it saves them money by not using up precious Cogent IPv4 address > > space. > > > > Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and > > its available as part of the enhanced package they offer with no extra > fees. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Wed Oct 17 16:42:08 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 17 Oct 2018 09:42:08 -0700 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> <20181017162435.t3wgs5uymkdm7biq@angus.ind.wpi.edu> Message-ID: <41087CEA-E866-48E7-9988-035089593B7B@6by7.net> We pay it too and I’ve asked to have it waived -Ben > On Oct 17, 2018, at 9:36 AM, Josh Luthman wrote: > > They gave me a free /29 and then when I reminded them about BGP they popped up another agreement for $50/mo. This was today. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > >> On Wed, Oct 17, 2018, 12:25 PM Anderson, Charles R wrote: >> I was told they only charge it if you have bigger than a /29 from them. >> >> On Wed, Oct 17, 2018 at 04:12:01PM +0000, David Hubbard wrote: >> > They charge it even if you’re using your own address space. It’s a fee simply for establishing BGP with them on a given circuit. I believe if you used static routes and their space, you would not have to pay it. >> > >> > From: NANOG on behalf of Josh Luthman >> > Date: Wednesday, October 17, 2018 at 12:10 PM >> > To: Brielle Bruns >> > Cc: NANOG list >> > Subject: Re: Cogent charging 50/mo for BGP (not IPs, the service) >> > >> > I view Cogent IP space as a way to lock customers to their service, ie make them sticky. >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> > >> > On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns > wrote: >> > On 10/17/2018 9:47 AM, Josh Luthman wrote: >> > > Has anyone else dealt with this mess? Even my Cogent rep admits it's >> > > unique to their business. >> > >> > That sounds like the BS the first company I worked for tried to pull. >> > >> > One would think they'd welcome customers bringing their own IP space >> > since it saves them money by not using up precious Cogent IPv4 address >> > space. >> > >> > Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and >> > its available as part of the enhanced package they offer with no extra fees. -------------- next part -------------- An HTML attachment was scrubbed... URL: From afmug at zirkel.us Wed Oct 17 17:13:16 2018 From: afmug at zirkel.us (Sean Heskett) Date: Wed, 17 Oct 2018 11:13:16 -0600 Subject: verizon wifi calling stopped working Message-ID: Hello, Is anyone from verizon wireless on here. clients across our network started complaining 2 weeks ago that wifi calling stopped working. below are some pings at traceroutes to wo.vzwwo.com which fail. the first set is with our normal DNS servers and the second set is using 8.8.8.8 Thanks, *Sean Heskett* *ZIRKEL Wireless * *High-Speed Internet for NW Colorado* 970-871-8500 x100 - Office 970-846-8065 - mobile 866-903-4628 - Fax Website | Facebook MBP-Sean:~ sean$ ping wo.vzwwo.com PING wo.vzwwo.com (141.207.177.233): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 ^C --- wo.vzwwo.com ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss MBP-Sean:~ sean$ traceroute wo.vzwwo.com traceroute: Warning: wo.vzwwo.com has multiple addresses; using 141.207.177.233 traceroute to wo.vzwwo.com (141.207.177.233), 64 hops max, 52 byte packets 1 192.168.12.1 (192.168.12.1) 0.810 ms 0.586 ms 0.571 ms 2 rtr-edge-rht.zirkelwireless.com (65.117.208.1) 1.547 ms 1.640 ms 1.550 ms 3 65-117-210-178.zirkelwireless.com (65.117.210.178) 2.494 ms 2.412 ms 2.249 ms 4 72-55-193-5.mammothnetworks.com (72.55.193.5) 5.149 ms 6.783 ms 5.540 ms 5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com (38.140.187.145) 5.996 ms 5.880 ms 5.756 ms 6 be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 6.072 ms be3415.ccr22.den01.atlas.cogentco.com (154.54.30.241) 6.252 ms be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 6.203 ms 7 be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.542 ms be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90) 17.646 ms be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.038 ms 8 be2433.ccr32.dfw01.atlas.cogentco.com (154.54.3.213) 27.259 ms 27.265 ms be2432.ccr31.dfw01.atlas.cogentco.com (154.54.3.133) 27.198 ms 9 be2764.ccr41.dfw03.atlas.cogentco.com (154.54.47.214) 28.024 ms be2763.ccr41.dfw03.atlas.cogentco.com (154.54.28.74) 27.870 ms 27.955 ms 10 verizon.dfw03.atlas.cogentco.com (154.54.12.206) 27.478 ms 48.841 ms 40.085 ms 11 0.et-10-1-0.gw8.chi13.alter.net (140.222.236.209) 40.159 ms 0.et-11-3-0.gw8.chi13.alter.net (140.222.231.217) 39.879 ms 0.et-10-1-0.gw8.chi13.alter.net (140.222.236.209) 40.217 ms 12 * * * ^C MBP-Sean:~ sean$ ping wo.vzwwo.com PING wo.vzwwo.com (141.207.193.233): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 ^C --- wo.vzwwo.com ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss MBP-Sean:~ sean$ traceroute wo.vzwwo.com traceroute: Warning: wo.vzwwo.com has multiple addresses; using 141.207.193.233 traceroute to wo.vzwwo.com (141.207.193.233), 64 hops max, 52 byte packets 1 192.168.12.1 (192.168.12.1) 0.896 ms 0.593 ms 0.583 ms 2 rtr-edge-rht.zirkelwireless.com (65.117.208.1) 1.453 ms 1.312 ms 1.181 ms 3 65-117-210-178.zirkelwireless.com (65.117.210.178) 2.446 ms 2.061 ms 2.237 ms 4 72-55-193-5.mammothnetworks.com (72.55.193.5) 5.152 ms 5.121 ms 5.124 ms 5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com (38.140.187.145) 5.716 ms 5.748 ms 5.506 ms 6 be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 5.919 ms be3415.ccr22.den01.atlas.cogentco.com (154.54.30.241) 6.004 ms be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 7.184 ms 7 be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.233 ms be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90) 17.397 ms be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.859 ms 8 be2433.ccr32.dfw01.atlas.cogentco.com (154.54.3.213) 27.428 ms 27.476 ms be2432.ccr31.dfw01.atlas.cogentco.com (154.54.3.133) 27.606 ms 9 be2764.ccr41.dfw03.atlas.cogentco.com (154.54.47.214) 28.129 ms be2763.ccr41.dfw03.atlas.cogentco.com (154.54.28.74) 28.009 ms 27.497 ms 10 verizon.dfw03.atlas.cogentco.com (154.54.12.206) 27.402 ms 27.451 ms 27.445 ms 11 0.et-11-3-0.gw10.dfw7.alter.net (140.222.228.115) 29.849 ms 29.039 ms 0.et-10-1-0.gw10.dfw7.alter.net (140.222.0.113) 29.132 ms ^C MBP-Sean:~ sean$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Oct 17 19:31:20 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 17 Oct 2018 12:31:20 -0700 Subject: Reno local fibre providers Message-ID: hi there, I am trying to help a good friend of mine to connect his office to a pop (in bay area most likely) so I am in the need of identifying some network providers in Reno who can provide this service. Currently charter and AT&T are onnet in the facility but the prices they are quoting is "out of this world" :) thank you for your help Mehmet From fw at deneb.enyo.de Wed Oct 17 19:41:24 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 17 Oct 2018 21:41:24 +0200 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: (Scott Brim's message of "Tue, 16 Oct 2018 23:36:33 -0400") References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> Message-ID: <87woqgcqe3.fsf@mid.deneb.enyo.de> * Scott Brim: > On Tue, Oct 16, 2018, 22:37 Michael Thomas wrote: > >> I believe that the IETF party line these days is that Postel was wrong >> on this point. Security is one consideration, but there are others. >> >> Mike >> > > I saw just a small swing of the pendulum toward the center, a nuanced > meaning for "liberal". The adage wasn't tossed out. Operationally it can't > be. I think DMARC, as it is deployed right now, pretty much killed the “liberal” part for many people. It's sender policy, but it's necessarily enforced at the recipient end, but many recipients aren't given a choice to opt out when it is technically the wrong thing to do. You can switch email providers, but as the IETF never really designed for email address portability, that's a theoretical option only for many. From sethm at rollernet.us Wed Oct 17 19:56:37 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 17 Oct 2018 12:56:37 -0700 Subject: Reno local fibre providers In-Reply-To: References: Message-ID: <28fc38eb-2b35-fc12-b70a-393ff8648958@rollernet.us> On 10/17/18 12:31 PM, Mehmet Akcin wrote: > hi there, > > I am trying to help a good friend of mine to connect his office to a > pop (in bay area most likely) so I am in the need of identifying some > network providers in Reno who can provide this service. Currently > charter and AT&T are onnet in the facility but the prices they are > quoting is "out of this world" :) > I guess that depends, if you mean colo then you could consider Hurricane Electric. They have better pricing than AT&T and Charter. If you mean to a house that's going to be limited. ~Seth From fw at deneb.enyo.de Wed Oct 17 19:43:20 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 17 Oct 2018 21:43:20 +0200 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <1e450a72-1448-67d1-021c-5b20d88ba68c@heliacal.net> (Laszlo Hanyecz's message of "Wed, 17 Oct 2018 13:04:19 +0000") References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> <1e450a72-1448-67d1-021c-5b20d88ba68c@heliacal.net> Message-ID: <87sh14cqav.fsf@mid.deneb.enyo.de> * Laszlo Hanyecz: > On 2018-10-17 02:35, Michael Thomas wrote: >> I believe that the IETF party line these days is that Postel was wrong >> on this point. Security is one consideration, but there are others. > > Postel's maxim also allowed extensibility.  If our network code rejects > (or crashes) on things we don't currently understand and use, it ensures > that they can't be used by apps that come along later either.  The > attitude of rejecting everything in the name of security is what has > forced app developers to tunnel APIs and everything else inside HTTP/DNS. To be fair, a lot of these components that make extending protocols hard are both receivers and senders. If they are asked to forward garbage, then something has to give. From bzs at theworld.com Wed Oct 17 20:39:09 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 17 Oct 2018 16:39:09 -0400 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <87woqgcqe3.fsf@mid.deneb.enyo.de> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> <87woqgcqe3.fsf@mid.deneb.enyo.de> Message-ID: <23495.40429.682673.131676@gargle.gargle.HOWL> I'm probably going to regret posting this but I think most of this dispute regarding Jon Postel's advice revolves around how the words "liberal" and "conservative" have changed over 20 years. Liberal used to mean adaptable, open-minded, and conservative used to mean cautious and hewing close to the rules (and I mean none of that disparagingly.) I won't begin to characterize how these words have changed but, um, ach, phffft, AGHHH!...they didn't mean calling your personal prostitute a "horseface" or arguing that point via the public internet. -- -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 mike at mtcc.com Wed Oct 17 20:45:53 2018 From: mike at mtcc.com (Michael Thomas) Date: Wed, 17 Oct 2018 13:45:53 -0700 Subject: It's been 20 years today (Oct 16, UTC). Hard to believe. In-Reply-To: <87sh14cqav.fsf@mid.deneb.enyo.de> References: <20181016101121.469B8F56@m0117568.ppops.net> <20181016181030.GA8414@meow.BKantor.net> <23494.39926.405612.48460@gargle.gargle.HOWL> <1e450a72-1448-67d1-021c-5b20d88ba68c@heliacal.net> <87sh14cqav.fsf@mid.deneb.enyo.de> Message-ID: On 10/17/2018 12:43 PM, Florian Weimer wrote: > * Laszlo Hanyecz: > >> On 2018-10-17 02:35, Michael Thomas wrote: >>> I believe that the IETF party line these days is that Postel was wrong >>> on this point. Security is one consideration, but there are others. >> Postel's maxim also allowed extensibility.  If our network code rejects >> (or crashes) on things we don't currently understand and use, it ensures >> that they can't be used by apps that come along later either.  The >> attitude of rejecting everything in the name of security is what has >> forced app developers to tunnel APIs and everything else inside HTTP/DNS. Let's be clear: crashing is a software bug. It has nothing to do with Postel. On the extensibility part, that is for the protocol itself to define, and it should be explicit. If the protocol says to reject, then you must reject. I'm not sure if extensibility one of the global protocol check offs, but it certainly should be part of any stander. > To be fair, a lot of these components that make extending protocols > hard are both receivers and senders. If they are asked to forward > garbage, then something has to give. Yes, the protocol should tell you what to do. If it doesn't, its deficient. Mike From bruns at 2mbit.com Thu Oct 18 01:10:54 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 17 Oct 2018 19:10:54 -0600 Subject: [OT?] Anyone else been contacted by networkequipment.net after commenting here? Message-ID: <339eca7d-df1e-0657-57ec-c940237e0e2c@2mbit.com> So I decided to respond to a message earlier - was the first time in quite a while on the NANOG list. Like, we're talking maybe 3-6 months since my last post? This afternoon I get an e-mail from Brad Lovelace asking me if I have cisco, juniper, etc to sell to his company, claimed I have done business with him before (even though I've never sold any equipment to them, nor have we ever communicated before - my e-mail archives go back to 1996 or so). Isn't the first time I've been contacted by a networking gear vendor after they 'mysteriously' got my e-mail address (shortly after I posted a comment here) as someone who was interested in their wares. We may have someone scraping e-mail addresses and names from the nanog list - don't suppose the mods might be so gracious enough to look at the sub list and see if anyone from networkequipment.net is on here? Sorry in advance to go somewhat OT. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From matt.larson at icann.org Thu Oct 18 08:55:44 2018 From: matt.larson at icann.org (Matt Larson) Date: Thu, 18 Oct 2018 08:55:44 +0000 Subject: Anyone from Consolidated Communications here? Message-ID: <1797DB10-8A31-42FD-81F6-3A99AB0A9DA6@icann.org> Could someone in operations from Consolidated Communications in Vermont please contact me off list, if possible? Thanks, Matt -- Matt Larson, VP of Research ICANN Office of the CTO -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Thu Oct 18 15:28:10 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 18 Oct 2018 11:28:10 -0400 Subject: verizon wifi calling stopped working In-Reply-To: References: Message-ID: If someone from Verizon Wireless specifically for WiFi calling could reach out to me to fix our devices I would appreciate it. The WiFi calling works just fine when we reboot in the office, but it will never reconnect (ie we leave the office, get 4G, come back). I've opened 3-4 tickets with no resolution. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Oct 17, 2018 at 1:13 PM, Sean Heskett wrote: > Hello, > > Is anyone from verizon wireless on here. clients across our network > started complaining 2 weeks ago that wifi calling stopped working. below > are some pings at traceroutes to wo.vzwwo.com which fail. the first set > is with our normal DNS servers and the second set is using 8.8.8.8 > > Thanks, > > *Sean Heskett* > > *ZIRKEL Wireless * > *High-Speed Internet for NW Colorado* > 970-871-8500 x100 - Office > 970-846-8065 - mobile > 866-903-4628 - Fax > Website | Facebook > > > > MBP-Sean:~ sean$ ping wo.vzwwo.com > > PING wo.vzwwo.com (141.207.177.233): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > Request timeout for icmp_seq 3 > > ^C > > --- wo.vzwwo.com ping statistics --- > > 5 packets transmitted, 0 packets received, 100.0% packet loss > > MBP-Sean:~ sean$ traceroute wo.vzwwo.com > > traceroute: Warning: wo.vzwwo.com has multiple addresses; using > 141.207.177.233 > > traceroute to wo.vzwwo.com (141.207.177.233), 64 hops max, 52 byte packets > > 1 192.168.12.1 (192.168.12.1) 0.810 ms 0.586 ms 0.571 ms > > 2 rtr-edge-rht.zirkelwireless.com (65.117.208.1) 1.547 ms 1.640 ms > 1.550 ms > > 3 65-117-210-178.zirkelwireless.com (65.117.210.178) 2.494 ms 2.412 > ms 2.249 ms > > 4 72-55-193-5.mammothnetworks.com (72.55.193.5) 5.149 ms 6.783 ms > 5.540 ms > > 5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com (38.140.187.145) > 5.996 ms 5.880 ms 5.756 ms > > 6 be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 6.072 ms > > be3415.ccr22.den01.atlas.cogentco.com (154.54.30.241) 6.252 ms > > be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 6.203 ms > > 7 be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.542 ms > > be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90) 17.646 ms > > be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.038 ms > > 8 be2433.ccr32.dfw01.atlas.cogentco.com (154.54.3.213) 27.259 ms > 27.265 ms > > be2432.ccr31.dfw01.atlas.cogentco.com (154.54.3.133) 27.198 ms > > 9 be2764.ccr41.dfw03.atlas.cogentco.com (154.54.47.214) 28.024 ms > > be2763.ccr41.dfw03.atlas.cogentco.com (154.54.28.74) 27.870 ms > 27.955 ms > > 10 verizon.dfw03.atlas.cogentco.com (154.54.12.206) 27.478 ms 48.841 > ms 40.085 ms > > 11 0.et-10-1-0.gw8.chi13.alter.net (140.222.236.209) 40.159 ms > > 0.et-11-3-0.gw8.chi13.alter.net (140.222.231.217) 39.879 ms > > 0.et-10-1-0.gw8.chi13.alter.net (140.222.236.209) 40.217 ms > > 12 * * * > > ^C > > MBP-Sean:~ sean$ ping wo.vzwwo.com > > PING wo.vzwwo.com (141.207.193.233): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > ^C > > --- wo.vzwwo.com ping statistics --- > > 4 packets transmitted, 0 packets received, 100.0% packet loss > > MBP-Sean:~ sean$ traceroute wo.vzwwo.com > > traceroute: Warning: wo.vzwwo.com has multiple addresses; using > 141.207.193.233 > > traceroute to wo.vzwwo.com (141.207.193.233), 64 hops max, 52 byte packets > > 1 192.168.12.1 (192.168.12.1) 0.896 ms 0.593 ms 0.583 ms > > 2 rtr-edge-rht.zirkelwireless.com (65.117.208.1) 1.453 ms 1.312 ms > 1.181 ms > > 3 65-117-210-178.zirkelwireless.com (65.117.210.178) 2.446 ms 2.061 > ms 2.237 ms > > 4 72-55-193-5.mammothnetworks.com (72.55.193.5) 5.152 ms 5.121 ms > 5.124 ms > > 5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com (38.140.187.145) > 5.716 ms 5.748 ms 5.506 ms > > 6 be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 5.919 ms > > be3415.ccr22.den01.atlas.cogentco.com (154.54.30.241) 6.004 ms > > be3414.ccr21.den01.atlas.cogentco.com (66.28.4.205) 7.184 ms > > 7 be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.233 ms > > be3036.ccr22.mci01.atlas.cogentco.com (154.54.31.90) 17.397 ms > > be3035.ccr21.mci01.atlas.cogentco.com (154.54.5.90) 17.859 ms > > 8 be2433.ccr32.dfw01.atlas.cogentco.com (154.54.3.213) 27.428 ms > 27.476 ms > > be2432.ccr31.dfw01.atlas.cogentco.com (154.54.3.133) 27.606 ms > > 9 be2764.ccr41.dfw03.atlas.cogentco.com (154.54.47.214) 28.129 ms > > be2763.ccr41.dfw03.atlas.cogentco.com (154.54.28.74) 28.009 ms > 27.497 ms > > 10 verizon.dfw03.atlas.cogentco.com (154.54.12.206) 27.402 ms 27.451 > ms 27.445 ms > > 11 0.et-11-3-0.gw10.dfw7.alter.net (140.222.228.115) 29.849 ms 29.039 > ms > > 0.et-10-1-0.gw10.dfw7.alter.net (140.222.0.113) 29.132 ms > > ^C > > MBP-Sean:~ sean$ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Thu Oct 18 15:41:02 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 18 Oct 2018 09:41:02 -0600 Subject: verizon wifi calling stopped working In-Reply-To: References: Message-ID: <52536152-ab40-0368-115e-250681e2d0d7@2mbit.com> IIRC, the Wifi calling stuff works over IPSec from the devices back to a concentrator device. Are you able to look on your network firewall/router/nat device and see if you have lingering IPSec sessions hung open, or if there's a network ALG that might be playing a part? I used to have issues like this with T-Mobile and UMA. On 10/18/2018 9:28 AM, Josh Luthman wrote: > If someone from Verizon Wireless specifically for WiFi calling could > reach out to me to fix our devices I would appreciate it.  The WiFi > calling works just fine when we reboot in the office, but it will never > reconnect (ie we leave the office, get 4G, come back).  I've opened 3-4 > tickets with no resolution. > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Oct 17, 2018 at 1:13 PM, Sean Heskett > wrote: > > Hello, > > Is anyone from verizon wireless on here.  clients across our network > started complaining 2 weeks ago that wifi calling stopped working. >  below are some pings at traceroutes to wo.vzwwo.com > which fail.  the first set is with our normal > DNS servers and the second set is using 8.8.8.8 > > Thanks, > > *Sean Heskett* > * > * > *ZIRKEL Wireless * > */High-Speed Internet/ for NW Colorado* > 970-871-8500 x100 - Office > 970-846-8065 - mobile > 866-903-4628 - Fax > Website  | Facebook > > > > MBP-Sean:~ sean$ ping wo.vzwwo.com > > PING wo.vzwwo.com (141.207.177.233): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > Request timeout for icmp_seq 3 > > ^C > > --- wo.vzwwo.com ping statistics --- > > 5 packets transmitted, 0 packets received, 100.0% packet loss > > MBP-Sean:~ sean$ traceroute wo.vzwwo.com > > traceroute: Warning: wo.vzwwo.com has multiple > addresses; using 141.207.177.233 > > traceroute to wo.vzwwo.com (141.207.177.233), > 64 hops max, 52 byte packets > >  1  192.168.12.1 (192.168.12.1)  0.810 ms  0.586 ms  0.571 ms > >  2 rtr-edge-rht.zirkelwireless.com > (65.117.208.1)  1.547 ms > 1.640 ms  1.550 ms > >  3 65-117-210-178.zirkelwireless.com > (65.117.210.178)  2.494 > ms  2.412 ms  2.249 ms > >  4 72-55-193-5.mammothnetworks.com > (72.55.193.5)  5.149 ms > 6.783 ms  5.540 ms > >  5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com > > (38.140.187.145)  5.996 ms  5.880 ms  5.756 ms > >  6 be3414.ccr21.den01.atlas.cogentco.com > (66.28.4.205)  6.072 ms > > be3415.ccr22.den01.atlas.cogentco.com > (154.54.30.241)  6.252 ms > > be3414.ccr21.den01.atlas.cogentco.com > (66.28.4.205)  6.203 ms > >  7 be3035.ccr21.mci01.atlas.cogentco.com > (154.54.5.90)  17.542 ms > > be3036.ccr22.mci01.atlas.cogentco.com > (154.54.31.90)  17.646 ms > > be3035.ccr21.mci01.atlas.cogentco.com > (154.54.5.90)  17.038 ms > >  8 be2433.ccr32.dfw01.atlas.cogentco.com > (154.54.3.213) > 27.259 ms  27.265 ms > > be2432.ccr31.dfw01.atlas.cogentco.com > (154.54.3.133)  27.198 ms > >  9 be2764.ccr41.dfw03.atlas.cogentco.com > (154.54.47.214) > 28.024 ms > > be2763.ccr41.dfw03.atlas.cogentco.com > (154.54.28.74) > 27.870 ms  27.955 ms > > 10 verizon.dfw03.atlas.cogentco.com > (154.54.12.206)  27.478 > ms  48.841 ms  40.085 ms > > 11 0.et-10-1-0.gw8.chi13.alter.net > (140.222.236.209)  40.159 ms > > 0.et-11-3-0.gw8.chi13.alter.net > (140.222.231.217)  39.879 ms > > 0.et-10-1-0.gw8.chi13.alter.net > (140.222.236.209)  40.217 ms > > 12  * * * > > ^C > > MBP-Sean:~ sean$ ping wo.vzwwo.com > > PING wo.vzwwo.com (141.207.193.233): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > ^C > > --- wo.vzwwo.com ping statistics --- > > 4 packets transmitted, 0 packets received, 100.0% packet loss > > MBP-Sean:~ sean$ traceroute wo.vzwwo.com > > traceroute: Warning: wo.vzwwo.com has multiple > addresses; using 141.207.193.233 > > traceroute to wo.vzwwo.com (141.207.193.233), > 64 hops max, 52 byte packets > >  1  192.168.12.1 (192.168.12.1)  0.896 ms  0.593 ms  0.583 ms > >  2 rtr-edge-rht.zirkelwireless.com > (65.117.208.1)  1.453 ms > 1.312 ms  1.181 ms > >  3 65-117-210-178.zirkelwireless.com > (65.117.210.178)  2.446 > ms  2.061 ms  2.237 ms > >  4 72-55-193-5.mammothnetworks.com > (72.55.193.5)  5.152 ms > 5.121 ms  5.124 ms > >  5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com > > (38.140.187.145)  5.716 ms  5.748 ms  5.506 ms > >  6 be3414.ccr21.den01.atlas.cogentco.com > (66.28.4.205)  5.919 ms > > be3415.ccr22.den01.atlas.cogentco.com > (154.54.30.241)  6.004 ms > > be3414.ccr21.den01.atlas.cogentco.com > (66.28.4.205)  7.184 ms > >  7 be3035.ccr21.mci01.atlas.cogentco.com > (154.54.5.90)  17.233 ms > > be3036.ccr22.mci01.atlas.cogentco.com > (154.54.31.90)  17.397 ms > > be3035.ccr21.mci01.atlas.cogentco.com > (154.54.5.90)  17.859 ms > >  8 be2433.ccr32.dfw01.atlas.cogentco.com > (154.54.3.213) > 27.428 ms  27.476 ms > > be2432.ccr31.dfw01.atlas.cogentco.com > (154.54.3.133)  27.606 ms > >  9 be2764.ccr41.dfw03.atlas.cogentco.com > (154.54.47.214) > 28.129 ms > > be2763.ccr41.dfw03.atlas.cogentco.com > (154.54.28.74) > 28.009 ms  27.497 ms > > 10 verizon.dfw03.atlas.cogentco.com > (154.54.12.206)  27.402 > ms  27.451 ms  27.445 ms > > 11 0.et-11-3-0.gw10.dfw7.alter.net > (140.222.228.115)  29.849 > ms  29.039 ms > > 0.et-10-1-0.gw10.dfw7.alter.net > (140.222.0.113)  29.132 ms > > ^C > > MBP-Sean:~ sean$ > > > -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From surfer at mauigateway.com Thu Oct 18 16:50:14 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 18 Oct 2018 09:50:14 -0700 Subject: [OT?] Anyone else been contacted by networkequipment.net after commenting here? Message-ID: <20181018095014.469A8D59@m0117566.ppops.net> --- bruns at 2mbit.com wrote: From: Brielle Bruns RE shaming: networkequipment.net Isn't the first time I've been contacted by a networking gear vendor after they 'mysteriously' got my e-mail address (shortly after I posted a comment here) as someone who was interested in their wares. --------------------------------------------- We should get a list of these folks so we can look at it when we're buying so we don't purchase from these types of companies/people. scott From saku at ytti.fi Thu Oct 18 17:11:00 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 18 Oct 2018 20:11:00 +0300 Subject: [OT?] Anyone else been contacted by networkequipment.net after commenting here? In-Reply-To: <339eca7d-df1e-0657-57ec-c940237e0e2c@2mbit.com> References: <339eca7d-df1e-0657-57ec-c940237e0e2c@2mbit.com> Message-ID: Hey. I got the same spam from Brad and actually have Cat trash to offload, so I iterated SKUs and counts, and his reply: --- thank you Saku ... Feel free to hit me up anytime and have a fun week, Brad ------- Dunno what to make of it, that's as far as it went. I expected offer or 'we can't sell those', I don't know what this response even means. On Thu, 18 Oct 2018 at 04:14, Brielle Bruns wrote: > > So I decided to respond to a message earlier - was the first time in > quite a while on the NANOG list. Like, we're talking maybe 3-6 months > since my last post? > > This afternoon I get an e-mail from Brad Lovelace > asking me if I have cisco, juniper, etc to > sell to his company, claimed I have done business with him before (even > though I've never sold any equipment to them, nor have we ever > communicated before - my e-mail archives go back to 1996 or so). > > Isn't the first time I've been contacted by a networking gear vendor > after they 'mysteriously' got my e-mail address (shortly after I posted > a comment here) as someone who was interested in their wares. > > We may have someone scraping e-mail addresses and names from the nanog > list - don't suppose the mods might be so gracious enough to look at the > sub list and see if anyone from networkequipment.net is on here? > > Sorry in advance to go somewhat OT. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org -- ++ytti, me fail English? Impossible. From josh at imaginenetworksllc.com Thu Oct 18 18:05:35 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 18 Oct 2018 14:05:35 -0400 Subject: MSN.com blocking some customers Message-ID: I have a couple of customers in a /23 (possibly a /24) seemingly random that aren't able to get to MSN.com - this is http://msn.com not the win32 app or O365 and such. Would there be someone that can reach out to me offlist to take a look at this? I have two verified cases for the last 4 days where every website works except for http://msn.com Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Thu Oct 18 18:13:23 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 18 Oct 2018 14:13:23 -0400 Subject: verizon wifi calling stopped working In-Reply-To: <52536152-ab40-0368-115e-250681e2d0d7@2mbit.com> References: <52536152-ab40-0368-115e-250681e2d0d7@2mbit.com> Message-ID: The box with NAT would be the only thing that hangs onto sessions - everything expires at 24 hours, so that would be gone through the weekend (and some work weeks). I would think it's failing to dial when I lose VZW or doesn't think it needs to and a reboot of the phone forces it to. The phone may have an IPsec tunnel lingering, I suppose. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Oct 18, 2018 at 11:41 AM, Brielle Bruns wrote: > IIRC, the Wifi calling stuff works over IPSec from the devices back to a > concentrator device. > > Are you able to look on your network firewall/router/nat device and see if > you have lingering IPSec sessions hung open, or if there's a network ALG > that might be playing a part? > > I used to have issues like this with T-Mobile and UMA. > > > > On 10/18/2018 9:28 AM, Josh Luthman wrote: > >> If someone from Verizon Wireless specifically for WiFi calling could >> reach out to me to fix our devices I would appreciate it. The WiFi calling >> works just fine when we reboot in the office, but it will never reconnect >> (ie we leave the office, get 4G, come back). I've opened 3-4 tickets with >> no resolution. >> >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> On Wed, Oct 17, 2018 at 1:13 PM, Sean Heskett > afmug at zirkel.us>> wrote: >> >> Hello, >> >> Is anyone from verizon wireless on here. clients across our network >> started complaining 2 weeks ago that wifi calling stopped working. >> below are some pings at traceroutes to wo.vzwwo.com >> which fail. the first set is with our normal >> DNS servers and the second set is using 8.8.8.8 >> >> Thanks, >> >> *Sean Heskett* >> * >> * >> *ZIRKEL Wireless * >> */High-Speed Internet/ for NW Colorado* >> 970-871-8500 x100 - Office >> 970-846-8065 - mobile >> 866-903-4628 - Fax >> Website | Facebook >> >> >> >> MBP-Sean:~ sean$ ping wo.vzwwo.com >> >> PING wo.vzwwo.com (141.207.177.233): 56 data >> bytes >> >> Request timeout for icmp_seq 0 >> >> Request timeout for icmp_seq 1 >> >> Request timeout for icmp_seq 2 >> >> Request timeout for icmp_seq 3 >> >> ^C >> >> --- wo.vzwwo.com ping statistics --- >> >> 5 packets transmitted, 0 packets received, 100.0% packet loss >> >> MBP-Sean:~ sean$ traceroute wo.vzwwo.com >> >> traceroute: Warning: wo.vzwwo.com has multiple >> addresses; using 141.207.177.233 >> >> traceroute to wo.vzwwo.com (141.207.177.233), >> 64 hops max, 52 byte packets >> >> 1 192.168.12.1 (192.168.12.1) 0.810 ms 0.586 ms 0.571 ms >> >> 2 rtr-edge-rht.zirkelwireless.com >> (65.117.208.1) 1.547 ms >> 1.640 ms 1.550 ms >> >> 3 65-117-210-178.zirkelwireless.com >> (65.117.210.178) 2.494 >> ms 2.412 ms 2.249 ms >> >> 4 72-55-193-5.mammothnetworks.com >> (72.55.193.5) 5.149 ms >> 6.783 ms 5.540 ms >> >> 5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com >> >> (38.140.187.145) 5.996 ms 5.880 ms 5.756 ms >> >> 6 be3414.ccr21.den01.atlas.cogentco.com >> (66.28.4.205) 6.072 >> ms >> >> be3415.ccr22.den01.atlas.cogentco.com >> (154.54.30.241) >> 6.252 ms >> >> be3414.ccr21.den01.atlas.cogentco.com >> (66.28.4.205) 6.203 >> ms >> >> 7 be3035.ccr21.mci01.atlas.cogentco.com >> (154.54.5.90) 17.542 >> ms >> >> be3036.ccr22.mci01.atlas.cogentco.com >> (154.54.31.90) >> 17.646 ms >> >> be3035.ccr21.mci01.atlas.cogentco.com >> (154.54.5.90) 17.038 >> ms >> >> 8 be2433.ccr32.dfw01.atlas.cogentco.com >> (154.54.3.213) >> 27.259 ms 27.265 ms >> >> be2432.ccr31.dfw01.atlas.cogentco.com >> (154.54.3.133) >> 27.198 ms >> >> 9 be2764.ccr41.dfw03.atlas.cogentco.com >> (154.54.47.214) >> 28.024 ms >> >> be2763.ccr41.dfw03.atlas.cogentco.com >> (154.54.28.74) >> 27.870 ms 27.955 ms >> >> 10 verizon.dfw03.atlas.cogentco.com >> (154.54.12.206) 27.478 >> ms 48.841 ms 40.085 ms >> >> 11 0.et-10-1-0.gw8.chi13.alter.net >> (140.222.236.209) 40.159 ms >> >> 0.et-11-3-0.gw8.chi13.alter.net >> (140.222.231.217) 39.879 ms >> >> 0.et-10-1-0.gw8.chi13.alter.net >> (140.222.236.209) 40.217 ms >> >> 12 * * * >> >> ^C >> >> MBP-Sean:~ sean$ ping wo.vzwwo.com >> >> PING wo.vzwwo.com (141.207.193.233): 56 data >> bytes >> >> Request timeout for icmp_seq 0 >> >> Request timeout for icmp_seq 1 >> >> Request timeout for icmp_seq 2 >> >> ^C >> >> --- wo.vzwwo.com ping statistics --- >> >> 4 packets transmitted, 0 packets received, 100.0% packet loss >> >> MBP-Sean:~ sean$ traceroute wo.vzwwo.com >> >> traceroute: Warning: wo.vzwwo.com has multiple >> addresses; using 141.207.193.233 >> >> traceroute to wo.vzwwo.com (141.207.193.233), >> 64 hops max, 52 byte packets >> >> 1 192.168.12.1 (192.168.12.1) 0.896 ms 0.593 ms 0.583 ms >> >> 2 rtr-edge-rht.zirkelwireless.com >> (65.117.208.1) 1.453 ms >> 1.312 ms 1.181 ms >> >> 3 65-117-210-178.zirkelwireless.com >> (65.117.210.178) 2.446 >> ms 2.061 ms 2.237 ms >> >> 4 72-55-193-5.mammothnetworks.com >> (72.55.193.5) 5.152 ms >> 5.121 ms 5.124 ms >> >> 5 be5274.rcr21.b006467-6.den01.atlas.cogentco.com >> >> (38.140.187.145) 5.716 ms 5.748 ms 5.506 ms >> >> 6 be3414.ccr21.den01.atlas.cogentco.com >> (66.28.4.205) 5.919 >> ms >> >> be3415.ccr22.den01.atlas.cogentco.com >> (154.54.30.241) >> 6.004 ms >> >> be3414.ccr21.den01.atlas.cogentco.com >> (66.28.4.205) 7.184 >> ms >> >> 7 be3035.ccr21.mci01.atlas.cogentco.com >> (154.54.5.90) 17.233 >> ms >> >> be3036.ccr22.mci01.atlas.cogentco.com >> (154.54.31.90) >> 17.397 ms >> >> be3035.ccr21.mci01.atlas.cogentco.com >> (154.54.5.90) 17.859 >> ms >> >> 8 be2433.ccr32.dfw01.atlas.cogentco.com >> (154.54.3.213) >> 27.428 ms 27.476 ms >> >> be2432.ccr31.dfw01.atlas.cogentco.com >> (154.54.3.133) >> 27.606 ms >> >> 9 be2764.ccr41.dfw03.atlas.cogentco.com >> (154.54.47.214) >> 28.129 ms >> >> be2763.ccr41.dfw03.atlas.cogentco.com >> (154.54.28.74) >> 28.009 ms 27.497 ms >> >> 10 verizon.dfw03.atlas.cogentco.com >> (154.54.12.206) 27.402 >> ms 27.451 ms 27.445 ms >> >> 11 0.et-11-3-0.gw10.dfw7.alter.net >> (140.222.228.115) 29.849 >> ms 29.039 ms >> >> 0.et-10-1-0.gw10.dfw7.alter.net >> (140.222.0.113) 29.132 ms >> >> ^C >> >> MBP-Sean:~ sean$ >> >> >> >> > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Thu Oct 18 19:03:22 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 18 Oct 2018 14:03:22 -0500 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> Message-ID: <004f01d46715$3de810e0$b9b832a0$@gvtc.com> I guess those bots have to sit somewhere. I don’t know that they would be in routers as much as they would be in Microsoft Windows… so if that’s what you meant, then I see what you mean Michael Niels, I like my cogent and telia internet connections… I just recall seeing more ddos on cogent then I did on my previous att, and current spectrum… telia is showing a good bit of ddos also Let’s put it this way, I can thank Cogent and Telia for helping my get better in my ddos mitigation skills J … there’s a bright side to everything huh Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Crapse Sent: Tuesday, October 16, 2018 8:37 PM To: NANOG list Subject: Re: Whats going on at Cogent Or he's saying that cogent has the biggest network of compromised users. Usually ipv4 only eyeball networks tend to have the most bots on net. On Tue, 16 Oct 2018 at 19:22, Niels Bakker wrote: * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: >However Cogent seems to be the dirtiest in regards to DDOS... >however Telia might be catching up... in times past when I receive >volumetric DDOS, Cogent typically ranks with the highest on my >providers ... AT&T and spectrum seem to be a bit cleaner So you're saying, Cogent and Telia have the best backbones and interconnects and thus deliver the most of your traffic to you, even at times of peak utilization? -- Niels. -------------- next part -------------- An HTML attachment was scrubbed... URL: From troy at wolvtech.com Thu Oct 18 19:11:23 2018 From: troy at wolvtech.com (Troy Mursch) Date: Thu, 18 Oct 2018 12:11:23 -0700 Subject: Whats going on at Cogent In-Reply-To: <004f01d46715$3de810e0$b9b832a0$@gvtc.com> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> <004f01d46715$3de810e0$b9b832a0$@gvtc.com> Message-ID: Cogent has done well to remediate the compromised MikroTik routers on their network. 3,000 IPv4 hosts were found on Aug. 25 ( https://twitter.com/bad_packets/status/1033256704941514752) and today, only a hundred: https://censys.io/ipv4?q=%28%28%28%22CoinHive.Anonymous%22%29+AND+%28MikroTik%29%29+AND+location.country_code%3A+US%29+AND+autonomous_system.description.raw%3A+%22COGENT-174+-+Cogent+Communications%22& __ *Troy Mursch* On Thu, Oct 18, 2018 at 12:05 PM Aaron Gould wrote: > I guess those bots have to sit somewhere. I don’t know that they would be > in routers as much as they would be in Microsoft Windows… so if that’s what > you meant, then I see what you mean Michael > > > > Niels, I like my cogent and telia internet connections… I just recall > seeing more ddos on cogent then I did on my previous att, and current > spectrum… telia is showing a good bit of ddos also > > > > Let’s put it this way, I can thank Cogent and Telia for helping my get > better in my ddos mitigation skills J … there’s a bright side to > everything huh > > > > Aaron > > > > > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Michael > Crapse > *Sent:* Tuesday, October 16, 2018 8:37 PM > *To:* NANOG list > *Subject:* Re: Whats going on at Cogent > > > > Or he's saying that cogent has the biggest network of compromised users. > Usually ipv4 only eyeball networks tend to have the most bots on net. > > > > > > On Tue, 16 Oct 2018 at 19:22, Niels Bakker wrote: > > * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: > >However Cogent seems to be the dirtiest in regards to DDOS... > >however Telia might be catching up... in times past when I receive > >volumetric DDOS, Cogent typically ranks with the highest on my > >providers ... AT&T and spectrum seem to be a bit cleaner > > So you're saying, Cogent and Telia have the best backbones and > interconnects and thus deliver the most of your traffic to you, > even at times of peak utilization? > > > -- Niels. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldumont at fibrenoire.ca Thu Oct 18 23:07:24 2018 From: ldumont at fibrenoire.ca (Laurent Dumont) Date: Thu, 18 Oct 2018 19:07:24 -0400 Subject: GTT IPVPN - Vienna - Circuit offline since maintenance. Message-ID: Hi everyone, We've have a IP-VPN circuit that has been down for the past 15 hours or so in Vienna. We are receiving the routes from the GTT BGP but we cant reach the equipment itself. GTT have confirmed a backbone issue but they have been unresponsive since. Anyone is aware of issues? Anyone from GTT can reach out off-list to figure out the status of the incident? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From hibaysal at gmail.com Fri Oct 19 12:41:38 2018 From: hibaysal at gmail.com (H I Baysal) Date: Fri, 19 Oct 2018 14:41:38 +0200 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> Message-ID: <91106287-41c7-3ba6-6922-681cf5b98193@gmail.com> Indeed, its a one time fee to setup BGP. And as a side note, I's also separate for v4 and v6 sessions. I was also taken aback when i heard it the first time. On 17-10-18 18:12, David Hubbard wrote: > > They charge it even if you’re using your own address space.  It’s a > fee simply for establishing BGP with them on a given circuit.  I > believe if you used static routes and their space, you would not have > to pay it. > > *From: *NANOG on behalf of Josh Luthman > > *Date: *Wednesday, October 17, 2018 at 12:10 PM > *To: *Brielle Bruns > *Cc: *NANOG list > *Subject: *Re: Cogent charging 50/mo for BGP (not IPs, the service) > > I view Cogent IP space as a way to lock customers to their service, ie > make them sticky. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns > wrote: > > On 10/17/2018 9:47 AM, Josh Luthman wrote: > > Has anyone else dealt with this mess?  Even my Cogent rep admits > it's > > unique to their business. > > That sounds like the BS the first company I worked for tried to pull. > > One would think they'd welcome customers bringing their own IP space > since it saves them money by not using up precious Cogent IPv4 > address > space. > > Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, > and > its available as part of the enhanced package they offer with no > extra fees. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org    / http://www.ahbl.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff+nanog at waddellsolutions.com Fri Oct 19 13:17:59 2018 From: jeff+nanog at waddellsolutions.com (Jeff Waddell) Date: Fri, 19 Oct 2018 09:17:59 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: <91106287-41c7-3ba6-6922-681cf5b98193@gmail.com> References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> <91106287-41c7-3ba6-6922-681cf5b98193@gmail.com> Message-ID: What Cogent charges is not a one time fee, its monthly recurring On Fri, Oct 19, 2018 at 8:43 AM H I Baysal wrote: > Indeed, its a one time fee to setup BGP. And as a side note, > I's also separate for v4 and v6 sessions. > > I was also taken aback when i heard it the first time. > On 17-10-18 18:12, David Hubbard wrote: > > They charge it even if you’re using your own address space. It’s a fee > simply for establishing BGP with them on a given circuit. I believe if you > used static routes and their space, you would not have to pay it. > > > > *From: *NANOG on > behalf of Josh Luthman > > *Date: *Wednesday, October 17, 2018 at 12:10 PM > *To: *Brielle Bruns > *Cc: *NANOG list > *Subject: *Re: Cogent charging 50/mo for BGP (not IPs, the service) > > > > I view Cogent IP space as a way to lock customers to their service, ie > make them sticky. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > > On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns wrote: > > On 10/17/2018 9:47 AM, Josh Luthman wrote: > > Has anyone else dealt with this mess? Even my Cogent rep admits it's > > unique to their business. > > That sounds like the BS the first company I worked for tried to pull. > > One would think they'd welcome customers bringing their own IP space > since it saves them money by not using up precious Cogent IPv4 address > space. > > Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and > its available as part of the enhanced package they offer with no extra > fees. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Fri Oct 19 14:03:18 2018 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 19 Oct 2018 10:03:18 -0400 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> <91106287-41c7-3ba6-6922-681cf5b98193@gmail.com> Message-ID: Here in the US it is unheard of. So far for every turn up I have done in Europe or Asia we were charged a separate BGP session fee. On Fri, Oct 19, 2018 at 9:17 AM, Jeff Waddell < jeff+nanog at waddellsolutions.com> wrote: > What Cogent charges is not a one time fee, its monthly recurring > > On Fri, Oct 19, 2018 at 8:43 AM H I Baysal wrote: > >> Indeed, its a one time fee to setup BGP. And as a side note, >> I's also separate for v4 and v6 sessions. >> >> I was also taken aback when i heard it the first time. >> On 17-10-18 18:12, David Hubbard wrote: >> >> They charge it even if you’re using your own address space. It’s a fee >> simply for establishing BGP with them on a given circuit. I believe if you >> used static routes and their space, you would not have to pay it. >> >> >> >> *From: *NANOG on >> behalf of Josh Luthman >> >> *Date: *Wednesday, October 17, 2018 at 12:10 PM >> *To: *Brielle Bruns >> *Cc: *NANOG list >> *Subject: *Re: Cogent charging 50/mo for BGP (not IPs, the service) >> >> >> >> I view Cogent IP space as a way to lock customers to their service, ie >> make them sticky. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> >> Suite 1337 >> Troy, OH 45373 >> >> >> >> On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns wrote: >> >> On 10/17/2018 9:47 AM, Josh Luthman wrote: >> > Has anyone else dealt with this mess? Even my Cogent rep admits it's >> > unique to their business. >> >> That sounds like the BS the first company I worked for tried to pull. >> >> One would think they'd welcome customers bringing their own IP space >> since it saves them money by not using up precious Cogent IPv4 address >> space. >> >> Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and >> its available as part of the enhanced package they offer with no extra >> fees. >> >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Quincy.Marshall at reged.com Fri Oct 19 14:57:07 2018 From: Quincy.Marshall at reged.com (Marshall, Quincy) Date: Fri, 19 Oct 2018 14:57:07 +0000 Subject: Cogent charging 50/mo for BGP (not IPs, the service) In-Reply-To: References: <257e42f3-6e63-8150-9696-690e1aa6daef@2mbit.com> <9AF05AC4-E8F5-4667-A3EB-2CB45202D3CA@dino.hostasaurus.com> <91106287-41c7-3ba6-6922-681cf5b98193@gmail.com> Message-ID: <3438B611A2B2C04495EF0E1B25729C46331C2BA4@mbx032-e1-va-8.exch032.serverpod.net> On: Friday, October 19, 2018 10:03 AM, Jeff Waddell said… Here in the US it is unheard of. So far for every turn up I have done in Europe or Asia we were charged a separate BGP session fee. Not unheard of… requested several new quotes in the last few months and at least 2 included $50/mo charge for BGP. LQ. Marshall | Sr. Network Engineer | RegEd --------------------------------------------------------------------------------------- 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 cscora at apnic.net Fri Oct 19 18:03:13 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Oct 2018 04:03:13 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181019180313.74B10C450F@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 20 Oct, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 720932 Prefixes after maximum aggregation (per Origin AS): 277736 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 346559 Total ASes present in the Internet Routing Table: 62172 Prefixes per ASN: 11.60 Origin-only ASes present in the Internet Routing Table: 53659 Origin ASes announcing only one prefix: 23351 Transit ASes present in the Internet Routing Table: 8513 Transit-only ASes present in the Internet Routing Table: 258 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 45 Number of instances of unregistered ASNs: 45 Number of 32-bit ASNs allocated by the RIRs: 24512 Number of 32-bit ASNs visible in the Routing Table: 19802 Prefixes from 32-bit ASNs in the Routing Table: 83276 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 265 Number of addresses announced to Internet: 2855841539 Equivalent to 170 /8s, 56 /16s and 175 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 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: 240937 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 196031 Total APNIC prefixes after maximum aggregation: 55976 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 193756 Unique aggregates announced from the APNIC address blocks: 80180 APNIC Region origin ASes present in the Internet Routing Table: 9173 APNIC Prefixes per ASN: 21.12 APNIC Region origin ASes announcing only one prefix: 2566 APNIC Region transit ASes present in the Internet Routing Table: 1366 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4141 Number of APNIC addresses announced to Internet: 767770050 Equivalent to 45 /8s, 195 /16s and 61 /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: 214759 Total ARIN prefixes after maximum aggregation: 101898 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 214148 Unique aggregates announced from the ARIN address blocks: 101956 ARIN Region origin ASes present in the Internet Routing Table: 18276 ARIN Prefixes per ASN: 11.72 ARIN Region origin ASes announcing only one prefix: 6787 ARIN Region transit ASes present in the Internet Routing Table: 1819 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2468 Number of ARIN addresses announced to Internet: 1098652576 Equivalent to 65 /8s, 124 /16s and 27 /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: 197098 Total RIPE prefixes after maximum aggregation: 94122 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 193556 Unique aggregates announced from the RIPE address blocks: 114401 RIPE Region origin ASes present in the Internet Routing Table: 25565 RIPE Prefixes per ASN: 7.57 RIPE Region origin ASes announcing only one prefix: 11475 RIPE Region transit ASes present in the Internet Routing Table: 3540 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7497 Number of RIPE addresses announced to Internet: 714892672 Equivalent to 42 /8s, 156 /16s and 101 /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: 93394 Total LACNIC prefixes after maximum aggregation: 21481 LACNIC Deaggregation factor: 4.35 Prefixes being announced from the LACNIC address blocks: 94805 Unique aggregates announced from the LACNIC address blocks: 41433 LACNIC Region origin ASes present in the Internet Routing Table: 7667 LACNIC Prefixes per ASN: 12.37 LACNIC Region origin ASes announcing only one prefix: 2118 LACNIC Region transit ASes present in the Internet Routing Table: 1445 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5216 Number of LACNIC addresses announced to Internet: 172298784 Equivalent to 10 /8s, 69 /16s and 18 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19604 Total AfriNIC prefixes after maximum aggregation: 4219 AfriNIC Deaggregation factor: 4.65 Prefixes being announced from the AfriNIC address blocks: 24402 Unique aggregates announced from the AfriNIC address blocks: 8345 AfriNIC Region origin ASes present in the Internet Routing Table: 1207 AfriNIC Prefixes per ASN: 20.22 AfriNIC Region origin ASes announcing only one prefix: 405 AfriNIC Region transit ASes present in the Internet Routing Table: 243 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 480 Number of AfriNIC addresses announced to Internet: 101797120 Equivalent to 6 /8s, 17 /16s and 77 /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 4638 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4471 496 489 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2985 1153 93 VIETEL-AS-AP Viettel Group, VN 45899 2839 1674 159 VNPT-AS-VN VNPT Corp, VN 4766 2809 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2734 1495 548 BSNL-NIB National Internet Backbone, IN 9394 2503 4907 31 CTTNET China TieTong Telecommunications 9808 2252 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2240 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2133 422 172 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 11492 3495 226 581 CABLEONE - CABLE ONE, INC., US 6327 3454 1324 84 SHAW - Shaw Communications Inc., CA 22773 3268 2971 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2325 5005 834 AMAZON-02 - Amazon.com, Inc., US 18566 2156 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2148 2737 515 CHARTER-NET-HKY-NC - Charter Communicat 5650 2085 3074 1461 FRONTIER-FRTR - Frontier Communications 16625 2081 1118 1555 AKAMAI-AS - Akamai Technologies, Inc., 209 2036 5079 594 CENTURYLINK-US-LEGACY-QWEST - CenturyLi 30036 2033 343 228 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 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 4996 1616 132 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3045 378 50 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2569 578 1913 AKAMAI-ASN1, US 12389 2119 2067 686 ROSTELECOM-AS, RU 34984 2030 336 527 TELLCOM-AS, TR 9121 1862 1691 17 TTNET, TR 13188 1604 100 45 TRIOLAN, UA 8402 1284 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA 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 5424 3305 609 Uninet S.A. de C.V., MX 10620 3199 490 804 Telmex Colombia S.A., CO 11830 2661 370 83 Instituto Costarricense de Electricidad 6503 1651 449 55 Axtel, S.A.B. de C.V., MX 7303 1432 956 206 Telecom Argentina S.A., AR 6147 1092 377 29 Telefonica del Peru S.A.A., PE 28573 1083 2234 192 CLARO S.A., BR 3816 1025 508 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 937 145 72 Alestra, S. de R.L. de C.V., MX 18881 919 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 949 395 41 LINKdotNET-AS, EG 37611 902 107 9 Afrihost, ZA 36903 794 399 146 MT-MPLS, MA 36992 753 1411 41 ETISALAT-MISR, EG 24835 682 758 20 RAYA-AS, EG 8452 612 1728 15 TE-AS TE-AS, EG 29571 462 70 12 ORANGE-COTE-IVOIRE, CI 37492 440 467 62 ORANGE-, TN 23889 394 231 15 MauritiusTelecom, MU 37342 394 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 5424 3305 609 Uninet S.A. de C.V., MX 12479 4996 1616 132 UNI2-AS, ES 4538 4638 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4471 496 489 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3495 226 581 CABLEONE - CABLE ONE, INC., US 6327 3454 1324 84 SHAW - Shaw Communications Inc., CA 22773 3268 2971 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3199 490 804 Telmex Colombia S.A., CO 8551 3045 378 50 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 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 4996 4864 UNI2-AS, ES 4538 4638 4564 ERX-CERNET-BKB China Education and Research Net 7545 4471 3982 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3454 3370 SHAW - Shaw Communications Inc., CA 22773 3268 3107 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3045 2995 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3495 2914 CABLEONE - CABLE ONE, INC., US 7552 2985 2892 VIETEL-AS-AP Viettel Group, VN 45899 2839 2680 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 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65551 DOCUMENT 103.112.64.0/23 58889 ZOL-BD Zx Online Ltd, BD 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 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.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 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 64.28.160.0/20 20475 AS20475 - Global Capacity, LLC, US 64.29.240.0/20 27279 -Reserved AS-, ZZ 64.30.152.0/24 15830 TELECITY-LON, GB 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:14 /9:11 /10:36 /11:98 /12:289 /13:566 /14:1105 /15:1889 /16:13326 /17:7890 /18:13785 /19:25401 /20:39569 /21:45929 /22:89486 /23:73423 /24:405894 /25:822 /26:625 /27:639 /28:36 /29:21 /30:22 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3779 4996 UNI2-AS, ES 6327 3239 3454 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2764 3495 CABLEONE - CABLE ONE, INC., US 22773 2527 3268 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2501 3045 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2050 2156 MEGAPATH5-US - MegaPath Corporation, US 11830 2011 2661 Instituto Costarricense de Electricidad y Telec 30036 1781 2033 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1762 2085 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:892 4:18 5:2676 6:43 7:1 8:1142 12:1869 13:222 14:1848 15:33 16:3 17:192 18:58 20:50 23:2471 24:2434 25:2 27:2512 31:2013 32:84 35:30 36:546 37:2918 38:1560 39:262 40:122 41:3179 42:717 43:1959 44:126 45:5808 46:3112 47:222 49:1352 50:1062 51:318 52:1089 54:361 55:1 56:12 57:38 58:1608 59:985 60:417 61:2084 62:1954 63:1805 64:5053 65:2204 66:4817 67:2665 68:1156 69:3345 70:1166 71:590 72:2245 74:2730 75:416 76:458 77:1658 78:1746 79:2226 80:1584 81:1422 82:1052 83:787 84:1048 85:2063 86:568 87:1468 88:942 89:2368 90:215 91:6446 92:1272 93:2392 94:2451 95:3026 96:924 97:353 98:944 99:145 100:86 101:1174 102:252 103:18935 104:3569 105:235 106:769 107:1831 108:710 109:3375 110:1658 111:1815 112:1329 113:1306 114:1143 115:1681 116:1660 117:1802 118:2192 119:1666 120:1083 121:1036 122:2319 123:1664 124:1451 125:1939 128:1206 129:689 130:503 131:1616 132:723 133:191 134:1036 135:237 136:527 137:658 138:1961 139:695 140:553 141:752 142:840 143:988 144:851 145:496 146:1249 147:769 148:1665 149:775 150:763 151:991 152:871 153:325 154:1882 155:941 156:1533 157:813 158:660 159:1867 160:1494 161:852 162:2650 163:735 164:1092 165:1565 166:454 167:1288 168:3138 169:859 170:3982 171:495 172:1040 173:2077 174:997 175:817 176:2107 177:3980 178:2507 179:1305 180:2122 181:2430 182:2596 183:1303 184:1135 185:14239 186:3591 187:2449 188:2930 189:2010 190:8269 191:1361 192:9864 193:6304 194:5153 195:4047 196:2838 197:1618 198:5692 199:5954 200:7407 201:5017 202:10249 203:10199 204:4612 205:2982 206:3217 207:3196 208:3931 209:4160 210:3834 211:1985 212:2983 213:2800 214:1041 215:54 216:6022 217:2181 218:866 219:575 220:1812 221:992 222:967 223:1400 End of report From aaron1 at gvtc.com Fri Oct 19 21:47:51 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 19 Oct 2018 16:47:51 -0500 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> <004f01d46715$3de810e0$b9b832a0$@gvtc.com> Message-ID: <3C6C9429-E5C3-45D4-B7F8-27983570315F@gvtc.com> Yes I noticed that last week, it is very slow Aaron > On Oct 19, 2018, at 4:43 PM, Ryan Gelobter wrote: > > Has anyone else noticed their ecogent portal is super fucking slow? Back in the day it used to be fast > >> On Thu, Oct 18, 2018 at 2:12 PM Troy Mursch wrote: >> Cogent has done well to remediate the compromised MikroTik routers on their network. 3,000 IPv4 hosts were found on Aug. 25 (https://twitter.com/bad_packets/status/1033256704941514752) and today, only a hundred: https://censys.io/ipv4?q=%28%28%28%22CoinHive.Anonymous%22%29+AND+%28MikroTik%29%29+AND+location.country_code%3A+US%29+AND+autonomous_system.description.raw%3A+%22COGENT-174+-+Cogent+Communications%22& >> __ >> >> Troy Mursch >> >> >> >>> On Thu, Oct 18, 2018 at 12:05 PM Aaron Gould wrote: >>> I guess those bots have to sit somewhere. I don’t know that they would be in routers as much as they would be in Microsoft Windows… so if that’s what you meant, then I see what you mean Michael >>> >>> >>> >>> Niels, I like my cogent and telia internet connections… I just recall seeing more ddos on cogent then I did on my previous att, and current spectrum… telia is showing a good bit of ddos also >>> >>> >>> >>> Let’s put it this way, I can thank Cogent and Telia for helping my get better in my ddos mitigation skills J … there’s a bright side to everything huh >>> >>> >>> >>> Aaron >>> >>> >>> >>> >>> >>> >>> >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Crapse >>> Sent: Tuesday, October 16, 2018 8:37 PM >>> To: NANOG list >>> Subject: Re: Whats going on at Cogent >>> >>> >>> >>> Or he's saying that cogent has the biggest network of compromised users. Usually ipv4 only eyeball networks tend to have the most bots on net. >>> >>> >>> >>> >>> >>> On Tue, 16 Oct 2018 at 19:22, Niels Bakker wrote: >>> >>> * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: >>> >However Cogent seems to be the dirtiest in regards to DDOS... >>> >however Telia might be catching up... in times past when I receive >>> >volumetric DDOS, Cogent typically ranks with the highest on my >>> >providers ... AT&T and spectrum seem to be a bit cleaner >>> >>> So you're saying, Cogent and Telia have the best backbones and >>> interconnects and thus deliver the most of your traffic to you, >>> even at times of peak utilization? >>> >>> >>> -- Niels. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at unlimitednet.us Sat Oct 20 02:54:29 2018 From: jason at unlimitednet.us (Jason Canady) Date: Fri, 19 Oct 2018 22:54:29 -0400 Subject: Whats going on at Cogent In-Reply-To: <3C6C9429-E5C3-45D4-B7F8-27983570315F@gvtc.com> References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> <004f01d46715$3de810e0$b9b832a0$@gvtc.com> <3C6C9429-E5C3-45D4-B7F8-27983570315F@gvtc.com> Message-ID: It's been slow for quite some time now. I only find it useful for billing purposes.  It's a shame carriers don't have a good ticket system. Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure On 10/19/18 5:47 PM, Aaron1 wrote: > Yes I noticed that last week, it is very slow > > Aaron > > On Oct 19, 2018, at 4:43 PM, Ryan Gelobter > > wrote: > >> Has anyone else noticed their ecogent portal is super fucking slow? >> Back in the day it used to be fast >> >> On Thu, Oct 18, 2018 at 2:12 PM Troy Mursch > > wrote: >> >> Cogent has done well to remediate the compromised MikroTik >> routers on their network. 3,000 IPv4 hosts were found on Aug. 25 >> (https://twitter.com/bad_packets/status/1033256704941514752) and >> today, only a hundred: >> https://censys.io/ipv4?q=%28%28%28%22CoinHive.Anonymous%22%29+AND+%28MikroTik%29%29+AND+location.country_code%3A+US%29+AND+autonomous_system.description.raw%3A+%22COGENT-174+-+Cogent+Communications%22& >> >> __ >> >> *Troy Mursch* >> >> >> >> On Thu, Oct 18, 2018 at 12:05 PM Aaron Gould > > wrote: >> >> I guess those bots have to sit somewhere.  I don’t know that >> they would be in routers as much as they would be in >> Microsoft Windows… so if that’s what you meant, then I see >> what you mean Michael >> >> Niels, I like my cogent and telia internet connections… I >> just recall seeing more ddos on cogent then I did on my >> previous att, and current spectrum… telia is showing a good >> bit of ddos also >> >> Let’s put it this way, I can thank Cogent and Telia for >> helping my get better in my ddos mitigation skills ☺… there’s >> a bright side to everything huh >> >> Aaron >> >> *From:*NANOG [mailto:nanog-bounces at nanog.org >> ] *On Behalf Of *Michael Crapse >> *Sent:* Tuesday, October 16, 2018 8:37 PM >> *To:* NANOG list >> *Subject:* Re: Whats going on at Cogent >> >> Or he's saying that cogent has the biggest network of >> compromised users. Usually ipv4 only eyeball networks tend to >> have the most bots on net. >> >> On Tue, 16 Oct 2018 at 19:22, Niels Bakker >> > wrote: >> >> * aaron1 at gvtc.com (Aaron1) [Wed >> 17 Oct 2018, 00:17 CEST]: >> >However Cogent seems to be the dirtiest in regards to >> DDOS... >> >however Telia might be catching up... in times past when >> I receive >> >volumetric DDOS, Cogent typically ranks with the highest >> on my >> >providers ... AT&T and spectrum seem to be a bit cleaner >> >> So you're saying, Cogent and Telia have the best >> backbones and >> interconnects and thus deliver the most of your traffic >> to you, >> even at times of peak utilization? >> >> >>         -- Niels. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Sat Oct 20 03:13:39 2018 From: aaron1 at gvtc.com (Aaron1) Date: Fri, 19 Oct 2018 22:13:39 -0500 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> <004f01d46715$3de810e0$b9b832a0$@gvtc.com> <3C6C9429-E5C3-45D4-B7F8-27983570315F@gvtc.com> Message-ID: ecogent looking glass tools are helpful Aaron > On Oct 19, 2018, at 9:54 PM, Jason Canady wrote: > > It's been slow for quite some time now. I only find it useful for billing purposes. It's a shame carriers don't have a good ticket system. > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure >> On 10/19/18 5:47 PM, Aaron1 wrote: >> Yes I noticed that last week, it is very slow >> >> Aaron >> >> On Oct 19, 2018, at 4:43 PM, Ryan Gelobter wrote: >> >>> Has anyone else noticed their ecogent portal is super fucking slow? Back in the day it used to be fast >>> >>>> On Thu, Oct 18, 2018 at 2:12 PM Troy Mursch wrote: >>>> Cogent has done well to remediate the compromised MikroTik routers on their network. 3,000 IPv4 hosts were found on Aug. 25 (https://twitter.com/bad_packets/status/1033256704941514752) and today, only a hundred: https://censys.io/ipv4?q=%28%28%28%22CoinHive.Anonymous%22%29+AND+%28MikroTik%29%29+AND+location.country_code%3A+US%29+AND+autonomous_system.description.raw%3A+%22COGENT-174+-+Cogent+Communications%22& >>>> __ >>>> >>>> Troy Mursch >>>> >>>> >>>> >>>>> On Thu, Oct 18, 2018 at 12:05 PM Aaron Gould wrote: >>>>> I guess those bots have to sit somewhere. I don’t know that they would be in routers as much as they would be in Microsoft Windows… so if that’s what you meant, then I see what you mean Michael >>>>> >>>>> >>>>> >>>>> Niels, I like my cogent and telia internet connections… I just recall seeing more ddos on cogent then I did on my previous att, and current spectrum… telia is showing a good bit of ddos also >>>>> >>>>> >>>>> >>>>> Let’s put it this way, I can thank Cogent and Telia for helping my get better in my ddos mitigation skills ☺ … there’s a bright side to everything huh >>>>> >>>>> >>>>> >>>>> Aaron >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Crapse >>>>> Sent: Tuesday, October 16, 2018 8:37 PM >>>>> To: NANOG list >>>>> Subject: Re: Whats going on at Cogent >>>>> >>>>> >>>>> >>>>> Or he's saying that cogent has the biggest network of compromised users. Usually ipv4 only eyeball networks tend to have the most bots on net. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, 16 Oct 2018 at 19:22, Niels Bakker wrote: >>>>> >>>>> * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: >>>>> >However Cogent seems to be the dirtiest in regards to DDOS... >>>>> >however Telia might be catching up... in times past when I receive >>>>> >volumetric DDOS, Cogent typically ranks with the highest on my >>>>> >providers ... AT&T and spectrum seem to be a bit cleaner >>>>> >>>>> So you're saying, Cogent and Telia have the best backbones and >>>>> interconnects and thus deliver the most of your traffic to you, >>>>> even at times of peak utilization? >>>>> >>>>> >>>>> -- Niels. >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Sun Oct 21 08:20:12 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 21 Oct 2018 10:20:12 +0200 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> Message-ID: Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps peak from our HE link and 336 Mbps peak from our Cogent link. This is inbound traffic. We are eyeballs and our outbound is a small fraction of our inbound. Regards. Baldur On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: > We have been very happy with HE. It was a no brainer over cogent. They are > smaller (so are we). When there are issues they are real fast to fix them, > you also get the personal touch which you don't get with others. > > > On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas > wrote: > >> I don't really get the Cogent/Google peering issues. I've been hearing >> this for years... How about fixing it already? Telling customer to get >> other transit providers to get to a given network is really bad. >> >> On a side note, HE is still HE but they're trying really hard to be a >> good netcitizen. They've finally pushed filtering for peers: >> http://routing.he.net. I wouldn't get transit from them, but in some >> markets, they're the only affordable IP transit providers. >> >> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >> >> >> >> When I call and mention it I’m told that it’s HE’s fault (despite the >> lovely cake), but when I also bring Google, then they tell me to get a >> different provider just for this traffic, or meet them at an IX and send my >> traffic from there. >> >> About the staff rotation I’ve seen it too, and I’ve also seen an increase >> in salespeople calling, for example when an AS is registered etc. in >> addition to the normal calls.. >> >> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >> >> They call me every few months. the last time they emailed me I said I >> wasn't interested because of the HE issue. I have yet to get another >> email....... >> >> >> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >> >> >> >> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >> dhubbard at dino.hostasaurus.com> wrote: >> >> Have had the same sales rep for several years now; unfortunately he has >> no ability to fix their IPv6 peering issue so we’re slowly removing >> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >> stable. >> >> >> >> >> Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing >> HE and Google ipv6 traffic, which is what they do if i use a default route >> from them, is dead on arrival. Shows they make bad decisions and dont put >> the customer first, or even create such an illusion. >> >> >> >> >> *From: *NANOG on behalf of Ryan Gelobter < >> ryan.g at atwgpc.net> >> *Date: *Tuesday, October 16, 2018 at 6:04 AM >> *To: *NANOG >> *Subject: *Whats going on at Cogent >> >> Anyone else seen terrible support and high turnover of sales/account >> people at Cogent the last few months? Is there something going on over >> there internally? I'm sure some people will say Cogent has always been crap >> but in the past their account reps and support were pretty good. It seems >> to have gone downhill the last 12 months really bad. >> >> Regards, >> Ryan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Oct 21 12:39:44 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 21 Oct 2018 07:39:44 -0500 (CDT) Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> Message-ID: <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> I guess first thing's first... you aren't doing anything to force the traffic that way, are you? If you've got IPv6 deployed, chances are that no Google will be coming over that Cogent. :-) CAIDA says Cogent is bigger. http://as-rank.caida.org/asns/174/as-core http://as-rank.caida.org/asns/6939/as-core Being an eyeball network, what's going to impact that kind of usage the most is where the next up connections to Netflix, Google, Akamai, Cloudflare, etc. are located. If they're closer via HE than Cogent, that's where your traffic will come from. Looking at your network specifically, Netflix isn't on either IX that you're on, so that HE traffic very well could be a majority Netflix. What do your netflows say? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Sunday, October 21, 2018 3:20:12 AM Subject: Re: Whats going on at Cogent Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps peak from our HE link and 336 Mbps peak from our Cogent link. This is inbound traffic. We are eyeballs and our outbound is a small fraction of our inbound. Regards. Baldur On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender < dovid at telecurve.com > wrote: We have been very happy with HE. It was a no brainer over cogent. They are smaller (so are we). When there are issues they are real fast to fix them, you also get the personal touch which you don't get with others. On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas < edugas at unknowndevice.ca > wrote:
I don't really get the Cogent/Google peering issues. I've been hearing this for years... How about fixing it already? Telling customer to get other transit providers to get to a given network is really bad. On a side note, HE is still HE but they're trying really hard to be a good netcitizen. They've finally pushed filtering for peers: http://routing.he.net . I wouldn't get transit from them, but in some markets, they're the only affordable IP transit providers. On Oct 16 2018, at 10:04 am, DaKnOb < daknob.mac at gmail.com > wrote:
When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. On 16 Oct 2018, at 16:54, Dovid Bender < dovid at telecurve.com > wrote:
They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... On Tue, Oct 16, 2018 at 9:29 AM, Ca By < cb.list6 at gmail.com > wrote:
On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < dhubbard at dino.hostasaurus.com > wrote:
Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion.
From: NANOG < nanog-bounces at nanog.org > on behalf of Ryan Gelobter < ryan.g at atwgpc.net > Date: Tuesday, October 16, 2018 at 6:04 AM To: NANOG < nanog at nanog.org > Subject: Whats going on at Cogent Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan
-------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Sun Oct 21 15:45:58 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Sun, 21 Oct 2018 11:45:58 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <16DE7B02-8203-4A58-A702-1279CB643742@dino.hostasaurus.com> <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <5DC6BEB1-0CC1-46A5-831D-A0B49CB61F08@hammerfiber.com> <1888176954.506.1539709704202.JavaMail.mhammett@ThunderFuck> <20181017012025.GB7993@jima.tpb.net> <004f01d46715$3de810e0$b9b832a0$@gvtc.com> <3C6C9429-E5C3-45D4-B7F8-27983570315F@gvtc.com> Message-ID: Portal takes a good long time for me to log in (I just got a circuit in the last week) but after ~30 seconds to log in, it seems pretty responsive. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Oct 19, 2018 at 10:54 PM, Jason Canady wrote: > It's been slow for quite some time now. I only find it useful for billing > purposes. It's a shame carriers don't have a good ticket system. > > Jason Canady > Unlimited Net, LLC > Responsive, Reliable, Secure > > On 10/19/18 5:47 PM, Aaron1 wrote: > > Yes I noticed that last week, it is very slow > > Aaron > > On Oct 19, 2018, at 4:43 PM, Ryan Gelobter > wrote: > > Has anyone else noticed their ecogent portal is super fucking slow? Back > in the day it used to be fast > > On Thu, Oct 18, 2018 at 2:12 PM Troy Mursch wrote: > >> Cogent has done well to remediate the compromised MikroTik routers on >> their network. 3,000 IPv4 hosts were found on Aug. 25 ( >> https://twitter.com/bad_packets/status/1033256704941514752) and today, >> only a hundred: https://censys.io/ipv4?q=%28%28%28%22CoinHive. >> Anonymous%22%29+AND+%28MikroTik%29%29+AND+location. >> country_code%3A+US%29+AND+autonomous_system.description. >> raw%3A+%22COGENT-174+-+Cogent+Communications%22& >> >> __ >> >> *Troy Mursch* >> >> >> On Thu, Oct 18, 2018 at 12:05 PM Aaron Gould wrote: >> >>> I guess those bots have to sit somewhere. I don’t know that they would >>> be in routers as much as they would be in Microsoft Windows… so if that’s >>> what you meant, then I see what you mean Michael >>> >>> >>> >>> Niels, I like my cogent and telia internet connections… I just recall >>> seeing more ddos on cogent then I did on my previous att, and current >>> spectrum… telia is showing a good bit of ddos also >>> >>> >>> >>> Let’s put it this way, I can thank Cogent and Telia for helping my get >>> better in my ddos mitigation skills ☺ … there’s a bright side to >>> everything huh >>> >>> >>> >>> Aaron >>> >>> >>> >>> >>> >>> >>> >>> *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Michael >>> Crapse >>> *Sent:* Tuesday, October 16, 2018 8:37 PM >>> *To:* NANOG list >>> *Subject:* Re: Whats going on at Cogent >>> >>> >>> >>> Or he's saying that cogent has the biggest network of compromised users. >>> Usually ipv4 only eyeball networks tend to have the most bots on net. >>> >>> >>> >>> >>> >>> On Tue, 16 Oct 2018 at 19:22, Niels Bakker >>> wrote: >>> >>> * aaron1 at gvtc.com (Aaron1) [Wed 17 Oct 2018, 00:17 CEST]: >>> >However Cogent seems to be the dirtiest in regards to DDOS... >>> >however Telia might be catching up... in times past when I receive >>> >volumetric DDOS, Cogent typically ranks with the highest on my >>> >providers ... AT&T and spectrum seem to be a bit cleaner >>> >>> So you're saying, Cogent and Telia have the best backbones and >>> interconnects and thus deliver the most of your traffic to you, >>> even at times of peak utilization? >>> >>> >>> -- Niels. >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Sun Oct 21 16:51:53 2018 From: aaron1 at gvtc.com (Aaron1) Date: Sun, 21 Oct 2018 11:51:53 -0500 Subject: Whats going on at Cogent In-Reply-To: <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: If he only uses a default route then his outbound routing won’t have anything to do with what destinations are closer, etc Aaron > On Oct 21, 2018, at 7:39 AM, Mike Hammett wrote: > > I guess first thing's first... you aren't doing anything to force the traffic that way, are you? > > If you've got IPv6 deployed, chances are that no Google will be coming over that Cogent. :-) > > CAIDA says Cogent is bigger. > > http://as-rank.caida.org/asns/174/as-core > http://as-rank.caida.org/asns/6939/as-core > > Being an eyeball network, what's going to impact that kind of usage the most is where the next up connections to Netflix, Google, Akamai, Cloudflare, etc. are located. If they're closer via HE than Cogent, that's where your traffic will come from. > > Looking at your network specifically, Netflix isn't on either IX that you're on, so that HE traffic very well could be a majority Netflix. > > What do your netflows say? > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Sunday, October 21, 2018 3:20:12 AM > Subject: Re: Whats going on at Cogent > > Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps peak from our HE link and 336 Mbps peak from our Cogent link. This is inbound traffic. We are eyeballs and our outbound is a small fraction of our inbound. > > Regards. > > Baldur > > >> On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: >> We have been very happy with HE. It was a no brainer over cogent. They are smaller (so are we). When there are issues they are real fast to fix them, you also get the personal touch which you don't get with others. >> >> >>> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas wrote: >>> I don't really get the Cogent/Google peering issues. I've been hearing this for years... How about fixing it already? Telling customer to get other transit providers to get to a given network is really bad. >>> >>> On a side note, HE is still HE but they're trying really hard to be a good netcitizen. They've finally pushed filtering for peers: http://routing.he.net. I wouldn't get transit from them, but in some markets, they're the only affordable IP transit providers. >>> >>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>> >>> >>> When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. >>> >>> About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. >>> >>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>> >>> They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... >>> >>> >>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>> >>> >>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard wrote: >>> Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. >>> >>> >>> >>> Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. >>> >>> >>> >>> >>> From: NANOG on behalf of Ryan Gelobter >>> Date: Tuesday, October 16, 2018 at 6:04 AM >>> To: NANOG >>> Subject: Whats going on at Cogent >>> >>> Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. >>> >>> Regards, >>> Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sun Oct 21 17:19:09 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 21 Oct 2018 12:19:09 -0500 (CDT) Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: <1765602334.4558.1540142345437.JavaMail.mhammett@ThunderFuck> I didn't explicitly refer to outbound routing in my post, but maybe this is a tangent. The outbound routing is a major factor in CDNs like Cloudflare that are anycasted and serve from the same node the request is received on. For other CDNs, your outbound routing strategy will have a lesser impact. I intentionally didn't get technical with my response because "closer" could mean many things, depending on routing configurations, IX connections, CDN magic sauce, etc. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Aaron1" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Sunday, October 21, 2018 11:51:53 AM Subject: Re: Whats going on at Cogent If he only uses a default route then his outbound routing won’t have anything to do with what destinations are closer, etc Aaron On Oct 21, 2018, at 7:39 AM, Mike Hammett < nanog at ics-il.net > wrote: I guess first thing's first... you aren't doing anything to force the traffic that way, are you? If you've got IPv6 deployed, chances are that no Google will be coming over that Cogent. :-) CAIDA says Cogent is bigger. http://as-rank.caida.org/asns/174/as-core http://as-rank.caida.org/asns/6939/as-core Being an eyeball network, what's going to impact that kind of usage the most is where the next up connections to Netflix, Google, Akamai, Cloudflare, etc. are located. If they're closer via HE than Cogent, that's where your traffic will come from. Looking at your network specifically, Netflix isn't on either IX that you're on, so that HE traffic very well could be a majority Netflix. What do your netflows say? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Baldur Norddahl" < baldur.norddahl at gmail.com > To: nanog at nanog.org Sent: Sunday, October 21, 2018 3:20:12 AM Subject: Re: Whats going on at Cogent Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps peak from our HE link and 336 Mbps peak from our Cogent link. This is inbound traffic. We are eyeballs and our outbound is a small fraction of our inbound. Regards. Baldur On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender < dovid at telecurve.com > wrote:
We have been very happy with HE. It was a no brainer over cogent. They are smaller (so are we). When there are issues they are real fast to fix them, you also get the personal touch which you don't get with others. On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas < edugas at unknowndevice.ca > wrote:
I don't really get the Cogent/Google peering issues. I've been hearing this for years... How about fixing it already? Telling customer to get other transit providers to get to a given network is really bad. On a side note, HE is still HE but they're trying really hard to be a good netcitizen. They've finally pushed filtering for peers: http://routing.he.net . I wouldn't get transit from them, but in some markets, they're the only affordable IP transit providers. On Oct 16 2018, at 10:04 am, DaKnOb < daknob.mac at gmail.com > wrote:
When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. On 16 Oct 2018, at 16:54, Dovid Bender < dovid at telecurve.com > wrote:
They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... On Tue, Oct 16, 2018 at 9:29 AM, Ca By < cb.list6 at gmail.com > wrote:
On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < dhubbard at dino.hostasaurus.com > wrote:
Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion.
From: NANOG < nanog-bounces at nanog.org > on behalf of Ryan Gelobter < ryan.g at atwgpc.net > Date: Tuesday, October 16, 2018 at 6:04 AM To: NANOG < nanog at nanog.org > Subject: Whats going on at Cogent Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. Regards, Ryan
-------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Mon Oct 22 02:33:31 2018 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 21 Oct 2018 22:33:31 -0400 Subject: Whats going on at Cogent In-Reply-To: <1765602334.4558.1540142345437.JavaMail.mhammett@ThunderFuck> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <1765602334.4558.1540142345437.JavaMail.mhammett@ThunderFuck> Message-ID: Bear in mind that many orgs will prefer their cheapest link for outbound, and I'm pretty sure HE is cheaper than Cogent. Someone else's outbound traffic going through HE means your inbound traffic coming through HE. On Sun, Oct 21, 2018 at 1:19 PM, Mike Hammett wrote: > I didn't explicitly refer to outbound routing in my post, but maybe this > is a tangent. > > > The outbound routing is a major factor in CDNs like Cloudflare that are > anycasted and serve from the same node the request is received on. For > other CDNs, your outbound routing strategy will have a lesser impact. > > > I intentionally didn't get technical with my response because "closer" > could mean many things, depending on routing configurations, IX > connections, CDN magic sauce, etc. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Aaron1" > *To: *"Mike Hammett" > *Cc: *nanog at nanog.org > *Sent: *Sunday, October 21, 2018 11:51:53 AM > > *Subject: *Re: Whats going on at Cogent > > If he only uses a default route then his outbound routing won’t have > anything to do with what destinations are closer, etc > > Aaron > > On Oct 21, 2018, at 7:39 AM, Mike Hammett wrote: > > I guess first thing's first... you aren't doing anything to force the > traffic that way, are you? > > If you've got IPv6 deployed, chances are that no Google will be coming > over that Cogent. :-) > > CAIDA says Cogent is bigger. > > http://as-rank.caida.org/asns/174/as-core > http://as-rank.caida.org/asns/6939/as-core > > Being an eyeball network, what's going to impact that kind of usage the > most is where the next up connections to Netflix, Google, Akamai, > Cloudflare, etc. are located. If they're closer via HE than Cogent, that's > where your traffic will come from. > > Looking at your network specifically, Netflix isn't on either IX that > you're on, so that HE traffic very well could be a majority Netflix. > > What do your netflows say? > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Baldur Norddahl" > *To: *nanog at nanog.org > *Sent: *Sunday, October 21, 2018 3:20:12 AM > *Subject: *Re: Whats going on at Cogent > > Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps > peak from our HE link and 336 Mbps peak from our Cogent link. This is > inbound traffic. We are eyeballs and our outbound is a small fraction of > our inbound. > > Regards. > > Baldur > > > On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: > >> We have been very happy with HE. It was a no brainer over cogent. They >> are smaller (so are we). When there are issues they are real fast to fix >> them, you also get the personal touch which you don't get with others. >> >> >> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas >> wrote: >> >>> I don't really get the Cogent/Google peering issues. I've been hearing >>> this for years... How about fixing it already? Telling customer to get >>> other transit providers to get to a given network is really bad. >>> >>> On a side note, HE is still HE but they're trying really hard to be a >>> good netcitizen. They've finally pushed filtering for peers: >>> http://routing.he.net. I wouldn't get transit from them, but in some >>> markets, they're the only affordable IP transit providers. >>> >>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>> >>> >>> >>> When I call and mention it I’m told that it’s HE’s fault (despite the >>> lovely cake), but when I also bring Google, then they tell me to get a >>> different provider just for this traffic, or meet them at an IX and send my >>> traffic from there. >>> >>> About the staff rotation I’ve seen it too, and I’ve also seen an >>> increase in salespeople calling, for example when an AS is registered etc. >>> in addition to the normal calls.. >>> >>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>> >>> They call me every few months. the last time they emailed me I said I >>> wasn't interested because of the HE issue. I have yet to get another >>> email....... >>> >>> >>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>> >>> >>> >>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >>> dhubbard at dino.hostasaurus.com> wrote: >>> >>> Have had the same sales rep for several years now; unfortunately he has >>> no ability to fix their IPv6 peering issue so we’re slowly removing >>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>> stable. >>> >>> >>> >>> >>> Yep, this. Whenever Cogent calls, this is what i tell them. >>> Black-holing HE and Google ipv6 traffic, which is what they do if i use a >>> default route from them, is dead on arrival. Shows they make bad decisions >>> and dont put the customer first, or even create such an illusion. >>> >>> >>> >>> >>> *From: *NANOG on behalf of Ryan Gelobter < >>> ryan.g at atwgpc.net> >>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>> *To: *NANOG >>> *Subject: *Whats going on at Cogent >>> >>> Anyone else seen terrible support and high turnover of sales/account >>> people at Cogent the last few months? Is there something going on over >>> there internally? I'm sure some people will say Cogent has always been crap >>> but in the past their account reps and support were pretty good. It seems >>> to have gone downhill the last 12 months really bad. >>> >>> Regards, >>> Ryan >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Mon Oct 22 20:16:57 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 22 Oct 2018 22:16:57 +0200 Subject: Whats going on at Cogent In-Reply-To: <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: Hello Our network is connected as follows: 1) We are fully IPv6 deployed 2) We have direct peerings with Google, Apple, Microsoft, Akamai, Cloudflare, etc 3) We have cache servers from Netflix and Akamai 4) We are peered with the route servers on NL-IX and STHIX CPH. 5) Transit from HE, Cogent, GlobalConnect. I am not doing anything to force traffic to the Cogent link (why would I?). But I am not doing anything to force it off either. The nice people at Cogent will regularly call me and ask if I want to buy more transit. However I can not make their network deliver more traffic. I only fully control the outbound and that is a small fraction of our inbound. I understand that measured by "AS rank" Cogent might have more, but that does not translate to traffic in our case. This got to be a problem for them. Regards, Baldur On Sun, Oct 21, 2018 at 2:41 PM Mike Hammett wrote: > I guess first thing's first... you aren't doing anything to force the > traffic that way, are you? > > If you've got IPv6 deployed, chances are that no Google will be coming > over that Cogent. :-) > > CAIDA says Cogent is bigger. > > http://as-rank.caida.org/asns/174/as-core > http://as-rank.caida.org/asns/6939/as-core > > Being an eyeball network, what's going to impact that kind of usage the > most is where the next up connections to Netflix, Google, Akamai, > Cloudflare, etc. are located. If they're closer via HE than Cogent, that's > where your traffic will come from. > > Looking at your network specifically, Netflix isn't on either IX that > you're on, so that HE traffic very well could be a majority Netflix. > > What do your netflows say? > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Baldur Norddahl" > *To: *nanog at nanog.org > *Sent: *Sunday, October 21, 2018 3:20:12 AM > *Subject: *Re: Whats going on at Cogent > > Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps > peak from our HE link and 336 Mbps peak from our Cogent link. This is > inbound traffic. We are eyeballs and our outbound is a small fraction of > our inbound. > > Regards. > > Baldur > > > On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: > >> We have been very happy with HE. It was a no brainer over cogent. They >> are smaller (so are we). When there are issues they are real fast to fix >> them, you also get the personal touch which you don't get with others. >> >> >> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas >> wrote: >> >>> I don't really get the Cogent/Google peering issues. I've been hearing >>> this for years... How about fixing it already? Telling customer to get >>> other transit providers to get to a given network is really bad. >>> >>> On a side note, HE is still HE but they're trying really hard to be a >>> good netcitizen. They've finally pushed filtering for peers: >>> http://routing.he.net. I wouldn't get transit from them, but in some >>> markets, they're the only affordable IP transit providers. >>> >>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>> >>> >>> >>> When I call and mention it I’m told that it’s HE’s fault (despite the >>> lovely cake), but when I also bring Google, then they tell me to get a >>> different provider just for this traffic, or meet them at an IX and send my >>> traffic from there. >>> >>> About the staff rotation I’ve seen it too, and I’ve also seen an >>> increase in salespeople calling, for example when an AS is registered etc. >>> in addition to the normal calls.. >>> >>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>> >>> They call me every few months. the last time they emailed me I said I >>> wasn't interested because of the HE issue. I have yet to get another >>> email....... >>> >>> >>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>> >>> >>> >>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >>> dhubbard at dino.hostasaurus.com> wrote: >>> >>> Have had the same sales rep for several years now; unfortunately he has >>> no ability to fix their IPv6 peering issue so we’re slowly removing >>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>> stable. >>> >>> >>> >>> >>> Yep, this. Whenever Cogent calls, this is what i tell them. >>> Black-holing HE and Google ipv6 traffic, which is what they do if i use a >>> default route from them, is dead on arrival. Shows they make bad decisions >>> and dont put the customer first, or even create such an illusion. >>> >>> >>> >>> >>> *From: *NANOG on behalf of Ryan Gelobter < >>> ryan.g at atwgpc.net> >>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>> *To: *NANOG >>> *Subject: *Whats going on at Cogent >>> >>> Anyone else seen terrible support and high turnover of sales/account >>> people at Cogent the last few months? Is there something going on over >>> there internally? I'm sure some people will say Cogent has always been crap >>> but in the past their account reps and support were pretty good. It seems >>> to have gone downhill the last 12 months really bad. >>> >>> Regards, >>> Ryan >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Oct 22 21:43:23 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Oct 2018 14:43:23 -0700 Subject: Whats going on at Cogent In-Reply-To: <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: Cogent is bigger. HE is more widely peered, especially in IPv6. I may be somewhat prejudice, though I don’t work for HE any more. Most on this list know the history so I won’t repeat it here. Owen > On Oct 21, 2018, at 05:39 , Mike Hammett wrote: > > I guess first thing's first... you aren't doing anything to force the traffic that way, are you? > > If you've got IPv6 deployed, chances are that no Google will be coming over that Cogent. :-) > > CAIDA says Cogent is bigger. > > http://as-rank.caida.org/asns/174/as-core > http://as-rank.caida.org/asns/6939/as-core > > Being an eyeball network, what's going to impact that kind of usage the most is where the next up connections to Netflix, Google, Akamai, Cloudflare, etc. are located. If they're closer via HE than Cogent, that's where your traffic will come from. > > Looking at your network specifically, Netflix isn't on either IX that you're on, so that HE traffic very well could be a majority Netflix. > > What do your netflows say? > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Sunday, October 21, 2018 3:20:12 AM > Subject: Re: Whats going on at Cogent > > Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps peak from our HE link and 336 Mbps peak from our Cogent link. This is inbound traffic. We are eyeballs and our outbound is a small fraction of our inbound. > > Regards. > > Baldur > > > On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender > wrote: > We have been very happy with HE. It was a no brainer over cogent. They are smaller (so are we). When there are issues they are real fast to fix them, you also get the personal touch which you don't get with others. > > > On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas > wrote: > I don't really get the Cogent/Google peering issues. I've been hearing this for years... How about fixing it already? Telling customer to get other transit providers to get to a given network is really bad. > > On a side note, HE is still HE but they're trying really hard to be a good netcitizen. They've finally pushed filtering for peers: http://routing.he.net . I wouldn't get transit from them, but in some markets, they're the only affordable IP transit providers. > > On Oct 16 2018, at 10:04 am, DaKnOb > wrote: > > > When I call and mention it I’m told that it’s HE’s fault (despite the lovely cake), but when I also bring Google, then they tell me to get a different provider just for this traffic, or meet them at an IX and send my traffic from there. > > About the staff rotation I’ve seen it too, and I’ve also seen an increase in salespeople calling, for example when an AS is registered etc. in addition to the normal calls.. > > On 16 Oct 2018, at 16:54, Dovid Bender > wrote: > > They call me every few months. the last time they emailed me I said I wasn't interested because of the HE issue. I have yet to get another email....... > > > On Tue, Oct 16, 2018 at 9:29 AM, Ca By > wrote: > > > On Tue, Oct 16, 2018 at 5:16 AM David Hubbard > wrote: > Have had the same sales rep for several years now; unfortunately he has no ability to fix their IPv6 peering issue so we’re slowly removing circuits, but otherwise for a handful of 10gig DIA circuits it’s been stable. > > > > Yep, this. Whenever Cogent calls, this is what i tell them. Black-holing HE and Google ipv6 traffic, which is what they do if i use a default route from them, is dead on arrival. Shows they make bad decisions and dont put the customer first, or even create such an illusion. > > > > > From: NANOG > on behalf of Ryan Gelobter > > Date: Tuesday, October 16, 2018 at 6:04 AM > To: NANOG > > Subject: Whats going on at Cogent > > Anyone else seen terrible support and high turnover of sales/account people at Cogent the last few months? Is there something going on over there internally? I'm sure some people will say Cogent has always been crap but in the past their account reps and support were pretty good. It seems to have gone downhill the last 12 months really bad. > > Regards, > Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Oct 23 03:47:22 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 22 Oct 2018 23:47:22 -0400 (EDT) Subject: Hurricane Michael: Communications restoration status Message-ID: 39 deaths in the US, at least 15 deaths in Honduras, Nicaragua, El Salvador After 12 days, most wireless service is restored in Florida. It took over 6 months to restore wireless service across Puerto Rico/US Virgin Islands. Today, Oct 22 2018, Verizon Wireless reported wireless services has been restored throughout the area. AT&T Wireless reports 99.9% wireless service restoration. T-Mobile reports service restored or temporary solutions in place. FCC Status Reporting Cellular service: Bay County: 103 cell sites out of service (29.7%) Gadsden County: 12 cell sites out of service (19.4%) Gulf County: 6 cell sites out of service (26.1%) 55,006 wireline and cable customers are reported out of service. 1 TV, 7 FM and 2 AM broadcasters reported out of service. From mehmet at akcin.net Tue Oct 23 04:00:05 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 22 Oct 2018 21:00:05 -0700 Subject: Hurricane Michael: Communications restoration status In-Reply-To: References: Message-ID: Thank you for sharing this. Very sad indeed to hear about 6 months delays in restoring for PR. On Mon, Oct 22, 2018 at 8:47 PM Sean Donelan wrote: > 39 deaths in the US, at least 15 deaths in Honduras, Nicaragua, El > Salvador > > After 12 days, most wireless service is restored in Florida. It took > over 6 months to restore wireless service across Puerto Rico/US Virgin > Islands. > > Today, Oct 22 2018, Verizon Wireless reported wireless services has been > restored throughout the area. > > AT&T Wireless reports 99.9% wireless service restoration. > > T-Mobile reports service restored or temporary solutions in place. > > FCC Status Reporting > > Cellular service: > Bay County: 103 cell sites out of service (29.7%) > Gadsden County: 12 cell sites out of service (19.4%) > Gulf County: 6 cell sites out of service (26.1%) > > 55,006 wireline and cable customers are reported out of service. > > 1 TV, 7 FM and 2 AM broadcasters reported out of service. > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Oct 23 04:42:02 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 23 Oct 2018 00:42:02 -0400 (EDT) Subject: What a FEMA Primary Entry Point emergency alert radio station looks like Message-ID: Almost 100% use of the Emergency Alert System is for local and weather alerts. Nevertheless, there are people who plan for the worst case scenario (i.e. "the really bad, bad day"). If you wonder what a hardened Primary Entry Point station for the Emergency Alert System looks like... a rare media event. https://www.radioworld.com/news-and-business/wlw-pep-station-to-test-new-studio-shelter [...] The Federal Emergency Management Agency expects to reveal new studio capabilities at WLW(AM) in Cincinnati on Wednesday during a first of its kind broadcast from a shelter at the transmitter site of the National Public Warning System (NWPS) Primary Entry Point (PEP) radio station. The iHeartMedia radio station is one of 77 PEP radio stations across the country and the second to have added modernized emergency studio facilities. Enhanced studio capabilities were completed at WJR(AM) in Detroit earlier this year, according to Manny Centeno, FEMA’s NPWS program manager. The upgrades include increased sheltering capabilities, expanded broadcast capacity, and sustainable power generation for all types of hazardous events. [...] Why does the federal government spend money to harden a few radio stations around the country? An example of a "bad day" (but not a really bad, bad day) was Hurricane Maria and Irma in Puerto Rico and US Virgin Islands. Manny Centeno was just one of 15,000 federal employees, and over 100,000 industry, volunteer and local government responders. WSTA and WKAQ are the two hardened PEP stations serving the islands. https://www.hstoday.us/federal-pages/dhs/fema-dhs-federal-pages/hstoday-profile-femas-manny-centeno-resurrects-communications-after-catastrophe/ [...] Nowhere was this challenge more apparent than in Puerto Rico when Hurricane Maria slammed into the island just over a year ago. When the Category 4 hurricane struck the island with 150-mph winds and rain measured in feet – not inches – it knocked out just about every imaginable infrastructure from being usable. Those roads, bridges, airports, harbors, utilities, essential services and communications that were not destroyed or operable post-storm were crippled to a point that they could not provide the capacities necessary for the demands of the response and recovery conditions. [...] From jerome at ceriz.fr Tue Oct 23 12:11:07 2018 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Tue, 23 Oct 2018 14:11:07 +0200 Subject: GGSN/PGW to LNS recommendations Message-ID: <64d69087-5c7f-0c2e-4b0f-66d0ceec9645@ceriz.fr> Hi ! I'm looking for a GGSN/PGW implementation that would act as a LAC, to re-encapsulate PPP sessions into L2TP tunnels to some LNS already deployed for traditional IP-ADSL collects. I found that feature available in Cisco ASR5000 but couldn't yet find any other. Would you have any pointer or references ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14 From mel at beckman.org Tue Oct 23 14:20:07 2018 From: mel at beckman.org (Mel Beckman) Date: Tue, 23 Oct 2018 14:20:07 +0000 Subject: Hurricane Michael: Communications restoration status In-Reply-To: References: Message-ID: <689B93FB-8752-4701-A69A-5F7E98606FD1@beckman.org> It helps to have a largely intact power grid, and a state government that doesn’t squander maintenance dollars on graft and corruption. https://www.reuters.com/article/us-usa-puertorico-prepa-probe/u-s-house-panel-probes-corruption-allegations-at-puerto-rico-utility-idUSKCN1GP03P -mel On Oct 23, 2018, at 12:00 AM, Mehmet Akcin > wrote: Thank you for sharing this. Very sad indeed to hear about 6 months delays in restoring for PR. On Mon, Oct 22, 2018 at 8:47 PM Sean Donelan > wrote: 39 deaths in the US, at least 15 deaths in Honduras, Nicaragua, El Salvador After 12 days, most wireless service is restored in Florida. It took over 6 months to restore wireless service across Puerto Rico/US Virgin Islands. Today, Oct 22 2018, Verizon Wireless reported wireless services has been restored throughout the area. AT&T Wireless reports 99.9% wireless service restoration. T-Mobile reports service restored or temporary solutions in place. FCC Status Reporting Cellular service: Bay County: 103 cell sites out of service (29.7%) Gadsden County: 12 cell sites out of service (19.4%) Gulf County: 6 cell sites out of service (26.1%) 55,006 wireline and cable customers are reported out of service. 1 TV, 7 FM and 2 AM broadcasters reported out of service. -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Oct 23 14:53:10 2018 From: sean at donelan.com (Sean Donelan) Date: Tue, 23 Oct 2018 10:53:10 -0400 (EDT) Subject: Hurricane Michael: Communications restoration status In-Reply-To: <689B93FB-8752-4701-A69A-5F7E98606FD1@beckman.org> References: <689B93FB-8752-4701-A69A-5F7E98606FD1@beckman.org> Message-ID: Florida county power status Bay County - 25,167 custoemrs out of service (21%) Calhoun County - 4,897 customers out of service (71%) Jackson County - 14,953 customers out of service (62%) Gulf County - 2,873 customers out of service (26%) https://www.politico.com/story/2018/09/16/maria-katrina-trump-bush-congress-hurricane-825870 "In the year since Hurricane Maria slammed into Puerto Rico, killing nearly 70 percent more people than Katrina, the GOP-led House has yet to create a select committee to oversee the Trump administration’s recovery efforts. The Senate Homeland Security and Governmental Affairs Committee, which oversees FEMA, has held just two hearings related to the storm. Neither the House nor the Senate have issued any major reports, and none appear to be in the works." https://docs.fcc.gov/public/attachments/DOC-353805A1.pdf 2017 Atlantic Hurricane Season Impact on Communications Report and Recommendations Public Safety Docket No. 17-344 25. Wireless telecommunications service. At its worst, 95.6 percent of the cell sites were out of service in Puerto Rico, and 76.6 percent of the cell sites were out of service in the USVI. Forty-eight out of 78 municipios in Puerto Rico had 100 percent of their cell sites out of service. Wireless service was restored gradually over a six-month period, considerably longer than for any other storm. After six months, 4 percent of cells sites remained out of service (i.e., completely inoperable) in Puerto Rico and 12percent continued to be out of service in the USVI -- outages more typical of a few days after, not many months after, a significant hurricane. On Tue, 23 Oct 2018, Mel Beckman wrote: > It helps to have a largely intact power grid, and a state government that > doesn’t squander maintenance dollars on graft and corruption. > https://www.reuters.com/article/us-usa-puertorico-prepa-probe/u-s-house-pan > el-probes-corruption-allegations-at-puerto-rico-utility-idUSKCN1GP03P > > -mel > > On Oct 23, 2018, at 12:00 AM, Mehmet Akcin wrote: > > Thank you for sharing this. > > Very sad indeed to hear about 6 months delays in restoring for PR. > > On Mon, Oct 22, 2018 at 8:47 PM Sean Donelan wrote: > 39 deaths in the US, at least 15 deaths in Honduras, > Nicaragua, El > Salvador > > After 12 days, most wireless service is restored in > Florida. It took > over 6 months to restore wireless service across Puerto > Rico/US Virgin > Islands. > > Today, Oct 22 2018, Verizon Wireless reported wireless > services has been > restored throughout the area. > > AT&T Wireless reports 99.9% wireless service restoration. > > T-Mobile reports service restored or temporary solutions > in place. > > FCC Status Reporting > > Cellular service: > Bay County: 103 cell sites out of service (29.7%) > Gadsden County: 12 cell sites out of service (19.4%) > Gulf County: 6 cell sites out of service (26.1%) > > 55,006 wireline and cable customers are reported out of > service. > > 1 TV, 7 FM and 2 AM broadcasters reported out of service. > > -- > Mehmet > +1-424-298-1903 > > > From josh at imaginenetworksllc.com Tue Oct 23 15:20:31 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 23 Oct 2018 11:20:31 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: If there is history about HE I should know before signing up with them I'd love to know off list. If it's just between you and HE I hope it wasn't too bad, and I'd be happy to listen, but I don't feel like it's something you need to share at all. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Oct 22, 2018 at 5:43 PM, Owen DeLong wrote: > Cogent is bigger. > > HE is more widely peered, especially in IPv6. > > I may be somewhat prejudice, though I don’t work for HE any more. Most on > this list know the history so I won’t repeat it here. > > Owen > > > On Oct 21, 2018, at 05:39 , Mike Hammett wrote: > > I guess first thing's first... you aren't doing anything to force the > traffic that way, are you? > > If you've got IPv6 deployed, chances are that no Google will be coming > over that Cogent. :-) > > CAIDA says Cogent is bigger. > > http://as-rank.caida.org/asns/174/as-core > http://as-rank.caida.org/asns/6939/as-core > > Being an eyeball network, what's going to impact that kind of usage the > most is where the next up connections to Netflix, Google, Akamai, > Cloudflare, etc. are located. If they're closer via HE than Cogent, that's > where your traffic will come from. > > Looking at your network specifically, Netflix isn't on either IX that > you're on, so that HE traffic very well could be a majority Netflix. > > What do your netflows say? > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Baldur Norddahl" > *To: *nanog at nanog.org > *Sent: *Sunday, October 21, 2018 3:20:12 AM > *Subject: *Re: Whats going on at Cogent > > Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps > peak from our HE link and 336 Mbps peak from our Cogent link. This is > inbound traffic. We are eyeballs and our outbound is a small fraction of > our inbound. > > Regards. > > Baldur > > > On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: > >> We have been very happy with HE. It was a no brainer over cogent. They >> are smaller (so are we). When there are issues they are real fast to fix >> them, you also get the personal touch which you don't get with others. >> >> >> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas >> wrote: >> >>> I don't really get the Cogent/Google peering issues. I've been hearing >>> this for years... How about fixing it already? Telling customer to get >>> other transit providers to get to a given network is really bad. >>> >>> On a side note, HE is still HE but they're trying really hard to be a >>> good netcitizen. They've finally pushed filtering for peers: >>> http://routing.he.net. I wouldn't get transit from them, but in some >>> markets, they're the only affordable IP transit providers. >>> >>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>> >>> >>> >>> When I call and mention it I’m told that it’s HE’s fault (despite the >>> lovely cake), but when I also bring Google, then they tell me to get a >>> different provider just for this traffic, or meet them at an IX and send my >>> traffic from there. >>> >>> About the staff rotation I’ve seen it too, and I’ve also seen an >>> increase in salespeople calling, for example when an AS is registered etc. >>> in addition to the normal calls.. >>> >>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>> >>> They call me every few months. the last time they emailed me I said I >>> wasn't interested because of the HE issue. I have yet to get another >>> email....... >>> >>> >>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>> >>> >>> >>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >>> dhubbard at dino.hostasaurus.com> wrote: >>> >>> Have had the same sales rep for several years now; unfortunately he has >>> no ability to fix their IPv6 peering issue so we’re slowly removing >>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>> stable. >>> >>> >>> >>> >>> Yep, this. Whenever Cogent calls, this is what i tell them. >>> Black-holing HE and Google ipv6 traffic, which is what they do if i use a >>> default route from them, is dead on arrival. Shows they make bad decisions >>> and dont put the customer first, or even create such an illusion. >>> >>> >>> >>> >>> *From: *NANOG on behalf of Ryan Gelobter < >>> ryan.g at atwgpc.net> >>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>> *To: *NANOG >>> *Subject: *Whats going on at Cogent >>> >>> Anyone else seen terrible support and high turnover of sales/account >>> people at Cogent the last few months? Is there something going on over >>> there internally? I'm sure some people will say Cogent has always been crap >>> but in the past their account reps and support were pretty good. It seems >>> to have gone downhill the last 12 months really bad. >>> >>> Regards, >>> Ryan >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Tue Oct 23 15:29:37 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Tue, 23 Oct 2018 10:29:37 -0500 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: We've had HE for 4 years. Pretty great company with good bandwidth. Most of our traffic prefers them. Their support is top notch as well. On Tue, Oct 23, 2018 at 10:20 AM Josh Luthman wrote: > If there is history about HE I should know before signing up with them I'd > love to know off list. > > If it's just between you and HE I hope it wasn't too bad, and I'd be happy > to listen, but I don't feel like it's something you need to share at all. > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Mon, Oct 22, 2018 at 5:43 PM, Owen DeLong wrote: > >> Cogent is bigger. >> >> HE is more widely peered, especially in IPv6. >> >> I may be somewhat prejudice, though I don’t work for HE any more. Most on >> this list know the history so I won’t repeat it here. >> >> Owen >> >> >> On Oct 21, 2018, at 05:39 , Mike Hammett wrote: >> >> I guess first thing's first... you aren't doing anything to force the >> traffic that way, are you? >> >> If you've got IPv6 deployed, chances are that no Google will be coming >> over that Cogent. :-) >> >> CAIDA says Cogent is bigger. >> >> http://as-rank.caida.org/asns/174/as-core >> http://as-rank.caida.org/asns/6939/as-core >> >> Being an eyeball network, what's going to impact that kind of usage the >> most is where the next up connections to Netflix, Google, Akamai, >> Cloudflare, etc. are located. If they're closer via HE than Cogent, that's >> where your traffic will come from. >> >> Looking at your network specifically, Netflix isn't on either IX that >> you're on, so that HE traffic very well could be a majority Netflix. >> >> What do your netflows say? >> >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> ------------------------------ >> *From: *"Baldur Norddahl" >> *To: *nanog at nanog.org >> *Sent: *Sunday, October 21, 2018 3:20:12 AM >> *Subject: *Re: Whats going on at Cogent >> >> Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps >> peak from our HE link and 336 Mbps peak from our Cogent link. This is >> inbound traffic. We are eyeballs and our outbound is a small fraction of >> our inbound. >> >> Regards. >> >> Baldur >> >> >> On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: >> >>> We have been very happy with HE. It was a no brainer over cogent. They >>> are smaller (so are we). When there are issues they are real fast to fix >>> them, you also get the personal touch which you don't get with others. >>> >>> >>> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas >>> wrote: >>> >>>> I don't really get the Cogent/Google peering issues. I've been hearing >>>> this for years... How about fixing it already? Telling customer to get >>>> other transit providers to get to a given network is really bad. >>>> >>>> On a side note, HE is still HE but they're trying really hard to be a >>>> good netcitizen. They've finally pushed filtering for peers: >>>> http://routing.he.net. I wouldn't get transit from them, but in some >>>> markets, they're the only affordable IP transit providers. >>>> >>>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>>> >>>> >>>> >>>> When I call and mention it I’m told that it’s HE’s fault (despite the >>>> lovely cake), but when I also bring Google, then they tell me to get a >>>> different provider just for this traffic, or meet them at an IX and send my >>>> traffic from there. >>>> >>>> About the staff rotation I’ve seen it too, and I’ve also seen an >>>> increase in salespeople calling, for example when an AS is registered etc. >>>> in addition to the normal calls.. >>>> >>>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>>> >>>> They call me every few months. the last time they emailed me I said I >>>> wasn't interested because of the HE issue. I have yet to get another >>>> email....... >>>> >>>> >>>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>>> >>>> >>>> >>>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >>>> dhubbard at dino.hostasaurus.com> wrote: >>>> >>>> Have had the same sales rep for several years now; unfortunately he has >>>> no ability to fix their IPv6 peering issue so we’re slowly removing >>>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>>> stable. >>>> >>>> >>>> >>>> >>>> Yep, this. Whenever Cogent calls, this is what i tell them. >>>> Black-holing HE and Google ipv6 traffic, which is what they do if i use a >>>> default route from them, is dead on arrival. Shows they make bad decisions >>>> and dont put the customer first, or even create such an illusion. >>>> >>>> >>>> >>>> >>>> *From: *NANOG on behalf of Ryan Gelobter < >>>> ryan.g at atwgpc.net> >>>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>>> *To: *NANOG >>>> *Subject: *Whats going on at Cogent >>>> >>>> Anyone else seen terrible support and high turnover of sales/account >>>> people at Cogent the last few months? Is there something going on over >>>> there internally? I'm sure some people will say Cogent has always been crap >>>> but in the past their account reps and support were pretty good. It seems >>>> to have gone downhill the last 12 months really bad. >>>> >>>> Regards, >>>> Ryan >>>> >>>> >> > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Oct 23 15:32:34 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 23 Oct 2018 11:32:34 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: I am also interested in hearing about this. I think it's relevant to the current thread. On Tue, Oct 23, 2018, 11:22 AM Josh Luthman wrote: > If there is history about HE I should know before signing up with them I'd > love to know off list. > > If it's just between you and HE I hope it wasn't too bad, and I'd be happy > to listen, but I don't feel like it's something you need to share at all. > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Mon, Oct 22, 2018 at 5:43 PM, Owen DeLong wrote: > >> Cogent is bigger. >> >> HE is more widely peered, especially in IPv6. >> >> I may be somewhat prejudice, though I don’t work for HE any more. Most on >> this list know the history so I won’t repeat it here. >> >> Owen >> >> >> On Oct 21, 2018, at 05:39 , Mike Hammett wrote: >> >> I guess first thing's first... you aren't doing anything to force the >> traffic that way, are you? >> >> If you've got IPv6 deployed, chances are that no Google will be coming >> over that Cogent. :-) >> >> CAIDA says Cogent is bigger. >> >> http://as-rank.caida.org/asns/174/as-core >> http://as-rank.caida.org/asns/6939/as-core >> >> Being an eyeball network, what's going to impact that kind of usage the >> most is where the next up connections to Netflix, Google, Akamai, >> Cloudflare, etc. are located. If they're closer via HE than Cogent, that's >> where your traffic will come from. >> >> Looking at your network specifically, Netflix isn't on either IX that >> you're on, so that HE traffic very well could be a majority Netflix. >> >> What do your netflows say? >> >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> ------------------------------ >> *From: *"Baldur Norddahl" >> *To: *nanog at nanog.org >> *Sent: *Sunday, October 21, 2018 3:20:12 AM >> *Subject: *Re: Whats going on at Cogent >> >> Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps >> peak from our HE link and 336 Mbps peak from our Cogent link. This is >> inbound traffic. We are eyeballs and our outbound is a small fraction of >> our inbound. >> >> Regards. >> >> Baldur >> >> >> On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender wrote: >> >>> We have been very happy with HE. It was a no brainer over cogent. They >>> are smaller (so are we). When there are issues they are real fast to fix >>> them, you also get the personal touch which you don't get with others. >>> >>> >>> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas >>> wrote: >>> >>>> I don't really get the Cogent/Google peering issues. I've been hearing >>>> this for years... How about fixing it already? Telling customer to get >>>> other transit providers to get to a given network is really bad. >>>> >>>> On a side note, HE is still HE but they're trying really hard to be a >>>> good netcitizen. They've finally pushed filtering for peers: >>>> http://routing.he.net. I wouldn't get transit from them, but in some >>>> markets, they're the only affordable IP transit providers. >>>> >>>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>>> >>>> >>>> >>>> When I call and mention it I’m told that it’s HE’s fault (despite the >>>> lovely cake), but when I also bring Google, then they tell me to get a >>>> different provider just for this traffic, or meet them at an IX and send my >>>> traffic from there. >>>> >>>> About the staff rotation I’ve seen it too, and I’ve also seen an >>>> increase in salespeople calling, for example when an AS is registered etc. >>>> in addition to the normal calls.. >>>> >>>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>>> >>>> They call me every few months. the last time they emailed me I said I >>>> wasn't interested because of the HE issue. I have yet to get another >>>> email....... >>>> >>>> >>>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>>> >>>> >>>> >>>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >>>> dhubbard at dino.hostasaurus.com> wrote: >>>> >>>> Have had the same sales rep for several years now; unfortunately he has >>>> no ability to fix their IPv6 peering issue so we’re slowly removing >>>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>>> stable. >>>> >>>> >>>> >>>> >>>> Yep, this. Whenever Cogent calls, this is what i tell them. >>>> Black-holing HE and Google ipv6 traffic, which is what they do if i use a >>>> default route from them, is dead on arrival. Shows they make bad decisions >>>> and dont put the customer first, or even create such an illusion. >>>> >>>> >>>> >>>> >>>> *From: *NANOG on behalf of Ryan Gelobter < >>>> ryan.g at atwgpc.net> >>>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>>> *To: *NANOG >>>> *Subject: *Whats going on at Cogent >>>> >>>> Anyone else seen terrible support and high turnover of sales/account >>>> people at Cogent the last few months? Is there something going on over >>>> there internally? I'm sure some people will say Cogent has always been crap >>>> but in the past their account reps and support were pretty good. It seems >>>> to have gone downhill the last 12 months really bad. >>>> >>>> Regards, >>>> Ryan >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Tue Oct 23 15:36:34 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 23 Oct 2018 11:36:34 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: It isn't IMO Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Oct 23, 2018 at 11:32 AM, Ross Tajvar wrote: > I am also interested in hearing about this. I think it's relevant to the > current thread. > > On Tue, Oct 23, 2018, 11:22 AM Josh Luthman > wrote: > >> If there is history about HE I should know before signing up with them >> I'd love to know off list. >> >> If it's just between you and HE I hope it wasn't too bad, and I'd be >> happy to listen, but I don't feel like it's something you need to share at >> all. >> >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> >> Suite 1337 >> >> Troy, OH 45373 >> >> >> On Mon, Oct 22, 2018 at 5:43 PM, Owen DeLong wrote: >> >>> Cogent is bigger. >>> >>> HE is more widely peered, especially in IPv6. >>> >>> I may be somewhat prejudice, though I don’t work for HE any more. Most >>> on this list know the history so I won’t repeat it here. >>> >>> Owen >>> >>> >>> On Oct 21, 2018, at 05:39 , Mike Hammett wrote: >>> >>> I guess first thing's first... you aren't doing anything to force the >>> traffic that way, are you? >>> >>> If you've got IPv6 deployed, chances are that no Google will be coming >>> over that Cogent. :-) >>> >>> CAIDA says Cogent is bigger. >>> >>> http://as-rank.caida.org/asns/174/as-core >>> http://as-rank.caida.org/asns/6939/as-core >>> >>> Being an eyeball network, what's going to impact that kind of usage the >>> most is where the next up connections to Netflix, Google, Akamai, >>> Cloudflare, etc. are located. If they're closer via HE than Cogent, that's >>> where your traffic will come from. >>> >>> Looking at your network specifically, Netflix isn't on either IX that >>> you're on, so that HE traffic very well could be a majority Netflix. >>> >>> What do your netflows say? >>> >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> >>> >>> >>> >>> Midwest Internet Exchange >>> >>> >>> >>> The Brothers WISP >>> >>> >>> ------------------------------ >>> *From: *"Baldur Norddahl" >>> *To: *nanog at nanog.org >>> *Sent: *Sunday, October 21, 2018 3:20:12 AM >>> *Subject: *Re: Whats going on at Cogent >>> >>> Is he.net smaller than Cogent? Over the past 24 hours we had 6.7 Gbps >>> peak from our HE link and 336 Mbps peak from our Cogent link. This is >>> inbound traffic. We are eyeballs and our outbound is a small fraction of >>> our inbound. >>> >>> Regards. >>> >>> Baldur >>> >>> >>> On Tue, Oct 16, 2018 at 4:17 PM Dovid Bender >>> wrote: >>> >>>> We have been very happy with HE. It was a no brainer over cogent. They >>>> are smaller (so are we). When there are issues they are real fast to fix >>>> them, you also get the personal touch which you don't get with others. >>>> >>>> >>>> On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas >>>> wrote: >>>> >>>>> I don't really get the Cogent/Google peering issues. I've been hearing >>>>> this for years... How about fixing it already? Telling customer to get >>>>> other transit providers to get to a given network is really bad. >>>>> >>>>> On a side note, HE is still HE but they're trying really hard to be a >>>>> good netcitizen. They've finally pushed filtering for peers: >>>>> http://routing.he.net. I wouldn't get transit from them, but in some >>>>> markets, they're the only affordable IP transit providers. >>>>> >>>>> On Oct 16 2018, at 10:04 am, DaKnOb wrote: >>>>> >>>>> >>>>> >>>>> When I call and mention it I’m told that it’s HE’s fault (despite the >>>>> lovely cake), but when I also bring Google, then they tell me to get a >>>>> different provider just for this traffic, or meet them at an IX and send my >>>>> traffic from there. >>>>> >>>>> About the staff rotation I’ve seen it too, and I’ve also seen an >>>>> increase in salespeople calling, for example when an AS is registered etc. >>>>> in addition to the normal calls.. >>>>> >>>>> On 16 Oct 2018, at 16:54, Dovid Bender wrote: >>>>> >>>>> They call me every few months. the last time they emailed me I said I >>>>> wasn't interested because of the HE issue. I have yet to get another >>>>> email....... >>>>> >>>>> >>>>> On Tue, Oct 16, 2018 at 9:29 AM, Ca By wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard < >>>>> dhubbard at dino.hostasaurus.com> wrote: >>>>> >>>>> Have had the same sales rep for several years now; unfortunately he >>>>> has no ability to fix their IPv6 peering issue so we’re slowly removing >>>>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been >>>>> stable. >>>>> >>>>> >>>>> >>>>> >>>>> Yep, this. Whenever Cogent calls, this is what i tell them. >>>>> Black-holing HE and Google ipv6 traffic, which is what they do if i use a >>>>> default route from them, is dead on arrival. Shows they make bad decisions >>>>> and dont put the customer first, or even create such an illusion. >>>>> >>>>> >>>>> >>>>> >>>>> *From: *NANOG on behalf of Ryan Gelobter < >>>>> ryan.g at atwgpc.net> >>>>> *Date: *Tuesday, October 16, 2018 at 6:04 AM >>>>> *To: *NANOG >>>>> *Subject: *Whats going on at Cogent >>>>> >>>>> Anyone else seen terrible support and high turnover of sales/account >>>>> people at Cogent the last few months? Is there something going on over >>>>> there internally? I'm sure some people will say Cogent has always been crap >>>>> but in the past their account reps and support were pretty good. It seems >>>>> to have gone downhill the last 12 months really bad. >>>>> >>>>> Regards, >>>>> Ryan >>>>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Oct 23 17:39:40 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 23 Oct 2018 10:39:40 -0700 Subject: Performance monitoring Message-ID: hi there, I am trying to find out what everyone is using nowadays for performance monitoring. Thousandeyes, Perfops, Ripe Atlas, Cedexis are some common stuff I have used in the recent past to see DNS/CDN performance , anything new out there that is worth giving it a try specifically focusing on distributed DNS performance? Mehmet From edugas at unknowndevice.ca Tue Oct 23 18:11:57 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 23 Oct 2018 14:11:57 -0400 Subject: Rogers Cable TPIA interconnections Message-ID: Hello, I have one or two questions for networks currently interconnected with Rogers Cable at 855 York Mills. Please respond off-list if you do. Thank you Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at shub-internet.org Wed Oct 24 00:19:52 2018 From: brad at shub-internet.org (Brad Knowles) Date: Tue, 23 Oct 2018 19:19:52 -0500 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> Message-ID: <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> On Oct 23, 2018, at 10:32 AM, Ross Tajvar wrote: > I am also interested in hearing about this. I think it's relevant to the current thread. Speaking only for myself, there are companies where I have done short-term contracts, and where I am definitely not interested in any further employment opportunities with them. OTOH, I am totally happy to continue to be a customer of theirs. Further discussion of that sort of thing would not be appropriate here. If Josh is in the same boat with HE, I totally understand. For the Network Time Foundation (and related projects), I think we've been pretty happy as a customer of HE, but then we're just a small customer of theirs. -- Brad Knowles Please forgive any typos. I'm fighting a failing keyboard on my laptop, in addition to having a broken finger. From ross at tajvar.io Wed Oct 24 00:47:05 2018 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 23 Oct 2018 20:47:05 -0400 Subject: Whats going on at Cogent In-Reply-To: <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> Message-ID: Sorry all. I misread Owen's email. I'm not trying to air his private business to the list. On Tue, Oct 23, 2018, 8:20 PM Brad Knowles wrote: > On Oct 23, 2018, at 10:32 AM, Ross Tajvar wrote: > > > I am also interested in hearing about this. I think it's relevant to the > current thread. > > Speaking only for myself, there are companies where I have done short-term > contracts, and where I am definitely not interested in any further > employment opportunities with them. OTOH, I am totally happy to continue > to be a customer of theirs. > > Further discussion of that sort of thing would not be appropriate here. > If Josh is in the same boat with HE, I totally understand. > > > For the Network Time Foundation (and related projects), I think we've been > pretty happy as a customer of HE, but then we're just a small customer of > theirs. > > -- > Brad Knowles > > Please forgive any typos. I'm fighting a failing keyboard on my laptop, > in addition to having a broken finger. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john-nanog at peachfamily.net Wed Oct 24 11:51:39 2018 From: john-nanog at peachfamily.net (John Peach) Date: Wed, 24 Oct 2018 07:51:39 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> Message-ID: <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> On 10/23/2018 08:47 PM, Ross Tajvar wrote: > Sorry all. I misread Owen's email. I'm not trying to air his private > business to the list. There is no secret - a quick search on the terms HE, Cogent and peering (and possibly cake) will give you the answer. Presumably Owen is not expounding because he used to work for HE. > > On Tue, Oct 23, 2018, 8:20 PM Brad Knowles > wrote: > > On Oct 23, 2018, at 10:32 AM, Ross Tajvar > wrote: > > > I am also interested in hearing about this. I think it's relevant > to the current thread. > > Speaking only for myself, there are companies where I have done > short-term contracts, and where I am definitely not interested in > any further employment opportunities with them.  OTOH, I am totally > happy to continue to be a customer of theirs. > > Further discussion of that sort of thing would not be appropriate > here.  If Josh is in the same boat with HE, I totally understand. > > > For the Network Time Foundation (and related projects), I think > we've been pretty happy as a customer of HE, but then we're just a > small customer of theirs. > > -- > Brad Knowles > > > Please forgive any typos.  I'm fighting a failing keyboard on my > laptop, in addition to having a broken finger. > -- John PGP Public Key: 412934AC From outsider at scarynet.org Wed Oct 24 14:50:20 2018 From: outsider at scarynet.org (Alexander Maassen) Date: Wed, 24 Oct 2018 16:50:20 +0200 Subject: Lots of compromized routers found in thailand Message-ID: Hi all, I know this would belong in THNOG, but since their email turns out to be unroutable, and APNIC never replied to a ticket I filed a week ago, I hope some thai network operators are listening here as well. (True's IRT team contact has however been established already) Since a week I've seen a lot of compromized connections on my personal IRC net from network ranges owned by asiasnet.co.th, 3bb.co.th, totbb.co.th and ais.co.th (and probably others). The issue seems to be limited to TH space at the moment. After investigating some of those bots ip sources, it turns out they all are from clients with routers that have the admin port open to everyone and the routers have the default login (BAD BAD BAD). ACS url's have been changed to http://255.255.255.255. New connections arrive in an estimate of 1 every 3 minutes at the moment. All connections found being affected will and have been added to my dnsbl (dronebl) as type 15 (compromized router/127.0.0.15), if you need a list, contact me off list with your AS number in order to get a dump. Kind regards, Alexander Maassen Maintainer DroneBL -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1774 bytes Desc: not available URL: From mehmet at akcin.net Wed Oct 24 19:44:48 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 24 Oct 2018 12:44:48 -0700 Subject: Network Atlas : Help wanted Message-ID: Hello there, I wanted to give you all an update on Network Atlas http://www.networkatlas.org as we started loading terrestrial links to our system, we have ran into some scale issues but we are working thru this as we speak. We are currently looking for people who can help with providing us KMZs which are publicly available for as many as terrestrial routes possible for us to stress test our newly designed more scalable backend. If you are able to assist please visit our GitHub repository https://github.com/networkatlas/v1/tree/master/Routes and feel free to send me links of the KMZs and I will put them all in this repository for others to easily access and use. We also have a slack channel if you are interested in joining you can click here https://join.slack .com/t/kapany/shared_invite/enQtNDQ1NTkxMzI0NjEyLWUzYWM3YjBjODJmNmYzMjYwZmM4MzFlZjg2MWNjMDUzZGZjMzViNDk0Njc1OTViZmNhMWIxZThiNDBkNWU0YTA if you want to contribute to project in any other way (hosting, software development, etc.. please contact me directly..) thank you everyone and we look forward to making our next update in upcoming weeks. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Wed Oct 24 21:44:38 2018 From: sean at donelan.com (Sean Donelan) Date: Wed, 24 Oct 2018 17:44:38 -0400 (EDT) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI Message-ID: Super Typhoon Yutu with sustained winds of 165 MPH and gusts over 200 MPH has struck the Commonwealth of the Northern Mariana Islands. Guam was on the "weak" side of the typhoon. Internet connectivity is still working on parts of the islands. From owen at delong.com Wed Oct 24 21:54:10 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Oct 2018 14:54:10 -0700 Subject: Whats going on at Cogent In-Reply-To: <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> Message-ID: <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> Mainly I wasn’t expounding because I’m surprised to learn that there’s anyone on this list unfamiliar with it. Didn’t want to bore people. I tended to speak my mind while I worked for HE, I’m certainly not going to stop as a result of no longer working there. ;-) Owen > On Oct 24, 2018, at 04:51 , John Peach wrote: > > On 10/23/2018 08:47 PM, Ross Tajvar wrote: >> Sorry all. I misread Owen's email. I'm not trying to air his private business to the list. > > There is no secret - a quick search on the terms HE, Cogent and peering (and possibly cake) will give you the answer. Presumably Owen is not expounding because he used to work for HE. > >> On Tue, Oct 23, 2018, 8:20 PM Brad Knowles > wrote: >> On Oct 23, 2018, at 10:32 AM, Ross Tajvar > > wrote: >> > I am also interested in hearing about this. I think it's relevant >> to the current thread. >> Speaking only for myself, there are companies where I have done >> short-term contracts, and where I am definitely not interested in >> any further employment opportunities with them. OTOH, I am totally >> happy to continue to be a customer of theirs. >> Further discussion of that sort of thing would not be appropriate >> here. If Josh is in the same boat with HE, I totally understand. >> For the Network Time Foundation (and related projects), I think >> we've been pretty happy as a customer of HE, but then we're just a >> small customer of theirs. >> -- Brad Knowles > >> Please forgive any typos. I'm fighting a failing keyboard on my >> laptop, in addition to having a broken finger. > > > > > -- > John > PGP Public Key: 412934AC From jtk at depaul.edu Wed Oct 24 22:32:41 2018 From: jtk at depaul.edu (John Kristoff) Date: Wed, 24 Oct 2018 17:32:41 -0500 Subject: Cogent and HE feedback [was Re: Whats going on at Cogent] In-Reply-To: <4d6da04959364ffc9476376ef4d05372@XCASPRD01.dpu.depaul.edu> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <4d6da04959364ffc9476376ef4d05372@XCASPRD01.dpu.depaul.edu> Message-ID: <20181024173241.7665f429@p50.localdomain> [ I've largely ignored this thread based on the Subject, but saw this so I'll change the subject to better reflect where I'm taking it. Sorry if this is a rehashing things others my have already said. - jtk ] On Tue, 23 Oct 2018 15:32:34 +0000 Ross Tajvar wrote: > I am also interested in hearing about this. I think it's relevant to > the current thread. DePaul has been a customer of Cogent for over 15 years, since the time they were selling 100 Mb/s or $1000/month. In my opinion from the view of an end user net, nothing fancy, just budget commodity Internet. DePaul has had HE for many years as well. We can see some of the rich peering that Owen suggested they have more of. HE and Cogent are amongst the lowest price providers in my experience. Note, if you're a network like DePaul's and getting transit from one, it would be advisable to get transit from the other (or at least someone else who can reliably reach them). There is plenty of peering dispute history to read up on I won't try to summarize here. If you care about traffic engineering with community tags, you might be disappointed that HE really only support RTBH. However in my experience, support and sales for both organizations seem just fine for what they deliver. I recently had an opportunity to use both (e.g. upgrades and enabling BFD) and things went swimmingly. Just so they get a nod, we also use ServerCentral as a sort of full-service provider. We rely on them for all sorts of things. They, like Cogent and HE are also a good value for DePaul in my opinion. That said, what is right for one organization is not necessarily right for another. That's just my experience and opinion. John From sean at donelan.com Thu Oct 25 04:27:21 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 25 Oct 2018 00:27:21 -0400 (EDT) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI In-Reply-To: References: Message-ID: Super Typhoon Yutu has passed over the Commonwealth of the Northern Mariana Islands, a U.S. territory, and moving to the northwest. According to the National Weather Service, the sustained winds in the eyewall was 180mph. The power is out on Tinian, and communications is spotty, mostly through satellite phones. Saipan has some power and communications. Some social media posting from mobile phones on Saipan. The CNMI EOC building is operating. FEMA has 110 people on the islands, still deployed from previous typhoons. Currently, Saipan airport is closed due to damage and debris. Restoring service at the airport is a priority, because that's how disaster relief supplies will arrive. Seas in the area still have 20-foot waves. The US Coast Guard will start the airlift of supplies from Guam to CNMI as soon as the Saipan runways are cleared. From eric at ericheather.com Thu Oct 25 14:49:36 2018 From: eric at ericheather.com (Eric C. Miller) Date: Thu, 25 Oct 2018 14:49:36 +0000 Subject: SunTrust Network Ops Message-ID: Is there anyone on-list from SunTrust Bank? I have a CGNAT address getting periodic TCP Resets from the online banking portal, and I suspect it's in response to a threat detector. Thank you! Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Oct 25 16:04:30 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 25 Oct 2018 11:04:30 -0500 (CDT) Subject: Hulu In-Reply-To: <1594195810.5081.1486855065051.JavaMail.mhammett@ThunderFuck> References: <1594195810.5081.1486855065051.JavaMail.mhammett@ThunderFuck> Message-ID: <1037877624.8753.1540483467876.JavaMail.mhammett@ThunderFuck> I don't have this as a current issue, but has anyone ever been successful in reaching out to someone in Hulu's NOC to get problems fixed? They seem to be the most common CDN I hear my eyeball colleagues complain about. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mike Hammett" To: "NANOG" Sent: Saturday, February 11, 2017 5:17:49 PM Subject: Hulu Could someone from Hulu reach out to me? My customers are getting the anonymous proxy page and I'm not sure why. They don't have any contact info in peeringdb and their ARIN whois looks more generic than useful (ipadmin@). ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aplato at coldwater.org Thu Oct 25 16:39:36 2018 From: aplato at coldwater.org (Plato, Art) Date: Thu, 25 Oct 2018 12:39:36 -0400 (EDT) Subject: Any Gmail Admins on here? Message-ID: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> I apologize for putting this out in this forum but I have attempted to reach Google/Gmail for several weeks with no response. Their servers have flagged my domain with bad reputation even thought he stats say no spam has been sent from my domain for the past several months that I can see. Please PM me if you are out there. Thanks, Art Plato From mehmet at akcin.net Thu Oct 25 16:43:37 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 25 Oct 2018 09:43:37 -0700 Subject: Hulu In-Reply-To: <1037877624.8753.1540483467876.JavaMail.mhammett@ThunderFuck> References: <1594195810.5081.1486855065051.JavaMail.mhammett@ThunderFuck> <1037877624.8753.1540483467876.JavaMail.mhammett@ThunderFuck> Message-ID: Yep. I will follow up offline On Thu, Oct 25, 2018 at 9:04 AM Mike Hammett wrote: > I don't have this as a current issue, but has anyone ever been successful > in reaching out to someone in Hulu's NOC to get problems fixed? They seem > to be the most common CDN I hear my eyeball colleagues complain about. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Mike Hammett" > *To: *"NANOG" > *Sent: *Saturday, February 11, 2017 5:17:49 PM > *Subject: *Hulu > > Could someone from Hulu reach out to me? My customers are getting the > anonymous proxy page and I'm not sure why. > > They don't have any contact info in peeringdb and their ARIN whois looks > more generic than useful (ipadmin@). > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Oct 25 16:45:09 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 25 Oct 2018 11:45:09 -0500 (CDT) Subject: Any Gmail Admins on here? In-Reply-To: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> References: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> Message-ID: <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Art Plato" To: "nanog" Sent: Thursday, October 25, 2018 11:39:36 AM Subject: Any Gmail Admins on here? I apologize for putting this out in this forum but I have attempted to reach Google/Gmail for several weeks with no response. Their servers have flagged my domain with bad reputation even thought he stats say no spam has been sent from my domain for the past several months that I can see. Please PM me if you are out there. Thanks, Art Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From chk at pobox.com Thu Oct 25 17:23:25 2018 From: chk at pobox.com (Harald Koch) Date: Thu, 25 Oct 2018 13:23:25 -0400 Subject: Any Gmail Admins on here? In-Reply-To: <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> References: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> Message-ID: chilli.nosignal.org has an SSL certificate that expired in *July*. -- Harald On Thu, 25 Oct 2018 at 12:48, Mike Hammett wrote: > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Art Plato" > *To: *"nanog" > *Sent: *Thursday, October 25, 2018 11:39:36 AM > *Subject: *Any Gmail Admins on here? > > I apologize for putting this out in this forum but I have attempted to > reach Google/Gmail for several weeks with no response. Their servers have > flagged my domain with bad reputation even thought he stats say no spam has > been sent from my domain for the past several months that I can see. Please > PM me if you are out there. > > Thanks, > Art Plato > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu Oct 25 17:43:02 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 25 Oct 2018 13:43:02 -0400 (EDT) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI In-Reply-To: References: Message-ID: Parts of Saipan airport was heavily dmanaged. Sea ports are closed. Utility power is out in Saipan, and hundreds of power poles are reported down. Backup generators are operating at critical facilities. The first disaster relief flights are expected at 10am Friday, after the runways at Saipan airport are cleared and certified for operation. IT&E, CNMI's local incumbant telephone provider, reports its central offices are operating and inter-island cables are are intact. Most of the backbone lines on CNMI are buried underground. DOCOMO Pacific, CNMI's local wireless provider, reports its network remained operational through the storm. I am seeing social media posts from people using cell phones on CNMI. Oracle's Internet Intelligence map shows 60% traceroute completion rate in the Northern Mariana Islands. https://map.internetintel.oracle.com/?root=national&country=MP From andreas at naund.org Thu Oct 25 17:43:50 2018 From: andreas at naund.org (Andreas Ott) Date: Thu, 25 Oct 2018 10:43:50 -0700 Subject: Any Gmail Admins on here? In-Reply-To: References: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> Message-ID: I tried telling them as well at the listed admin address of mailman, good luck! sendmail[6318]: w9PH8TE05888: to=mailman at chilli.default.andyd.uk0.bigv.io, ctladdr=andreas (111/200), delay=00:26:38, xdelay=00:00:03, mailer=esmtp, pri=302235, relay=chilli.default.andyd.uk0.bigv.io. [213.138.100.131], dsn=4.3.0, stat=Deferred: 451 Temporary local problem - please try later On Thu, Oct 25, 2018 at 10:27 AM Harald Koch wrote: > chilli.nosignal.org has an SSL certificate that expired in *July*. > > -- > Harald > > > On Thu, 25 Oct 2018 at 12:48, Mike Hammett wrote: > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> ------------------------------ >> *From: *"Art Plato" >> *To: *"nanog" >> *Sent: *Thursday, October 25, 2018 11:39:36 AM >> *Subject: *Any Gmail Admins on here? >> >> I apologize for putting this out in this forum but I have attempted to >> reach Google/Gmail for several weeks with no response. Their servers have >> flagged my domain with bad reputation even thought he stats say no spam has >> been sent from my domain for the past several months that I can see. Please >> PM me if you are out there. >> >> Thanks, >> Art Plato >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From keastes at gmail.com Thu Oct 25 17:51:03 2018 From: keastes at gmail.com (Kendrick Eastes) Date: Thu, 25 Oct 2018 10:51:03 -0700 Subject: Any Gmail Admins on here? In-Reply-To: References: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> Message-ID: <020BB806-0850-45EB-A92B-E7508505F5DF@gmail.com> As has been pointed out on the outages ML repeatedly. On October 25, 2018 10:23:25 AM PDT, Harald Koch wrote: >chilli.nosignal.org has an SSL certificate that expired in *July*. > >-- >Harald > > >On Thu, 25 Oct 2018 at 12:48, Mike Hammett wrote: > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> ------------------------------ >> *From: *"Art Plato" >> *To: *"nanog" >> *Sent: *Thursday, October 25, 2018 11:39:36 AM >> *Subject: *Any Gmail Admins on here? >> >> I apologize for putting this out in this forum but I have attempted >to >> reach Google/Gmail for several weeks with no response. Their servers >have >> flagged my domain with bad reputation even thought he stats say no >spam has >> been sent from my domain for the past several months that I can see. >Please >> PM me if you are out there. >> >> Thanks, >> Art Plato >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu Oct 25 19:27:30 2018 From: sean at donelan.com (Sean Donelan) Date: Thu, 25 Oct 2018 15:27:30 -0400 (EDT) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI In-Reply-To: References: Message-ID: Unlike the major carriers on the US mainland, which generally provide few details and only generic happy, happy, joy, joy messages after hurricanes, IT&E CNMI has been tweeting as it re-aligning antennas at each cell site that service is restored in an area. IT&E updates Update 6:34pm: As of 6PM, all mobile services in Chalan Laulau and Chalan Kanoa have been restored. To report affected services in your area, please send us a direct message. Update 4:11pm: As of 4PM, mobile services in Camachili have been restored. To report affected services in your area, please send us a direct message Update 11:58am: As of 11:41 AM, mobile services in Tanapag have been restored. To report affected services in your area, please send us a direct message. Update 9:28am: Hafa Adai CNMI. The following sites have been restored and mobile services should be up and running in the areas below. Tapochao, Kensington, Lower Base and Capitol Hill. 5 additional sites will be restored within the hour and updates will be provided. From kenny.taylor at kccd.edu Thu Oct 25 20:52:51 2018 From: kenny.taylor at kccd.edu (Kenny Taylor) Date: Thu, 25 Oct 2018 20:52:51 +0000 Subject: Whats going on at Cogent In-Reply-To: <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> Message-ID: I wasn't familiar with it, so thanks for sharing! The Google search for 'he cogent cake' was entertaining. Hard to believe that conflict is going on 9+ years.. Kenny -----Original Message----- From: NANOG On Behalf Of Owen DeLong Sent: Wednesday, October 24, 2018 2:54 PM To: nanog list Subject: Re: Whats going on at Cogent Mainly I wasn’t expounding because I’m surprised to learn that there’s anyone on this list unfamiliar with it. Didn’t want to bore people. I tended to speak my mind while I worked for HE, I’m certainly not going to stop as a result of no longer working there. ;-) Owen > On Oct 24, 2018, at 04:51 , John Peach wrote: > > On 10/23/2018 08:47 PM, Ross Tajvar wrote: >> Sorry all. I misread Owen's email. I'm not trying to air his private business to the list. > > There is no secret - a quick search on the terms HE, Cogent and peering (and possibly cake) will give you the answer. Presumably Owen is not expounding because he used to work for HE. > >> On Tue, Oct 23, 2018, 8:20 PM Brad Knowles > wrote: >> On Oct 23, 2018, at 10:32 AM, Ross Tajvar > > wrote: >> > I am also interested in hearing about this. I think it's relevant >> to the current thread. >> Speaking only for myself, there are companies where I have done >> short-term contracts, and where I am definitely not interested in >> any further employment opportunities with them. OTOH, I am totally >> happy to continue to be a customer of theirs. >> Further discussion of that sort of thing would not be appropriate >> here. If Josh is in the same boat with HE, I totally understand. >> For the Network Time Foundation (and related projects), I think >> we've been pretty happy as a customer of HE, but then we're just a >> small customer of theirs. >> -- Brad Knowles > >> Please forgive any typos. I'm fighting a failing keyboard on my >> laptop, in addition to having a broken finger. > > > > > -- > John > PGP Public Key: 412934AC From bobb.harley at gmail.com Fri Oct 26 13:52:59 2018 From: bobb.harley at gmail.com (Harley H) Date: Fri, 26 Oct 2018 09:52:59 -0400 Subject: =?UTF-8?Q?China_=E2=80=99s_Maxim_=E2=80=93_Leave_No_Access_Point_Unexploit?= =?UTF-8?Q?ed=3A_The_Hidden_Story_of_China_Telecom=E2=80=99_s_BGP_Hijacking?= Message-ID: Curious to hear others' thoughts on this. https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca This paper presents the view that several BGP hijacks performed by China Telecom had malicious intent. The incidents are: * Canada to Korea - 2016 * US to Italy - Oct 2016 * Scandinavia to Japan - April-May 2017 * Italy to Thailand - April-July 2017 The authors claim this is enabled by China Telecom's presence in North America. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Fri Oct 26 16:30:22 2018 From: blake at ispn.net (Blake Hudson) Date: Fri, 26 Oct 2018 11:30:22 -0500 Subject: =?UTF-8?Q?Re:_China_=e2=80=99s_Maxim_=e2=80=93_Leave_No_Access_Poin?= =?UTF-8?Q?t_Unexploited:_The_Hidden_Story_of_China_Telecom=e2=80=99_s_BGP_H?= =?UTF-8?Q?ijacking?= In-Reply-To: References: Message-ID: <2f8d871b-415d-3141-8138-f76c967e6138@ispn.net> Harley H wrote on 10/26/2018 8:52 AM: > Curious to hear others' thoughts on this. > https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca > > This paper presents the view that several BGP hijacks performed by > China Telecom had malicious intent. The incidents are: > * Canada to Korea - 2016 > * US to Italy - Oct 2016 > * Scandinavia to Japan - April-May 2017 > * Italy to Thailand - April-July 2017 > > The authors claim this is enabled by China Telecom's presence in North > America. Not sure I agree with the author's argument of having Access Reciprocity between nations/governments (both as a technical solution or on political principle). Moving towards an ecosystem where prefix advertisements and AS paths are validated to prevent both accidental and intentional hijacks is probably a better solution to improve availability, integrity, and confidentiality. Encrypting traffic so that, even if it does go through a hostile network, it remains confidential and the integrity is validated is also probably a better solution than the proposed access reciprocity. With the number of players involved, neither of these will be short term changes. But, over time, we seem to be moving in that direction already. From cscora at apnic.net Fri Oct 26 18:03:26 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Oct 2018 04:03:26 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20181026180326.CBB36C450F@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 27 Oct, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 722250 Prefixes after maximum aggregation (per Origin AS): 278090 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 346952 Total ASes present in the Internet Routing Table: 62257 Prefixes per ASN: 11.60 Origin-only ASes present in the Internet Routing Table: 53743 Origin ASes announcing only one prefix: 23346 Transit ASes present in the Internet Routing Table: 8514 Transit-only ASes present in the Internet Routing Table: 263 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 44 Max AS path prepend of ASN ( 19955) 41 Prefixes from unregistered ASNs in the Routing Table: 40 Number of instances of unregistered ASNs: 40 Number of 32-bit ASNs allocated by the RIRs: 24617 Number of 32-bit ASNs visible in the Routing Table: 19895 Prefixes from 32-bit ASNs in the Routing Table: 84143 Number of bogon 32-bit ASNs visible in the Routing Table: 230 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 261 Number of addresses announced to Internet: 2860457139 Equivalent to 170 /8s, 127 /16s and 28 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 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: 241318 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 196372 Total APNIC prefixes after maximum aggregation: 56014 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 194079 Unique aggregates announced from the APNIC address blocks: 80222 APNIC Region origin ASes present in the Internet Routing Table: 9197 APNIC Prefixes per ASN: 21.10 APNIC Region origin ASes announcing only one prefix: 2576 APNIC Region transit ASes present in the Internet Routing Table: 1369 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4168 Number of APNIC addresses announced to Internet: 767928322 Equivalent to 45 /8s, 197 /16s and 168 /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: 214886 Total ARIN prefixes after maximum aggregation: 102025 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 214232 Unique aggregates announced from the ARIN address blocks: 102051 ARIN Region origin ASes present in the Internet Routing Table: 18279 ARIN Prefixes per ASN: 11.72 ARIN Region origin ASes announcing only one prefix: 6780 ARIN Region transit ASes present in the Internet Routing Table: 1819 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 44 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2480 Number of ARIN addresses announced to Internet: 1102718992 Equivalent to 65 /8s, 186 /16s and 40 /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: 197293 Total RIPE prefixes after maximum aggregation: 94314 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 193756 Unique aggregates announced from the RIPE address blocks: 114550 RIPE Region origin ASes present in the Internet Routing Table: 25591 RIPE Prefixes per ASN: 7.57 RIPE Region origin ASes announcing only one prefix: 11485 RIPE Region transit ASes present in the Internet Routing Table: 3536 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7526 Number of RIPE addresses announced to Internet: 714749056 Equivalent to 42 /8s, 154 /16s and 52 /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: 93819 Total LACNIC prefixes after maximum aggregation: 21500 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 95259 Unique aggregates announced from the LACNIC address blocks: 41519 LACNIC Region origin ASes present in the Internet Routing Table: 7692 LACNIC Prefixes per ASN: 12.38 LACNIC Region origin ASes announcing only one prefix: 2103 LACNIC Region transit ASes present in the Internet Routing Table: 1448 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5237 Number of LACNIC addresses announced to Internet: 172397600 Equivalent to 10 /8s, 70 /16s and 148 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 19839 Total AfriNIC prefixes after maximum aggregation: 4203 AfriNIC Deaggregation factor: 4.72 Prefixes being announced from the AfriNIC address blocks: 24663 Unique aggregates announced from the AfriNIC address blocks: 8370 AfriNIC Region origin ASes present in the Internet Routing Table: 1210 AfriNIC Prefixes per ASN: 20.38 AfriNIC Region origin ASes announcing only one prefix: 402 AfriNIC Region transit ASes present in the Internet Routing Table: 241 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 484 Number of AfriNIC addresses announced to Internet: 102236160 Equivalent to 6 /8s, 24 /16s and 0 /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 4634 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4522 509 503 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2950 1153 93 VIETEL-AS-AP Viettel Group, VN 45899 2947 1685 110 VNPT-AS-VN VNPT Corp, VN 4766 2807 11130 763 KIXS-AS-KR Korea Telecom, KR 9829 2746 1496 551 BSNL-NIB National Internet Backbone, IN 9394 2426 4907 30 CTTNET China TieTong Telecommunications 9808 2250 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2246 968 51 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2130 421 171 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 3455 1324 84 SHAW - Shaw Communications Inc., CA 11492 3453 223 640 CABLEONE - CABLE ONE, INC., US 22773 3273 2972 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2354 5006 851 AMAZON-02 - Amazon.com, Inc., US 18566 2154 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2145 2737 540 CHARTER-NET-HKY-NC - Charter Communicat 16625 2099 1128 1565 AKAMAI-AS - Akamai Technologies, Inc., 5650 2084 3074 1461 FRONTIER-FRTR - Frontier Communications 30036 2052 346 152 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2041 5080 596 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 4997 1616 132 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3037 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2559 573 1910 AKAMAI-ASN1, US 12389 2144 2125 679 ROSTELECOM-AS, RU 34984 2021 335 532 TELLCOM-AS, TR 9121 1871 1691 17 TTNET, TR 13188 1604 100 45 TRIOLAN, UA 8402 1285 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA 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 5434 3307 599 Uninet S.A. de C.V., MX 10620 3196 489 810 Telmex Colombia S.A., CO 11830 2665 370 80 Instituto Costarricense de Electricidad 6503 1660 449 55 Axtel, S.A.B. de C.V., MX 7303 1436 959 209 Telecom Argentina S.A., AR 28573 1125 2237 181 CLARO S.A., BR 6147 1090 377 29 Telefonica del Peru S.A.A., PE 3816 1027 512 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 936 145 71 Alestra, S. de R.L. de C.V., MX 13999 921 537 258 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 1170 396 48 LINKdotNET-AS, EG 37611 907 107 9 Afrihost, ZA 36903 794 399 146 MT-MPLS, MA 36992 776 1411 41 ETISALAT-MISR, EG 24835 676 758 20 RAYA-AS, EG 8452 636 1728 15 TE-AS TE-AS, EG 37492 467 470 57 ORANGE-, TN 29571 461 70 12 ORANGE-COTE-IVOIRE, CI 23889 396 231 15 MauritiusTelecom, MU 37342 394 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 5434 3307 599 Uninet S.A. de C.V., MX 12479 4997 1616 132 UNI2-AS, ES 4538 4634 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4522 509 503 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3455 1324 84 SHAW - Shaw Communications Inc., CA 11492 3453 223 640 CABLEONE - CABLE ONE, INC., US 22773 3273 2972 164 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3196 489 810 Telmex Colombia S.A., CO 8551 3037 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 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 4997 4865 UNI2-AS, ES 4538 4634 4560 ERX-CERNET-BKB China Education and Research Net 7545 4522 4019 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3455 3371 SHAW - Shaw Communications Inc., CA 22773 3273 3109 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3037 2994 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2950 2857 VIETEL-AS-AP Viettel Group, VN 45899 2947 2837 VNPT-AS-VN VNPT Corp, VN 11492 3453 2813 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 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65551 DOCUMENT 103.112.64.0/23 58889 ZOL-BD Zx Online Ltd, BD 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 92937 UNALLOCATED 110.49.72.0/24 45458 SBN-AWN-AS-02-AP SBN-ISP/AWN-I 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 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 64.28.160.0/20 20475 AS20475 - Global Capacity, LLC, US 64.29.240.0/20 27279 -Reserved AS-, ZZ 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:14 /9:11 /10:36 /11:98 /12:289 /13:567 /14:1122 /15:1888 /16:13319 /17:7885 /18:13837 /19:25410 /20:39613 /21:46014 /22:89730 /23:73619 /24:406579 /25:821 /26:624 /27:639 /28:35 /29:21 /30:22 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3811 4997 UNI2-AS, ES 6327 3240 3455 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2740 3453 CABLEONE - CABLE ONE, INC., US 22773 2529 3273 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2493 3037 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 18566 2048 2154 MEGAPATH5-US - MegaPath Corporation, US 11830 2012 2665 Instituto Costarricense de Electricidad y Telec 30036 1801 2052 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1762 2084 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:1615 2:893 4:18 5:2670 6:43 7:1 8:1142 12:1873 13:231 14:1858 15:33 16:3 17:192 18:58 20:50 23:2471 24:2435 25:2 27:2512 31:2025 32:86 35:30 36:553 37:2927 38:1560 39:262 40:122 41:3211 42:717 43:1979 44:125 45:5844 46:3100 47:228 49:1351 50:1069 51:319 52:1098 54:361 55:1 56:12 57:38 58:1623 59:991 60:418 61:2088 62:1891 63:1795 64:5062 65:2198 66:4830 67:2667 68:1155 69:3341 70:1168 71:591 72:2239 74:2728 75:415 76:470 77:1662 78:1742 79:2217 80:1566 81:1414 82:1053 83:789 84:1043 85:2074 86:561 87:1463 88:948 89:2379 90:208 91:6450 92:1275 93:2394 94:2447 95:3020 96:913 97:351 98:945 99:147 100:86 101:1160 102:263 103:18982 104:3586 105:236 106:898 107:1835 108:709 109:3374 110:1667 111:1814 112:1345 113:1312 114:1142 115:1689 116:1647 117:1796 118:2194 119:1673 120:1082 121:1038 122:2320 123:1656 124:1451 125:1940 128:1209 129:672 130:502 131:1610 132:724 133:191 134:1035 135:237 136:526 137:662 138:1976 139:709 140:553 141:753 142:802 143:1021 144:842 145:496 146:1238 147:773 148:1644 149:781 150:762 151:996 152:875 153:325 154:1895 155:950 156:1557 157:820 158:652 159:1856 160:1474 161:871 162:2639 163:740 164:1096 165:1570 166:454 167:1344 168:3150 169:859 170:3989 171:496 172:1054 173:2083 174:993 175:825 176:2121 177:4019 178:2519 179:1279 180:2125 181:2448 182:2578 183:1305 184:1125 185:14273 186:3613 187:2451 188:2923 189:1997 190:8344 191:1388 192:9887 193:6337 194:5169 195:4041 196:2820 197:1620 198:5675 199:5964 200:7446 201:5011 202:10247 203:10147 204:4615 205:3009 206:3224 207:3203 208:3945 209:4149 210:3837 211:1985 212:2997 213:2810 214:1050 215:54 216:6001 217:2186 218:863 219:577 220:1818 221:994 222:971 223:1394 End of report From randy at psg.com Fri Oct 26 18:33:14 2018 From: randy at psg.com (Randy Bush) Date: Fri, 26 Oct 2018 11:33:14 -0700 Subject: China =?ISO-8859-7?Q?=A2s?= Maxim =?BIG5?Q?=A1V?= Leave No Access Point Unexploited: The Hidden Story of China =?ISO-8859-7?Q?Teleco?= =?ISO-8859-7?Q?m=A2?= s BGP Hijacking In-Reply-To: References: Message-ID: these hacks could have been done from any pwned core router. this is just a desire to get footprint in prc. randy From sean at donelan.com Sat Oct 27 01:46:52 2018 From: sean at donelan.com (Sean Donelan) Date: Fri, 26 Oct 2018 21:46:52 -0400 (EDT) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI In-Reply-To: References: Message-ID: The official damage assessements for CNMI are coming in ... As of October 27, 10am ChST 1 fatality reported so far Utility power is out on all CNMI islands. Saipan has generator fuel. Rota and Tinian all feeders are down. On Tinian - power plant damaged. Hospitals on Saipan and Tinian are open and operating on emergency power. Rota Health Center open and operating on emergency power. Communications - significant damage to cell towers across islands, but telecommunications companies have restored some mobile services. Backbone facilities appear functional, hundreds of utility poles are down across the islands. Transportation - Major and secondary roads are accessible. Saipan and Tinian ports are closed. Saipan airport restricted to military flights only because air traffic control tower damaged. Replacement air traffic control equipment being brought in, and commerical outbound flights expected on Sunday. No inbound commercial flights. Some gas stations open on Saipan, all gas stations closed on Tinian. Banks and ATMs are re-opening today for limited hours. 17 shelters open. Some grocery stores and restaurants re-opening. Public water systems out of service. Water distribution stations are being set up. From jeremyparr at gmail.com Sat Oct 27 15:38:23 2018 From: jeremyparr at gmail.com (Jeremy Parr) Date: Sat, 27 Oct 2018 11:38:23 -0400 Subject: Any Gmail Admins on here? In-Reply-To: References: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> Message-ID: Not only that, but I just tried signing up, and the confirmation email was marked as spam by GMail. Does not inspire confidence. On Thu, Oct 25, 2018 at 1:26 PM Harald Koch wrote: > chilli.nosignal.org has an SSL certificate that expired in *July*. > > -- > Harald > > > On Thu, 25 Oct 2018 at 12:48, Mike Hammett wrote: > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> >> >> >> Midwest Internet Exchange >> >> >> >> The Brothers WISP >> >> >> ------------------------------ >> *From: *"Art Plato" >> *To: *"nanog" >> *Sent: *Thursday, October 25, 2018 11:39:36 AM >> *Subject: *Any Gmail Admins on here? >> >> I apologize for putting this out in this forum but I have attempted to >> reach Google/Gmail for several weeks with no response. Their servers have >> flagged my domain with bad reputation even thought he stats say no spam has >> been sent from my domain for the past several months that I can see. Please >> PM me if you are out there. >> >> Thanks, >> Art Plato >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean at ddostest.me Sat Oct 27 15:50:24 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Sat, 27 Oct 2018 11:50:24 -0400 Subject: Any Gmail Admins on here? In-Reply-To: References: <408555561.154.1540485572122.JavaMail.art@NSD025277563753> <1992703796.8873.1540485905623.JavaMail.mhammett@ThunderFuck> Message-ID: Expired certificate, confirmation email delivered in SPAM. I agree that it looks phishy even if it's probably not. When you read the email In gmail, you can click on the 3 little dots, which will expand a menu and then on "Show original" You should see 3 important email attributes for helping providers in flagging SPAM, which are SPF, DKIM and DMARC. If you don't see all of the 3, there is a big chance that gmail will flag as SPAM. SPF: PASS with IP 2600::25 Learn more DKIM: 'PASS' with domain example.com Learn more DMARC: 'PASS' Learn more Does the email have all of the 3 or only some or none? Jean On 10/27/18 11:38 AM, Jeremy Parr wrote: > Not only that, but I just tried signing up, and the confirmation email > was marked as spam by GMail. Does not inspire confidence. > > On Thu, Oct 25, 2018 at 1:26 PM Harald Koch > wrote: > > chilli.nosignal.org has an SSL > certificate that expired in *July*. > > -- > Harald > > > On Thu, 25 Oct 2018 at 12:48, Mike Hammett > wrote: > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------------------------------------------------ > *From: *"Art Plato" > > *To: *"nanog" > > *Sent: *Thursday, October 25, 2018 11:39:36 AM > *Subject: *Any Gmail Admins on here? > > I apologize for putting this out in this forum but I have > attempted to reach Google/Gmail for several weeks with no > response. Their servers have flagged my domain with bad > reputation even thought he stats say no spam has been sent > from my domain for the past several months that I can see. > Please PM me if you are out there. > > Thanks, > Art Plato > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Sun Oct 28 14:13:33 2018 From: sean at donelan.com (Sean Donelan) Date: Sun, 28 Oct 2018 10:13:33 -0400 (EDT) Subject: Super typhoon Yutu strikes U.S. territories of Guam and CNMI In-Reply-To: References: Message-ID: 1 confirmed fatality on Saipan. 100% utility power was out of service (Saipan, Tinian). Today, Roto has 99% power restored. Saipan and Tinian still ahve damaged feeders and power plants. Some utility power expected to be restored by October 31. Public water utility out of service. Water distribution points are operating. All seaports re-opened. Saipan and Tinian airports open for humanitarian relieft flights only. Limited commercial service for outbound passengers only. Major roads and most secondary roads are accessible. Saipan hospital fully operational. Tinian and Rota urgent care health centers operating on generator power. Air ambulance service between islands operating. Telephone exchange with inter-island connections is on generator power with 96 hour fuel capacity. Hundreds of telephone poles reported toppled across the islands. Most backbone fiber cables are underground. Saipain and Roto: cell towers operating on generator power. Limited cell service operating on Tinian (1 community). >From local reports, all radio/TV stations are off the air in CNMI. The FCC has not activated DIRS in CNMI. From mpetach at netflight.com Mon Oct 29 00:19:41 2018 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 28 Oct 2018 17:19:41 -0700 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> Message-ID: On Thu, Oct 25, 2018 at 1:54 PM Kenny Taylor wrote: > I wasn't familiar with it, so thanks for sharing! The Google search for > 'he cogent cake' was entertaining. Hard to believe that conflict is going > on 9+ years.. > > Kenny > I can vouch for it. The cake was delicious and moist. And it was not a lie. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon Oct 29 08:35:21 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 29 Oct 2018 04:35:21 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> Message-ID: <212071.1540802121@turing-police.cc.vt.edu> On Sun, 28 Oct 2018 17:19:41 -0700, Matthew Petach said: > I can vouch for it. > > The cake was delicious and moist. I'm glad to hear it did *some* sort of good. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Mon Oct 29 12:22:54 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 29 Oct 2018 07:22:54 -0500 (CDT) Subject: Whats going on at Cogent In-Reply-To: <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> Message-ID: <1622051101.11339.1540815773292.JavaMail.mhammett@ThunderFuck> We've adopted sending cakes a couple times in that same spirit. They've been met with equal success. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "John Peach" To: "North American Network Operators' Group" Sent: Wednesday, October 24, 2018 6:51:39 AM Subject: Re: Whats going on at Cogent On 10/23/2018 08:47 PM, Ross Tajvar wrote: > Sorry all. I misread Owen's email. I'm not trying to air his private > business to the list. There is no secret - a quick search on the terms HE, Cogent and peering (and possibly cake) will give you the answer. Presumably Owen is not expounding because he used to work for HE. > > On Tue, Oct 23, 2018, 8:20 PM Brad Knowles > wrote: > > On Oct 23, 2018, at 10:32 AM, Ross Tajvar > wrote: > > > I am also interested in hearing about this. I think it's relevant > to the current thread. > > Speaking only for myself, there are companies where I have done > short-term contracts, and where I am definitely not interested in > any further employment opportunities with them. OTOH, I am totally > happy to continue to be a customer of theirs. > > Further discussion of that sort of thing would not be appropriate > here. If Josh is in the same boat with HE, I totally understand. > > > For the Network Time Foundation (and related projects), I think > we've been pretty happy as a customer of HE, but then we're just a > small customer of theirs. > > -- > Brad Knowles > > > Please forgive any typos. I'm fighting a failing keyboard on my > laptop, in addition to having a broken finger. > -- John PGP Public Key: 412934AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Oct 29 21:02:02 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 29 Oct 2018 14:02:02 -0700 Subject: looking glass software Message-ID: hey there, I am looking for a looking glass software which is available as free & open source. I have done some research ( https://github.com/search?q=looking+glass ) and installed https://github.com/telephone/LookingGlass and https://github.com/17mon/LookingGlass i wanted to drop a note to NANOG asking for possible recommendations. thank you Mehmet From jackson.tim at gmail.com Mon Oct 29 21:13:00 2018 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 29 Oct 2018 16:13:00 -0500 Subject: looking glass software In-Reply-To: References: Message-ID: I just tried out: https://github.com/respawner/looking-glass today, it seems to be at least new-ish and was pretty easy to get going. -- Tim On Mon, Oct 29, 2018 at 4:04 PM Mehmet Akcin wrote: > hey there, > > I am looking for a looking glass software which is available as free & > open source. > > I have done some research ( https://github.com/search?q=looking+glass > ) and installed https://github.com/telephone/LookingGlass and > https://github.com/17mon/LookingGlass > > i wanted to drop a note to NANOG asking for possible recommendations. > > thank you > > Mehmet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.king at de-cix.net Mon Oct 29 21:48:12 2018 From: thomas.king at de-cix.net (Thomas King) Date: Mon, 29 Oct 2018 21:48:12 +0000 Subject: looking glass software In-Reply-To: References: Message-ID: <5DE35F28-67A1-4AE0-A8AD-EF5DA55725E1@de-cix.net> Hi Mehmet, DE-CIX just launched its new Looking Glass service (https://lg.de-cix.net/alice/) based on the open source tool Alice https://github.com/alice-lg Best regards, Thomas On 29.10.18, 22:02, "NANOG on behalf of Mehmet Akcin" wrote: hey there, I am looking for a looking glass software which is available as free & open source. I have done some research ( https://github.com/search?q=looking+glass ) and installed https://github.com/telephone/LookingGlass and https://github.com/17mon/LookingGlass i wanted to drop a note to NANOG asking for possible recommendations. thank you Mehmet -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5353 bytes Desc: not available URL: From mehmet at akcin.net Tue Oct 30 03:11:43 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 29 Oct 2018 20:11:43 -0700 Subject: CLS to CLS Latency info Message-ID: Hello there I have been searching for CLS (Cable Landing Station) to CLS latency infirnation for submarine cables. I was able to identify only a handful of them via sales catalogs. I am still missing like 320~ systems, does wnyone have this info available? If i can’t find the data, i am going to formulate from lentgh of fiber diveded by speed of light on fibre (~ +\- resistance) but I really would prefer actual ping ;) This is for www.networkatlas.org project. Thank you in advance! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Tue Oct 30 03:20:12 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Mon, 29 Oct 2018 23:20:12 -0400 Subject: looking glass software In-Reply-To: <5DE35F28-67A1-4AE0-A8AD-EF5DA55725E1@de-cix.net> References: <5DE35F28-67A1-4AE0-A8AD-EF5DA55725E1@de-cix.net> Message-ID: <1540869537.local-30e34443-2920-v1.5.1-da141eaf@getmailspring.com> I've been using https://github.com/ramnode/LookingGlass for a while. In Python 2.7 instead of PHP. Works well under nginx. On Oct 29 2018, at 5:48 pm, Thomas King wrote: > > Hi Mehmet, > DE-CIX just launched its new Looking Glass service (https://lg.de-cix.net/alice/) based on the open source tool Alice https://github.com/alice-lg > Best regards, > Thomas > > On 29.10.18, 22:02, "NANOG on behalf of Mehmet Akcin" wrote: > hey there, > I am looking for a looking glass software which is available as free & > open source. > > I have done some research ( https://github.com/search?q=looking+glass > ) and installed https://github.com/telephone/LookingGlass and > https://github.com/17mon/LookingGlass > > i wanted to drop a note to NANOG asking for possible recommendations. > thank you > Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Tue Oct 30 07:59:48 2018 From: ben at 6by7.net (Ben Cannon) Date: Tue, 30 Oct 2018 00:59:48 -0700 Subject: CLS to CLS Latency info In-Reply-To: References: Message-ID: <0FA92B6B-1993-473A-A734-CB3F3C9A3FBA@6by7.net> I’d be astonished if they varied much from lightspeed. -Ben > On Oct 29, 2018, at 8:11 PM, Mehmet Akcin wrote: > > Hello there > > I have been searching for CLS (Cable Landing Station) to CLS latency infirnation for submarine cables. I was able to identify only a handful of them via sales catalogs. I am still missing like 320~ systems, does wnyone have this info available? > > If i can’t find the data, i am going to formulate from lentgh of fiber diveded by speed of light on fibre (~ +\- resistance) but I really would prefer actual ping ;) > > This is for www.networkatlas.org project. Thank you in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Oct 30 09:28:36 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 30 Oct 2018 11:28:36 +0200 Subject: CLS to CLS Latency info In-Reply-To: <0FA92B6B-1993-473A-A734-CB3F3C9A3FBA@6by7.net> References: <0FA92B6B-1993-473A-A734-CB3F3C9A3FBA@6by7.net> Message-ID: Agreed. Actual ping would not work, if we're talking about unixy system sending ping. Active devices increase latency in single digit microsecond, the host latency is much much higher, so the ping results would largely measure your host latency variation. You'd need NIC with hardware timestamping to get anything useful. I don't think we have unixy 'ping' tool which uses that? Even though typical server NIC today does do that, unfortunately SR-IOV does not expose it to guests, so guests would need direct NIC access to utilise it. On Tue, 30 Oct 2018 at 10:03, Ben Cannon wrote: > > I’d be astonished if they varied much from lightspeed. > > -Ben > > On Oct 29, 2018, at 8:11 PM, Mehmet Akcin wrote: > > Hello there > > I have been searching for CLS (Cable Landing Station) to CLS latency infirnation for submarine cables. I was able to identify only a handful of them via sales catalogs. I am still missing like 320~ systems, does wnyone have this info available? > > If i can’t find the data, i am going to formulate from lentgh of fiber diveded by speed of light on fibre (~ +\- resistance) but I really would prefer actual ping ;) > > This is for www.networkatlas.org project. Thank you in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 -- ++ytti From jason+nanog at lixfeld.ca Tue Oct 30 12:13:19 2018 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Tue, 30 Oct 2018 08:13:19 -0400 Subject: Peering management software Message-ID: Hello all, I’m researching various peering management software options, commercial or otherwise, geared towards network operators. Wondering if folks might be able to help add to my list - https://github.com/loopodoopo/pms https://www.6connect.com/peering-manager/ https://github.com/respawner/peering-manager http://www.lacnic.net/innovaportal/file/2569/1/mnovakovic_pivo_1.7.pdf [1] https://github.com/ipcjk/ixgen [1] If anyone from LinkedIn is around who might be able to contact me with info on Pivo, I’d be grateful! Thanks! From nanog at ics-il.net Tue Oct 30 14:29:56 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 30 Oct 2018 09:29:56 -0500 (CDT) Subject: CLS to CLS Latency info In-Reply-To: <0FA92B6B-1993-473A-A734-CB3F3C9A3FBA@6by7.net> References: <0FA92B6B-1993-473A-A734-CB3F3C9A3FBA@6by7.net> Message-ID: <1394730804.742.1540909794969.JavaMail.mhammett@ThunderFuck> The speed of light through fiber is about 2/3 the speed of light through a vacuum. This is why HFT prefers microwave over fiber when it comes to latency. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ben Cannon" To: "Mehmet Akcin" Cc: "nanog" Sent: Tuesday, October 30, 2018 2:59:48 AM Subject: Re: CLS to CLS Latency info I’d be astonished if they varied much from lightspeed. -Ben On Oct 29, 2018, at 8:11 PM, Mehmet Akcin < mehmet at akcin.net > wrote: Hello there I have been searching for CLS (Cable Landing Station) to CLS latency infirnation for submarine cables. I was able to identify only a handful of them via sales catalogs. I am still missing like 320~ systems, does wnyone have this info available? If i can’t find the data, i am going to formulate from lentgh of fiber diveded by speed of light on fibre (~ +\- resistance) but I really would prefer actual ping ;) This is for www.networkatlas.org project. Thank you in advance! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Oct 30 14:41:17 2018 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 30 Oct 2018 10:41:17 -0400 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> Message-ID: Maybe Cogent refuses to work with Google so nobody can search for evidence of said cake.... :) On Thu, Oct 25, 2018 at 4:55 PM Kenny Taylor wrote: > I wasn't familiar with it, so thanks for sharing! The Google search for > 'he cogent cake' was entertaining. Hard to believe that conflict is going > on 9+ years.. > > Kenny > > > -----Original Message----- > From: NANOG On Behalf Of Owen DeLong > Sent: Wednesday, October 24, 2018 2:54 PM > To: nanog list > Subject: Re: Whats going on at Cogent > > Mainly I wasn’t expounding because I’m surprised to learn that there’s > anyone on this list unfamiliar with it. > > Didn’t want to bore people. > > I tended to speak my mind while I worked for HE, I’m certainly not going > to stop as a result of no longer working there. ;-) > > Owen > > > > On Oct 24, 2018, at 04:51 , John Peach > wrote: > > > > On 10/23/2018 08:47 PM, Ross Tajvar wrote: > >> Sorry all. I misread Owen's email. I'm not trying to air his private > business to the list. > > > > There is no secret - a quick search on the terms HE, Cogent and peering > (and possibly cake) will give you the answer. Presumably Owen is not > expounding because he used to work for HE. > > > >> On Tue, Oct 23, 2018, 8:20 PM Brad Knowles > wrote: > >> On Oct 23, 2018, at 10:32 AM, Ross Tajvar >> > wrote: > >> > I am also interested in hearing about this. I think it's relevant > >> to the current thread. > >> Speaking only for myself, there are companies where I have done > >> short-term contracts, and where I am definitely not interested in > >> any further employment opportunities with them. OTOH, I am totally > >> happy to continue to be a customer of theirs. > >> Further discussion of that sort of thing would not be appropriate > >> here. If Josh is in the same boat with HE, I totally understand. > >> For the Network Time Foundation (and related projects), I think > >> we've been pretty happy as a customer of HE, but then we're just a > >> small customer of theirs. > >> -- Brad Knowles brad at shub-internet.org>> > >> Please forgive any typos. I'm fighting a failing keyboard on my > >> laptop, in addition to having a broken finger. > > > > > > > > > > -- > > John > > PGP Public Key: 412934AC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Tue Oct 30 16:11:53 2018 From: bryan at shout.net (Bryan Holloway) Date: Tue, 30 Oct 2018 11:11:53 -0500 Subject: Whats going on at Cogent In-Reply-To: References: <39CD8A25-AFDE-492B-AD1E-7126CB01C5B2@gmail.com> <1539698741.local-f334645b-242a-v1.4.2-f587b7b7@getmailspring.com> <1603355381.4432.1540125581028.JavaMail.mhammett@ThunderFuck> <881997D0-3F98-4725-8B95-7C3E09D7E818@shub-internet.org> <6ecb8b35-202c-1055-61d5-85c6ce34c7fb@peachfamily.net> <2B0C1FA1-DFC1-431B-9D22-205AACA4B053@delong.com> Message-ID: <574c3745-2041-7ff7-d440-d500d11328bb@shout.net> Let me Bing that for you. Oh, wait. On 10/30/18 9:41 AM, Tom Beecher wrote: > Maybe Cogent refuses to work with Google so nobody can search for > evidence of said cake.... > > :) > > On Thu, Oct 25, 2018 at 4:55 PM Kenny Taylor > wrote: > > I wasn't familiar with it, so thanks for sharing!  The Google search > for 'he cogent cake' was entertaining.  Hard to believe that > conflict is going on 9+ years.. > > Kenny > > > -----Original Message----- > From: NANOG > On Behalf Of Owen DeLong > Sent: Wednesday, October 24, 2018 2:54 PM > To: nanog list > > Subject: Re: Whats going on at Cogent > > Mainly I wasn’t expounding because I’m surprised to learn that > there’s anyone on this list unfamiliar with it. > > Didn’t want to bore people. > > I tended to speak my mind while I worked for HE, I’m certainly not > going to stop as a result of no longer working there. ;-) > > Owen > > > > On Oct 24, 2018, at 04:51 , John Peach > > wrote: > > > > On 10/23/2018 08:47 PM, Ross Tajvar wrote: > >> Sorry all. I misread Owen's email. I'm not trying to air his > private business to the list. > > > > There is no secret - a quick search on the terms HE, Cogent and > peering (and possibly cake) will give you the answer. Presumably > Owen is not expounding because he used to work for HE. > > > >> On Tue, Oct 23, 2018, 8:20 PM Brad Knowles > > >> wrote: > >>    On Oct 23, 2018, at 10:32 AM, Ross Tajvar > >>    >> wrote: > >>     > I am also interested in hearing about this. I think it's > relevant > >>    to the current thread. > >>    Speaking only for myself, there are companies where I have done > >>    short-term contracts, and where I am definitely not interested in > >>    any further employment opportunities with them.  OTOH, I am > totally > >>    happy to continue to be a customer of theirs. > >>    Further discussion of that sort of thing would not be appropriate > >>    here.  If Josh is in the same boat with HE, I totally understand. > >>    For the Network Time Foundation (and related projects), I think > >>    we've been pretty happy as a customer of HE, but then we're > just a > >>    small customer of theirs. > >>    --     Brad Knowles >> > >>    Please forgive any typos.  I'm fighting a failing keyboard on my > >>    laptop, in addition to having a broken finger. > > > > > > > > > > -- > > John > > PGP Public Key: 412934AC > From mehmet at akcin.net Wed Oct 31 15:56:23 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 31 Oct 2018 08:56:23 -0700 Subject: CLS to CLS Latency info In-Reply-To: <1394730804.742.1540909794969.JavaMail.mhammett@ThunderFuck> References: <0FA92B6B-1993-473A-A734-CB3F3C9A3FBA@6by7.net> <1394730804.742.1540909794969.JavaMail.mhammett@ThunderFuck> Message-ID: We are going to be making the data available soon at www.networkatlas.org - we are going to be able to make it so people can self upload/manage the information so we are able to crowdsource the info. here is the latest screenshots from networkatlas ;) https://drive.google.com/drive/folders/1JsV7QRaWkzj9W3oEwJe7Qm-vqwXjOdu3?usp=sharing if anyone wants to demo the beta, please let me know and i can share the link privately (i am trying to not do it here because it's running on a small infrastructure now and don't want to crash it;) On Tue, Oct 30, 2018 at 7:30 AM Mike Hammett wrote: > The speed of light through fiber is about 2/3 the speed of light through a > vacuum. This is why HFT prefers microwave over fiber when it comes to > latency. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Ben Cannon" > *To: *"Mehmet Akcin" > *Cc: *"nanog" > *Sent: *Tuesday, October 30, 2018 2:59:48 AM > *Subject: *Re: CLS to CLS Latency info > > I’d be astonished if they varied much from lightspeed. > > -Ben > > On Oct 29, 2018, at 8:11 PM, Mehmet Akcin wrote: > > Hello there > > I have been searching for CLS (Cable Landing Station) to CLS latency > infirnation for submarine cables. I was able to identify only a handful of > them via sales catalogs. I am still missing like 320~ systems, does wnyone > have this info available? > > If i can’t find the data, i am going to formulate from lentgh of fiber > diveded by speed of light on fibre (~ +\- resistance) but I really would > prefer actual ping ;) > > This is for www.networkatlas.org project. Thank you in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Wed Oct 31 16:06:07 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 31 Oct 2018 09:06:07 -0700 Subject: Network Atlas : Help wanted In-Reply-To: References: Message-ID: There were many requests for screenshots and I wanted to share it with everyone here. thank you everyone for all suggestions and help. https://drive.google.com/open?id=1JsV7QRaWkzj9W3oEwJe7Qm-vqwXjOdu3 On Wed, Oct 24, 2018 at 12:44 PM Mehmet Akcin wrote: > Hello there, > > I wanted to give you all an update on Network Atlas > http://www.networkatlas.org as we started loading terrestrial links to > our system, we have ran into some scale issues but we are working thru this > as we speak. > > We are currently looking for people who can help with providing us KMZs > which are publicly available for as many as terrestrial routes possible for > us to stress test our newly designed more scalable backend. > > If you are able to assist please visit our GitHub repository > https://github.com/networkatlas/v1/tree/master/Routes and feel free to > send me links of the KMZs and I will put them all in this repository for > others to easily access and use. > > We also have a slack channel if you are interested in joining you can > click here https://join.slack > .com/t/kapany/shared_invite/enQtNDQ1NTkxMzI0NjEyLWUzYWM3YjBjODJmNmYzMjYwZmM4MzFlZjg2MWNjMDUzZGZjMzViNDk0Njc1OTViZmNhMWIxZThiNDBkNWU0YTA > > if you want to contribute to project in any other way (hosting, software > development, etc.. please contact me directly..) > > thank you everyone and we look forward to making our next update in > upcoming weeks. > > Mehmet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kburke at burlingtontelecom.com Wed Oct 31 20:01:54 2018 From: kburke at burlingtontelecom.com (Kevin Burke) Date: Wed, 31 Oct 2018 20:01:54 +0000 Subject: Brocade SLX Internet Edge Message-ID: Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. The specs and sales rep says its fine, but the price makes me think its too good to be true. We are trying to shepherd an old Cat 6509 out of our core. Kevin Burke 802-540-0979 Burlington Telecom - City of Burlington 200 Church St, Burlington, VT 05401 From aaron at wholesaleinternet.net Wed Oct 31 20:56:29 2018 From: aaron at wholesaleinternet.net (Aaron) Date: Wed, 31 Oct 2018 15:56:29 -0500 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes. On 10/31/2018 3:01 PM, Kevin Burke wrote: > Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. > > The specs and sales rep says its fine, but the price makes me think its too good to be true. > > We are trying to shepherd an old Cat 6509 out of our core. > > > Kevin Burke > 802-540-0979 > Burlington Telecom - City of Burlington > 200 Church St, Burlington, VT 05401 > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From bengelly at gmail.com Wed Oct 31 20:59:59 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Wed, 31 Oct 2018 21:59:59 +0100 Subject: Brocade SLX Internet Edge In-Reply-To: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> Message-ID: <221FE7E2-4D44-4802-ABF5-FA6AD415D5F2@gmail.com> Last I heard (before switching shops), not yet it won’t. Best regards. > Le 31 oct. 2018 à 21:56, Aaron a écrit : > > It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes. > > >> On 10/31/2018 3:01 PM, Kevin Burke wrote: >> Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. >> >> The specs and sales rep says its fine, but the price makes me think its too good to be true. >> >> We are trying to shepherd an old Cat 6509 out of our core. >> >> >> Kevin Burke >> 802-540-0979 >> Burlington Telecom - City of Burlington >> 200 Church St, Burlington, VT 05401 >> > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > From rwoolleynanog at gmail.com Wed Oct 31 21:01:36 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Wed, 31 Oct 2018 17:01:36 -0400 Subject: NANOG 75 Call for Presentations is open Message-ID: NANOG Community, The NANOG Program Committee (PC) is excited to announce that we are now accepting proposals for all sessions at NANOG 75 in San Francisco, California, February 18-20, 2019. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at http://www.cvent.com/d/1bqspy/6K The NANOG PC seeks proposals for presentations, panels, tutorials, and track sessions for the NANOG 75 program. We welcome suggestions of speakers or topic ideas. Presentations may cover current technologies already deployed or soon-to-be deployed in the Internet. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations must not be promotional or discuss proprietary solutions. NANOG 75 submissions can be entered on the NANOG Program Committee Tool (PC Tool) at: https://pc.nanog.org The primary speaker, moderator, or author should submit a presentation proposal and an abstract in the PC Tool. -- Select “Propose Talk” from the Talks menu -- Select NANOG 75 from the Meeting menu -- Select the appropriate *Session* the talk will be presented in = General Session (30-45 minutes) = Tutorial (90-120 minutes) = Track (90-120 minutes) Timeline for submission and proposal review: -- Submitter enters abstract (and draft slides if possible) in PC Tool prior to deadline for slide submission -- PC performs initial review and assigns a “shepherd” to help develop the submission - within 2 weeks -- Submitter develops draft slides of talk if not already submitted with initial proposal. Please submit initial draft slides early -- Panel and Track submissions should provide topic list and intended/confirmed participants in the abstract -- PC reviews slides and continues to work with Submitter as needed to develop topic -- Draft presentation slides should be submitted prior to published deadline for slides -- PC accepts or declines submission -- Agenda assembled and posted -- Submitters notified If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the Program Committee, and a representative will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the PC Tool without delay! We look forward to reviewing your submission. Key Dates for NANOG 75: Oct. 29, 2018: CFP Opens & Agenda Outline Posted Dec. 03, 2018: CFP Deadline: Presentation Slides Due Jan. 14, 2019: CFP Topic List & NANOG Meeting Highlights Page Jan. 22, 2019: NANOG 75 Agenda Published Feb. 11, 2019: Speaker FINAL presentations to PC tool or speaker-support Feb. 17, 2019: Lightning Talk Submissions Open (Abstracts Only) Feb. 17, 2019: Onsite Registration Final slides MUST be submitted by Monday, February 11, 2018, and no changes will be accepted between that date and the conference. Materials received after that date will be updated on the web site after the completion of the conference. We look forward to seeing you in February in San Francisco! Sincerely, Ryan Woolley NANOG PC From ben at 6by7.net Wed Oct 31 21:04:23 2018 From: ben at 6by7.net (Ben Cannon) Date: Wed, 31 Oct 2018 14:04:23 -0700 Subject: Brocade SLX Internet Edge In-Reply-To: References: Message-ID: <1B1586A6-A065-4EEE-8164-968477914015@6by7.net> That won’t hold a full table - so performance isn’t relevant. -Ben > On Oct 31, 2018, at 1:01 PM, Kevin Burke wrote: > > Does anyone have any success with the Brocade SLX 9540 or similar? Its going to be taking full BGP tables from two Tier1's and some peering. > > The specs and sales rep says its fine, but the price makes me think its too good to be true. > > We are trying to shepherd an old Cat 6509 out of our core. > > > Kevin Burke > 802-540-0979 > Burlington Telecom - City of Burlington > 200 Church St, Burlington, VT 05401 From lists.nanog at monmotha.net Wed Oct 31 22:07:38 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 31 Oct 2018 18:07:38 -0400 Subject: Brocade SLX Internet Edge In-Reply-To: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> Message-ID: <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> On 10/31/18 4:56 PM, Aaron wrote: > It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes. That was changed earlier this year AFAIK. The website was slow to get updated but has been updated now. Current claim is 1.5M IPv4 and 140k IPv6. You need the "advanced feature license" to get access to that. -- Brandon Martin From Ryan.Hamel at quadranet.com Wed Oct 31 22:30:45 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 31 Oct 2018 22:30:45 +0000 Subject: Brocade SLX Internet Edge In-Reply-To: <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> Message-ID: 140K IPv6 equates to about 560K IPv4 routes, leaving the end user with 940K IPv4, which is not a lot of ceiling space considering we're at 741K IPv4 + and 60K IPv6 (240k IPv4 equivalent) now (941K total). This will leave you with 559K. I am not sure what the OP has for peering but with trying to keep 20% of TCAM space free, and keeping up with the current rate of rise according to CIDR-report, I'd say 4 years product lifetime if the OS has excellent TCAM management. Considering how the device looks like a switch and the SLX9850 uses Broadcom sillicon, I'm thinking it must use the Jericho chipset or some variant to get that kind of performance. In the end, your mileage may vary. -- Ryan Hamel Network Engineer ryan.hamel at quadranet.com | +1 (888) 578-2372 x201 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Wednesday, October 31, 2018 3:08 PM To: nanog at nanog.org Subject: Re: Brocade SLX Internet Edge On 10/31/18 4:56 PM, Aaron wrote: > It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes. That was changed earlier this year AFAIK. The website was slow to get updated but has been updated now. Current claim is 1.5M IPv4 and 140k IPv6. You need the "advanced feature license" to get access to that. -- Brandon Martin From morrowc.lists at gmail.com Wed Oct 31 22:37:38 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 1 Nov 2018 09:37:38 +1100 Subject: Brocade SLX Internet Edge In-Reply-To: References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> Message-ID: If you buy brocade, be sure to also by a license for securecrt so that backspace works over ssh... also, just don't do brocade... ever. On Thu, Nov 1, 2018 at 9:31 AM Ryan Hamel wrote: > 140K IPv6 equates to about 560K IPv4 routes, leaving the end user with > 940K IPv4, which is not a lot of ceiling space considering we're at 741K > IPv4 + and 60K IPv6 (240k IPv4 equivalent) now (941K total). This will > leave you with 559K. I am not sure what the OP has for peering but with > trying to keep 20% of TCAM space free, and keeping up with the current rate > of rise according to CIDR-report, I'd say 4 years product lifetime if the > OS has excellent TCAM management. > > Considering how the device looks like a switch and the SLX9850 uses > Broadcom sillicon, I'm thinking it must use the Jericho chipset or some > variant to get that kind of performance. In the end, your mileage may vary. > > -- > Ryan Hamel > Network Engineer > ryan.hamel at quadranet.com | +1 (888) 578-2372 x201 > QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin > Sent: Wednesday, October 31, 2018 3:08 PM > To: nanog at nanog.org > Subject: Re: Brocade SLX Internet Edge > > On 10/31/18 4:56 PM, Aaron wrote: > > It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes. > > That was changed earlier this year AFAIK. The website was slow to get > updated but has been updated now. Current claim is 1.5M IPv4 and 140k > IPv6. You need the "advanced feature license" to get access to that. > -- > Brandon Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Hamel at quadranet.com Wed Oct 31 22:42:44 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 31 Oct 2018 22:42:44 +0000 Subject: Brocade SLX Internet Edge In-Reply-To: References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> Message-ID: +1 SecureCRT in general, and don’t buy Brocade, I was happy when I got to pull out the last Foundry. -- Ryan Hamel Network Engineer ryan.hamel at quadranet.com | +1 (888) 578-2372 x201 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Wednesday, October 31, 2018 3:38 PM To: Ryan Hamel Cc: lists.nanog at monmotha.net; nanog list Subject: Re: Brocade SLX Internet Edge If you buy brocade, be sure to also by a license for securecrt so that backspace works over ssh... also, just don't do brocade... ever. On Thu, Nov 1, 2018 at 9:31 AM Ryan Hamel > wrote: 140K IPv6 equates to about 560K IPv4 routes, leaving the end user with 940K IPv4, which is not a lot of ceiling space considering we're at 741K IPv4 + and 60K IPv6 (240k IPv4 equivalent) now (941K total). This will leave you with 559K. I am not sure what the OP has for peering but with trying to keep 20% of TCAM space free, and keeping up with the current rate of rise according to CIDR-report, I'd say 4 years product lifetime if the OS has excellent TCAM management. Considering how the device looks like a switch and the SLX9850 uses Broadcom sillicon, I'm thinking it must use the Jericho chipset or some variant to get that kind of performance. In the end, your mileage may vary. -- Ryan Hamel Network Engineer ryan.hamel at quadranet.com | +1 (888) 578-2372 x201 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Wednesday, October 31, 2018 3:08 PM To: nanog at nanog.org Subject: Re: Brocade SLX Internet Edge On 10/31/18 4:56 PM, Aaron wrote: > It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes. That was changed earlier this year AFAIK. The website was slow to get updated but has been updated now. Current claim is 1.5M IPv4 and 140k IPv6. You need the "advanced feature license" to get access to that. -- Brandon Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Wed Oct 31 22:44:19 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 31 Oct 2018 18:44:19 -0400 Subject: Brocade SLX Internet Edge In-Reply-To: References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> Message-ID: On 10/31/18 6:30 PM, Ryan Hamel wrote: > 140K IPv6 equates to about 560K IPv4 routes, leaving the end user with 940K IPv4, which is not a lot of ceiling space considering we're at 741K IPv4 + and 60K IPv6 (240k IPv4 equivalent) now (941K total). This will leave you with 559K. I am not sure what the OP has for peering but with trying to keep 20% of TCAM space free, and keeping up with the current rate of rise according to CIDR-report, I'd say 4 years product lifetime if the OS has excellent TCAM management. I'm actually in the process of spec'ing one of these (if indeed it's appropriate) for a limited full-Internet-routes application and indeed these are the questions I've been asking of my rep. On "classic Netiron" (MLX, etc.) the numbers they often quoted were actually somewhat pessimistic in that they were one of their stock TCAM profiles, and you actually ended up with BOTH the IPv4 and IPv6 route counts simultaneously. > > Considering how the device looks like a switch and the SLX9850 uses Broadcom sillicon, I'm thinking it must use the Jericho chipset or some variant to get that kind of performance. In the end, your mileage may vary. I want to say it's a Qumran. They apparently have a bigger SLX pizzabox in the works that claims 4M IPv4 FIB and some stupid amount of buffering (8GB IIRC?). I know that's a Qumran, but that also seems like a truly huge amount of TCAM, so I dunno if that's with "typical aggregation" or some other shady trick. -- Brandon Martin From lists.nanog at monmotha.net Wed Oct 31 22:55:17 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 31 Oct 2018 18:55:17 -0400 Subject: Brocade SLX Internet Edge In-Reply-To: References: <07ab2c8a-2e49-3a3c-4db8-2873417df9ef@wholesaleinternet.net> <354e4a60-3a39-28e9-62f4-b4356ceb41d7@monmotha.net> Message-ID: <3abb1063-53cb-a09f-2d31-d8dc4feed02f@monmotha.net> On 10/31/18 6:37 PM, Christopher Morrow wrote: > If you buy brocade, be sure to also by a license for securecrt so that > backspace works over ssh... > also, just don't do brocade... ever. Works fine for me using OpenSSH in most Linux-y terminal emulators (Konsole, Linux console, Gnome terminal). I didn't do any special configuration. Now, over serial, enjoy your ctrl-H unless you do some remapping. I've never had any real problems with the hardware. The software can leave something to be desired especially on the old Foundry stuff that can't run the modern software, but if you just want it to push packets all day long, they seem to be pretty stable. Only bug I've been bitten with recently is apparent CAM corruption when manipulating large ACLs, but that was on the old (EOL) FCX platform. It's stable as long as you don't CHANGE things, and networks never change, right? (/s) Netiron seems to be more stable but definitely lacking control plane features, especially for MPLS, including some major ones that I gather the big C and J have had available for quite a while. I'm curious how things will diverge now that the "switching" line is at Ruckus/Arris while the "routing" line is at Extreme. I can't say I was ever a fan of Extreme's software, either, and I don't really have enough experience with Arris gear to comment. Certainly like any vendor's box, know what you're getting. It's a packet pusher. On a similar/related topic, has anyone used the Juniper MX204? It seems to occupy roughly the same space as the SLX9540. Less bandwidth, but JunOS is presumably more fully featured in terms of Internet-scale stuff one might want. -- Brandon Martin