From bhatton at htva.net Wed Feb 1 14:17:28 2017 From: bhatton at htva.net (Benjamin Hatton) Date: Wed, 1 Feb 2017 09:17:28 -0500 Subject: East coast outage Message-ID: Is anyone else seeing connectivity issues along the east coast? Our pipe through HE in NYC is showing loss to things behind most of Level3, and Qwest below Washington. *Ben Hatton* Network Engineer Haefele TV Inc. d:(607)589-8000 bhatton at htva.net www.htva.net From dbrisson at uvm.edu Wed Feb 1 14:22:30 2017 From: dbrisson at uvm.edu (Daniel Brisson) Date: Wed, 1 Feb 2017 14:22:30 +0000 Subject: East coast outage In-Reply-To: References: Message-ID: Definitely seeing problems here in Vermont. Reachability issues to amazon and other sites. Cogent BGP sessions have bounced, but still up. Right now things look normal, but it was definitely rocky over the last hour. -dan Dan Brisson Network Engineer University of Vermont > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Benjamin > Hatton > Sent: Wednesday, February 01, 2017 9:17 AM > To: nanog at nanog.org > Subject: East coast outage > > Is anyone else seeing connectivity issues along the east coast? Our pipe > through HE in NYC is showing loss to things behind most of Level3, and Qwest > below Washington. > > *Ben Hatton* > > Network Engineer > > Haefele TV Inc. > > d:(607)589-8000 > > bhatton at htva.net > > www.htva.net From raymond at prolocation.net Wed Feb 1 14:25:06 2017 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 1 Feb 2017 15:25:06 +0100 (CET) Subject: East coast outage In-Reply-To: References: Message-ID: Hello Ben, > Is anyone else seeing connectivity issues along the east coast? Our pipe > through HE in NYC is showing loss to things behind most of Level3, and > Qwest below Washington. > > *Ben Hatton* > > Network Engineer > > Haefele TV Inc. > > d:(607)589-8000 > > bhatton at htva.net > > www.htva.net We see the same, traffic going from Amsterdam towards HE heading USA is experiencing big packetloss at the moment. Traffic heading towards Ashburn seems affected from our point of view. Bye, Raymond. From Jeroen.Wunnink at gtt.net Wed Feb 1 14:26:26 2017 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Wed, 1 Feb 2017 14:26:26 +0000 Subject: East coast outage In-Reply-To: References: Message-ID: <1F7436A2-886F-438A-8C4D-BE074A58E4E1@gtt.net> There?s a major fiber outage between Ashburn, VA and Philadelphia, PA. Jeroen Wunnink IP Engineering manager office: +31.208.200.622 ext. 1011 Amsterdam Office www.gtt.net On 01/02/2017, 15:22, "NANOG on behalf of Daniel Brisson" wrote: Definitely seeing problems here in Vermont. Reachability issues to amazon and other sites. Cogent BGP sessions have bounced, but still up. Right now things look normal, but it was definitely rocky over the last hour. -dan Dan Brisson Network Engineer University of Vermont > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Benjamin > Hatton > Sent: Wednesday, February 01, 2017 9:17 AM > To: nanog at nanog.org > Subject: East coast outage > > Is anyone else seeing connectivity issues along the east coast? Our pipe > through HE in NYC is showing loss to things behind most of Level3, and Qwest > below Washington. > > *Ben Hatton* > > Network Engineer > > Haefele TV Inc. > > d:(607)589-8000 > > bhatton at htva.net > > www.htva.net From beecher at beecher.cc Wed Feb 1 14:30:59 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 1 Feb 2017 09:30:59 -0500 Subject: East coast outage In-Reply-To: References: Message-ID: I see a couple things that leads me to believe there's something afoot in NOVA as well. But not done with my first coffee, so unable to process any specifics yet. :) On Wed, Feb 1, 2017 at 9:25 AM, Raymond Dijkxhoorn wrote: > Hello Ben, > > > Is anyone else seeing connectivity issues along the east coast? Our pipe >> through HE in NYC is showing loss to things behind most of Level3, and >> Qwest below Washington. >> >> *Ben Hatton* >> >> Network Engineer >> >> Haefele TV Inc. >> >> d:(607)589-8000 >> >> bhatton at htva.net >> >> www.htva.net >> > > We see the same, traffic going from Amsterdam towards HE heading USA is > experiencing big packetloss at the moment. > > Traffic heading towards Ashburn seems affected from our point of view. > > Bye, > Raymond. > > From bhatton at htva.net Wed Feb 1 14:30:58 2017 From: bhatton at htva.net (Benjamin Hatton) Date: Wed, 1 Feb 2017 09:30:58 -0500 Subject: East coast outage In-Reply-To: References: Message-ID: > > Definitely seeing problems here in Vermont. Reachability issues to amazon > and other sites. Cogent BGP sessions have bounced, but still up. > Right now things look normal, but it was definitely rocky over the last > hour. > -dan Amazon was definitely on the list of sites with issues. I threw the switch over to a different provider so my CSR's wouldn't kill me. If you are seeing it start to seem more normal, might throw a test prefix back in an hour or so and see what it is doing. *Ben Hatton* Network Engineer Haefele TV Inc. d:(607)589-8000 bhatton at htva.net www.htva.net On Wed, Feb 1, 2017 at 9:22 AM, Daniel Brisson wrote: > Definitely seeing problems here in Vermont. Reachability issues to amazon > and other sites. Cogent BGP sessions have bounced, but still up. > > Right now things look normal, but it was definitely rocky over the last > hour. > > -dan > > > > Dan Brisson > Network Engineer > University of Vermont > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Benjamin > > Hatton > > Sent: Wednesday, February 01, 2017 9:17 AM > > To: nanog at nanog.org > > Subject: East coast outage > > > > Is anyone else seeing connectivity issues along the east coast? Our pipe > > through HE in NYC is showing loss to things behind most of Level3, and > Qwest > > below Washington. > > > > *Ben Hatton* > > > > Network Engineer > > > > Haefele TV Inc. > > > > d:(607)589-8000 > > > > bhatton at htva.net > > > > www.htva.net > From beecher at beecher.cc Wed Feb 1 14:37:36 2017 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 1 Feb 2017 09:37:36 -0500 Subject: East coast outage In-Reply-To: <1F7436A2-886F-438A-8C4D-BE074A58E4E1@gtt.net> References: <1F7436A2-886F-438A-8C4D-BE074A58E4E1@gtt.net> Message-ID: That'll do it. /refills coffee On Wed, Feb 1, 2017 at 9:26 AM, Jeroen Wunnink wrote: > There?s a major fiber outage between Ashburn, VA and Philadelphia, PA. > > > > Jeroen Wunnink > IP Engineering manager > office: +31.208.200.622 ext. 1011 > Amsterdam Office > www.gtt.net > > > > > On 01/02/2017, 15:22, "NANOG on behalf of Daniel Brisson" < > nanog-bounces at nanog.org on behalf of dbrisson at uvm.edu> wrote: > > Definitely seeing problems here in Vermont. Reachability issues to > amazon and other sites. Cogent BGP sessions have bounced, but still up. > > Right now things look normal, but it was definitely rocky over the > last hour. > > -dan > > > > Dan Brisson > Network Engineer > University of Vermont > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Benjamin > > Hatton > > Sent: Wednesday, February 01, 2017 9:17 AM > > To: nanog at nanog.org > > Subject: East coast outage > > > > Is anyone else seeing connectivity issues along the east coast? Our > pipe > > through HE in NYC is showing loss to things behind most of Level3, > and Qwest > > below Washington. > > > > *Ben Hatton* > > > > Network Engineer > > > > Haefele TV Inc. > > > > d:(607)589-8000 > > > > bhatton at htva.net > > > > www.htva.net > > > From scottf at gmail.com Wed Feb 1 14:41:10 2017 From: scottf at gmail.com (Scott Farber) Date: Wed, 1 Feb 2017 09:41:10 -0500 Subject: East coast outage In-Reply-To: References: Message-ID: I know Zayo has a cut somewhere between MD and DC, it's knocked a few things offline. Not sure if it's a shared conduit and who else may be affected. ETA for splicing crew is 1030 Eastern. On Wed, Feb 1, 2017 at 9:30 AM, Tom Beecher wrote: > I see a couple things that leads me to believe there's something afoot in > NOVA as well. > > But not done with my first coffee, so unable to process any specifics yet. > :) > > On Wed, Feb 1, 2017 at 9:25 AM, Raymond Dijkxhoorn < > raymond at prolocation.net> > wrote: > > > Hello Ben, > > > > > > Is anyone else seeing connectivity issues along the east coast? Our pipe > >> through HE in NYC is showing loss to things behind most of Level3, and > >> Qwest below Washington. > >> > >> *Ben Hatton* > >> > >> Network Engineer > >> > >> Haefele TV Inc. > >> > >> d:(607)589-8000 > >> > >> bhatton at htva.net > >> > >> www.htva.net > >> > > > > We see the same, traffic going from Amsterdam towards HE heading USA is > > experiencing big packetloss at the moment. > > > > Traffic heading towards Ashburn seems affected from our point of view. > > > > Bye, > > Raymond. > > > > > From Jeroen.Wunnink at gtt.net Wed Feb 1 15:06:51 2017 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Wed, 1 Feb 2017 15:06:51 +0000 Subject: East coast outage In-Reply-To: References: Message-ID: According to our optical noc they?re shooting new fiber as we speak. So now we wait. Jeroen Wunnink IP Engineering manager office: +31.208.200.622 ext. 1011 Amsterdam Office www.gtt.net On 01/02/2017, 15:41, "NANOG on behalf of Scott Farber" wrote: I know Zayo has a cut somewhere between MD and DC, it's knocked a few things offline. Not sure if it's a shared conduit and who else may be affected. ETA for splicing crew is 1030 Eastern. On Wed, Feb 1, 2017 at 9:30 AM, Tom Beecher wrote: > I see a couple things that leads me to believe there's something afoot in > NOVA as well. > > But not done with my first coffee, so unable to process any specifics yet. > :) > > On Wed, Feb 1, 2017 at 9:25 AM, Raymond Dijkxhoorn < > raymond at prolocation.net> > wrote: > > > Hello Ben, > > > > > > Is anyone else seeing connectivity issues along the east coast? Our pipe > >> through HE in NYC is showing loss to things behind most of Level3, and > >> Qwest below Washington. > >> > >> *Ben Hatton* > >> > >> Network Engineer > >> > >> Haefele TV Inc. > >> > >> d:(607)589-8000 > >> > >> bhatton at htva.net > >> > >> www.htva.net > >> > > > > We see the same, traffic going from Amsterdam towards HE heading USA is > > experiencing big packetloss at the moment. > > > > Traffic heading towards Ashburn seems affected from our point of view. > > > > Bye, > > Raymond. > > > > > From jhellenthal at dataix.net Wed Feb 1 16:24:28 2017 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 1 Feb 2017 10:24:28 -0600 Subject: PayCom Network Contact Request Message-ID: <20170201162429.991527219601@localhost> Could a network engineer from PayCom contact me off list when you get a chance please. Hoping to glean some subnet information from you that might help us out, if there is someone from PayCom on this list. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 500 bytes Desc: Message signed with OpenPGP URL: From applebaumt at ochin.org Wed Feb 1 22:47:50 2017 From: applebaumt at ochin.org (Tyler Applebaum) Date: Wed, 1 Feb 2017 22:47:50 +0000 Subject: T-Mobile Looking Glass Message-ID: <25440C4BF31A8E44872003195DEB57BE05D3D213@omail1.community-health.org> Hey all, just wondering if AS21928 has a looking glass. - Tyler From janusz at speedchecker.xyz Thu Feb 2 08:46:10 2017 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Thu, 2 Feb 2017 09:46:10 +0100 Subject: T-Mobile Looking Glass In-Reply-To: <25440C4BF31A8E44872003195DEB57BE05D3D213@omail1.community-health.org> References: <25440C4BF31A8E44872003195DEB57BE05D3D213@omail1.community-health.org> Message-ID: Hi Tyler, If you want to run some tests from AS21928, we do have some probes there. You can access them from this website - http://maplatency.com/ , just type in the ASN to the appropriate field and select a test you would like to run. Regards, Janusz Jezowicz *Speedchecker Ltd* *email*: janusz at speedchecker.xyz *skype*: jezowicz *phone*: +442032863573 *web*: www.speedchecker.xyz The Black Church, St. Mary?s Place, Dublin 7, D07 P4AX, Ireland On 1 February 2017 at 23:47, Tyler Applebaum wrote: > Hey all, just wondering if AS21928 has a looking glass. > > > - Tyler > From jcurran at arin.net Thu Feb 2 13:59:55 2017 From: jcurran at arin.net (John Curran) Date: Thu, 2 Feb 2017 13:59:55 +0000 Subject: ARIN on the Road - Little Rock, Arkansas USA on 7 March 2017 Message-ID: NANOGers - There is an "ARIN on the Road? one-day event coming up ?soon. The program covers a range of registry related topics including DNSSEC, RPKI, ARIN tools and services, IPv6 and more. We will be in Little Rock, Arkansas USA on 7 March 2017. This event is open to all and registration is free. If you are in the area, please come join us. For more information (including venue, agenda, and registration), go to https://www.arin.net/littlerock Thanks! /John John Curran President and CEO ARIN From sotnickd-nanog at ddv.com Thu Feb 2 16:32:14 2017 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 2 Feb 2017 08:32:14 -0800 Subject: IPv6-enabled multi-factor providers (not DUO) Message-ID: Hi NANOG, (Apologies if this is slightly off-topic; there are a lot of IPv6-advocates here who might have some insights). At my day job, we use Duo Security for MFA. It works well, with the caveats that it's cloud-based and heavily dependent on Amazon AWS. We had an IPv4 outage last weekend and of course our Duo MFA only supports IPv4 and given their dependence on AWS I'm not hopeful that they'll have IPv6 access to their API servers any time this year. If they had, my weekend would have gone a lot easier. What MFA alternatives are out there that support IPv6? If we found a suitable alternative, I'm sure we'd consider shifting our business their way. Thanks! -Dave From rvandolson at esri.com Thu Feb 2 17:54:39 2017 From: rvandolson at esri.com (Ray Van Dolson) Date: Thu, 2 Feb 2017 09:54:39 -0800 Subject: .gov / census.gov contact Message-ID: <20170202175439.GA10624@esri.com> One of our external hide NATs has been blocked by the census.gov WAF. Would someone contact me off-list about this or help point me to the proper POC? Am thinking responsibility may lie at the higher .gov level... TIA, Ray From cb.list6 at gmail.com Thu Feb 2 18:22:52 2017 From: cb.list6 at gmail.com (Ca By) Date: Thu, 2 Feb 2017 10:22:52 -0800 Subject: DOT FRA website broken on ipv6 Message-ID: Anyone have a contact at DOT or FRA that can solve this? It would be really nice if they remove the DNS AAAA record on www.fra.dot.gov until it works correctly, customers are complaining wget -6 -T 5 www.fra.dot.gov converted 'http://www.fra.dot.gov' (ANSI_X3.4-1968) -> ' http://www.fra.dot.gov' (UTF-8) --2017-02-02 13:20:39-- http://www.fra.dot.gov/ Resolving www.fra.dot.gov (www.fra.dot.gov)... 2001:19e8:d:0:204:68:194:250 Connecting to www.fra.dot.gov (www.fra.dot.gov)|2001:19e8:d:0:204:68:194:250|:80... failed: No route to host. traceroute www.fra.dot.gov traceroute to www.fra.dot.gov (204.68.194.250), 30 hops max, 60 byte packets^C cbyrne at uranus:~$ traceroute6 www.fra.dot.gov traceroute to www.fra.dot.gov (2001:19e8:d:0:204:68:194:250), 30 hops max, 80 byte packets 1 * * * 2 xe-0-1-0-17.r04.atlnga05.us.bb.gin.ntt.net (2001:418:0:5000::622) 0.865 ms 1.043 ms 1.382 ms 3 verio-gw.attga.ipv6.att.net (2001:1890:1fff:506:192:205:36:157) 1.601 ms 1.619 ms 3.665 ms 4 attga21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:141:234) 22.223 ms 22.139 ms 22.151 ms 5 nsvtn22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:2:6) 20.928 ms 20.931 ms 20.934 ms 6 cl2oh21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:28:74) 24.414 ms 23.878 ms 23.638 ms 7 cgcil21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:2:225) 22.245 ms 22.051 ms 21.976 ms 8 2001:1890:ff:ffff:12:122:120:179 (2001:1890:ff:ffff:12:122:120:179) 20.694 ms 20.201 ms 21.323 ms 9 2001:1890:c00:2407::113f:b38f (2001:1890:c00:2407::113f:b38f) 20.340 ms 20.145 ms 20.014 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * From morrowc.lists at gmail.com Thu Feb 2 19:41:56 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Feb 2017 14:41:56 -0500 Subject: IPv6-enabled multi-factor providers (not DUO) In-Reply-To: References: Message-ID: On Thu, Feb 2, 2017 at 11:32 AM, David Sotnick wrote: > Hi NANOG, > > (Apologies if this is slightly off-topic; there are a lot of IPv6-advocates > here who might have some insights). > > At my day job, we use Duo Security for MFA. It works well, with the caveats > that it's cloud-based and heavily dependent on Amazon AWS. > > https://aws.amazon.com/blogs/aws/new-ipv6-support-for-ec2-instances-in-virtual-private-clouds/ should be all set, right? > We had an IPv4 outage last weekend and of course our Duo MFA only supports > IPv4 and given their dependence on AWS I'm not hopeful that they'll have > IPv6 access to their API servers any time this year. If they had, my > weekend would have gone a lot easier. > > What MFA alternatives are out there that support IPv6? If we found a > suitable alternative, I'm sure we'd consider shifting our business their > way. > > Thanks! > > -Dave > From marka at isc.org Thu Feb 2 20:25:41 2017 From: marka at isc.org (Mark Andrews) Date: Fri, 03 Feb 2017 07:25:41 +1100 Subject: DOT FRA website broken on ipv6 In-Reply-To: Your message of "Thu, 02 Feb 2017 10:22:52 -0800." References: Message-ID: <20170202202541.A6D386153BB3@rock.dv.isc.org> In message , Ca By writes: > Anyone have a contact at DOT or FRA that can solve this? It would be > really nice if they remove the DNS AAAA record on www.fra.dot.gov until it > works correctly, customers are complaining While the web site should be fixed / made reachable it shouldn't matter if a single path to a site is down. This is basically due to crappy multi-home support in clients. You don't have to wait minutes to start to fallover to alternate addresses. Tell your clients to install modern browsers that do happy eyeballs. Fast failover should be in every application. It is trivial to do for TCP based applications. https://users.isc.org/~marka/ has sample code showing how to do it. Don't choose DNS64/NAT64 as your IPv6-only solution as it removes the ability to fallback to IPv4 on IPv6 failure. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From scottf at gmail.com Thu Feb 2 13:04:00 2017 From: scottf at gmail.com (Scott Farber) Date: Thu, 2 Feb 2017 08:04:00 -0500 Subject: East coast outage In-Reply-To: References: Message-ID: >From our ticket with Zayo: *Reason for Outage Summary*: The cause of this issue was traced to an active construction site. 50' of 432 ct cable in 8 conduits were damaged. OSP was able to repair all conduits and pull and splice new fiber cable to make this repair. On Wed, Feb 1, 2017 at 10:06 AM, Jeroen Wunnink wrote: > According to our optical noc they?re shooting new fiber as we speak. So > now we wait. > > > > > Jeroen Wunnink > IP Engineering manager > office: +31.208.200.622 ext. 1011 > Amsterdam Office > www.gtt.net > > > > > On 01/02/2017, 15:41, "NANOG on behalf of Scott Farber" < > nanog-bounces at nanog.org on behalf of scottf at gmail.com> wrote: > > I know Zayo has a cut somewhere between MD and DC, it's knocked a few > things offline. Not sure if it's a shared conduit and who else may be > affected. ETA for splicing crew is 1030 Eastern. > > On Wed, Feb 1, 2017 at 9:30 AM, Tom Beecher > wrote: > > > I see a couple things that leads me to believe there's something > afoot in > > NOVA as well. > > > > But not done with my first coffee, so unable to process any > specifics yet. > > :) > > > > On Wed, Feb 1, 2017 at 9:25 AM, Raymond Dijkxhoorn < > > raymond at prolocation.net> > > wrote: > > > > > Hello Ben, > > > > > > > > > Is anyone else seeing connectivity issues along the east coast? > Our pipe > > >> through HE in NYC is showing loss to things behind most of > Level3, and > > >> Qwest below Washington. > > >> > > >> *Ben Hatton* > > >> > > >> Network Engineer > > >> > > >> Haefele TV Inc. > > >> > > >> d:(607)589-8000 > > >> > > >> bhatton at htva.net > > >> > > >> www.htva.net > > >> > > > > > > We see the same, traffic going from Amsterdam towards HE heading > USA is > > > experiencing big packetloss at the moment. > > > > > > Traffic heading towards Ashburn seems affected from our point of > view. > > > > > > Bye, > > > Raymond. > > > > > > > > > > > From don at adinine.com Thu Feb 2 16:12:25 2017 From: don at adinine.com (Don) Date: Thu, 02 Feb 2017 11:12:25 -0500 Subject: Telia network quality Message-ID: I heard Telia's quality had been on the decline lately as they were signing on lots of high-capacity new customers, and Cloudflare had some complaint about them a few months prior too. Does anybody have any insight into whether this is still the case? I was trying to evaluate whether Telia would be a good carrier to switch over to as a primary provider, as their pricing does look pretty attractive. B/R Don From baldur.norddahl at gmail.com Thu Feb 2 22:12:05 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 2 Feb 2017 23:12:05 +0100 Subject: East coast outage In-Reply-To: References: Message-ID: Should we not be able to expect that these kind of failures are handled seamlessly by rerouting through redundant paths? A little extra latency ok. Packet loss, you failed to plan and upgrade your redundancy correctly. Regards Baldur Den 2. feb. 2017 21.34 skrev "Scott Farber" : >From our ticket with Zayo: *Reason for Outage Summary*: The cause of this issue was traced to an active construction site. 50' of 432 ct cable in 8 conduits were damaged. OSP was able to repair all conduits and pull and splice new fiber cable to make this repair. On Wed, Feb 1, 2017 at 10:06 AM, Jeroen Wunnink wrote: > According to our optical noc they?re shooting new fiber as we speak. So > now we wait. > > > > > Jeroen Wunnink > IP Engineering manager > office: +31.208.200.622 ext. 1011 > Amsterdam Office > www.gtt.net > > > > > On 01/02/2017, 15:41, "NANOG on behalf of Scott Farber" < > nanog-bounces at nanog.org on behalf of scottf at gmail.com> wrote: > > I know Zayo has a cut somewhere between MD and DC, it's knocked a few > things offline. Not sure if it's a shared conduit and who else may be > affected. ETA for splicing crew is 1030 Eastern. > > On Wed, Feb 1, 2017 at 9:30 AM, Tom Beecher > wrote: > > > I see a couple things that leads me to believe there's something > afoot in > > NOVA as well. > > > > But not done with my first coffee, so unable to process any > specifics yet. > > :) > > > > On Wed, Feb 1, 2017 at 9:25 AM, Raymond Dijkxhoorn < > > raymond at prolocation.net> > > wrote: > > > > > Hello Ben, > > > > > > > > > Is anyone else seeing connectivity issues along the east coast? > Our pipe > > >> through HE in NYC is showing loss to things behind most of > Level3, and > > >> Qwest below Washington. > > >> > > >> *Ben Hatton* > > >> > > >> Network Engineer > > >> > > >> Haefele TV Inc. > > >> > > >> d:(607)589-8000 > > >> > > >> bhatton at htva.net > > >> > > >> www.htva.net > > >> > > > > > > We see the same, traffic going from Amsterdam towards HE heading > USA is > > > experiencing big packetloss at the moment. > > > > > > Traffic heading towards Ashburn seems affected from our point of > view. > > > > > > Bye, > > > Raymond. > > > > > > > > > > > From sethm at rollernet.us Thu Feb 2 22:36:16 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 2 Feb 2017 14:36:16 -0800 Subject: East coast outage In-Reply-To: References: Message-ID: <4a56f633-2696-82a0-e7be-97395b79a843@rollernet.us> On 2/2/17 14:12, Baldur Norddahl wrote: > Should we not be able to expect that these kind of failures are handled > seamlessly by rerouting through redundant paths? A little extra latency ok. > Packet loss, you failed to plan and upgrade your redundancy correctly. Cost savings. ~Seth From sotnickd-nanog at ddv.com Fri Feb 3 01:52:33 2017 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 2 Feb 2017 17:52:33 -0800 Subject: IPv6-enabled multi-factor providers (not DUO) In-Reply-To: References: Message-ID: Ahhh, a recent development ? that's great news! Yes, it should be exceedingly simple for Duo to implement IPv6 :-) Thanks for the edification, all! -Dave On Thu, Feb 2, 2017 at 11:41 AM, Christopher Morrow wrote: > > > On Thu, Feb 2, 2017 at 11:32 AM, David Sotnick > wrote: > >> Hi NANOG, >> >> (Apologies if this is slightly off-topic; there are a lot of >> IPv6-advocates >> here who might have some insights). >> >> At my day job, we use Duo Security for MFA. It works well, with the >> caveats >> that it's cloud-based and heavily dependent on Amazon AWS. >> >> > https://aws.amazon.com/blogs/aws/new-ipv6-support-for-ec2- > instances-in-virtual-private-clouds/ > > should be all set, right? > > >> We had an IPv4 outage last weekend and of course our Duo MFA only supports >> IPv4 and given their dependence on AWS I'm not hopeful that they'll have >> IPv6 access to their API servers any time this year. If they had, my >> weekend would have gone a lot easier. >> >> What MFA alternatives are out there that support IPv6? If we found a >> suitable alternative, I'm sure we'd consider shifting our business their >> way. >> >> Thanks! >> >> -Dave >> > > From erich at gotfusion.net Fri Feb 3 02:55:21 2017 From: erich at gotfusion.net (Kaiser, Erich) Date: Thu, 2 Feb 2017 20:55:21 -0600 Subject: Telia network quality In-Reply-To: References: Message-ID: I would say that information is not 100% accurate. We use Telia for waves nationwide and also have several DIA ingest(transit) points from them. If anything, the IRU carriers they are using may have a problem sometimes due to fiber cuts, but that is why you build redundant paths. They are very ontop of the ball when one of the waves goes down. We actually don't utilize a ton of their transit due to the nature of our network design, because we are connected to all of the major IXs. Erich Kaiser The Fusion Network erich at gotfusion.net Office: 630-621-4804 Cell: 630-777-9291 On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > I heard Telia's quality had been on the decline lately as they were > signing on lots of high-capacity new customers, and Cloudflare had some > complaint about them a few months prior too. Does anybody have any insight > into whether this is still the case? I was trying to evaluate whether Telia > would be a good carrier to switch over to as a primary provider, as their > pricing does look pretty attractive. > > B/R > Don From kotikalapudi.sriram at nist.gov Fri Feb 3 17:00:04 2017 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Fri, 3 Feb 2017 17:00:04 +0000 Subject: BGP route processing speed In-Reply-To: <5890C175.9040307@sloc.de> References: <5890C175.9040307@sloc.de> Message-ID: >From: Sebastian Spies [mailto:s+Mailinglisten.nanog at sloc.de] > >my BSc thesis from 2010 might be relevant to what you are looking for. > >https://drive.google.com/file/d/0B5kLBHCcFJjFZk5RTUtwbUstbm8/view?usp=sharing Thanks, Sebastian. Good study. Your convergence time estimates (e.g. Table 2, p. 38) for route servers are interesting and also consistent with the AMS-IX study in 2012 (the latter in realistic IXP scenarios). But I am still interested in any pointers to BGP router measurements in ISP/provider edge scenarios. Sriram >Sriram, Kotikalapudi (Fed) schrieb: >> I am interested in measurements related to BGP route processing speed >> (i.e. routing engine capacity in terms of routes or updates processed per second). >> Folks from AMS-IX did an interesting study in 2012 >> in their Route Server / IXP environment. >> https://ams-ix.net/downloads/ams-ix-route-server-implementations-performance.pdf >> >> Are there other measurement studies available >> on this topic, especially in ISP/PE router scenarios, >> including BGP policy processing, best path selection, route filtering, etc.? >> Will appreciate much if you can share some pointers. >> >> Sriram From cscora at apnic.net Fri Feb 3 18:02:47 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Feb 2017 04:02:47 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170203180247.5950DC44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 04 Feb, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 633950 Prefixes after maximum aggregation (per Origin AS): 247336 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 305776 Total ASes present in the Internet Routing Table: 56129 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 48582 Origin ASes announcing only one prefix: 21685 Transit ASes present in the Internet Routing Table: 7547 Transit-only ASes present in the Internet Routing Table: 216 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 79 Numnber of instances of unregistered ASNs: 80 Number of 32-bit ASNs allocated by the RIRs: 17163 Number of 32-bit ASNs visible in the Routing Table: 13334 Prefixes from 32-bit ASNs in the Routing Table: 53723 Number of bogon 32-bit ASNs visible in the Routing Table: 46 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 400 Number of addresses announced to Internet: 2832448228 Equivalent to 168 /8s, 211 /16s and 186 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 211737 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 172877 Total APNIC prefixes after maximum aggregation: 49602 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 172226 Unique aggregates announced from the APNIC address blocks: 71217 APNIC Region origin ASes present in the Internet Routing Table: 7818 APNIC Prefixes per ASN: 22.03 APNIC Region origin ASes announcing only one prefix: 2189 APNIC Region transit ASes present in the Internet Routing Table: 1118 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2650 Number of APNIC addresses announced to Internet: 760164996 Equivalent to 45 /8s, 79 /16s and 50 /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-137529 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: 193441 Total ARIN prefixes after maximum aggregation: 92906 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 195881 Unique aggregates announced from the ARIN address blocks: 89974 ARIN Region origin ASes present in the Internet Routing Table: 17792 ARIN Prefixes per ASN: 11.01 ARIN Region origin ASes announcing only one prefix: 6646 ARIN Region transit ASes present in the Internet Routing Table: 1767 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1749 Number of ARIN addresses announced to Internet: 1104014496 Equivalent to 65 /8s, 205 /16s and 236 /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-397212 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: 168694 Total RIPE prefixes after maximum aggregation: 83741 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 164013 Unique aggregates announced from the RIPE address blocks: 99601 RIPE Region origin ASes present in the Internet Routing Table: 23643 RIPE Prefixes per ASN: 6.94 RIPE Region origin ASes announcing only one prefix: 10969 RIPE Region transit ASes present in the Internet Routing Table: 3344 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5514 Number of RIPE addresses announced to Internet: 709672576 Equivalent to 42 /8s, 76 /16s and 190 /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-207259 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: 82376 Total LACNIC prefixes after maximum aggregation: 17349 LACNIC Deaggregation factor: 4.75 Prefixes being announced from the LACNIC address blocks: 83458 Unique aggregates announced from the LACNIC address blocks: 37868 LACNIC Region origin ASes present in the Internet Routing Table: 5618 LACNIC Prefixes per ASN: 14.86 LACNIC Region origin ASes announcing only one prefix: 1555 LACNIC Region transit ASes present in the Internet Routing Table: 1031 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3135 Number of LACNIC addresses announced to Internet: 171072576 Equivalent to 10 /8s, 50 /16s and 92 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16450 Total AfriNIC prefixes after maximum aggregation: 3679 AfriNIC Deaggregation factor: 4.47 Prefixes being announced from the AfriNIC address blocks: 17972 Unique aggregates announced from the AfriNIC address blocks: 6769 AfriNIC Region origin ASes present in the Internet Routing Table: 1016 AfriNIC Prefixes per ASN: 17.69 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 202 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 286 Number of AfriNIC addresses announced to Internet: 87082496 Equivalent to 5 /8s, 48 /16s and 198 /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 5544 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3723 391 255 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2979 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2717 1501 542 BSNL-NIB National Internet Backbone, IN 9808 2282 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2059 421 220 TATACOMM-AS TATA Communications formerl 45899 1918 1284 99 VNPT-AS-VN VNPT Corp, VN 4808 1641 1788 450 CHINA169-BJ China Unicom Beijing Provin 24560 1564 567 248 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd 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 22773 3625 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3349 1333 83 SHAW - Shaw Communications Inc., CA 18566 2192 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2094 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1968 2034 405 CHARTER-NET-HKY-NC - Charter Communicat 209 1715 5067 638 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1684 317 470 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 16509 1634 3048 536 AMAZON-02 - Amazon.com, Inc., US 701 1596 10613 658 UUNET - MCI Communications Services, In 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 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3021 1136 2140 AKAMAI-ASN1 , US 9121 2170 1708 97 TTNET , TR 34984 1992 327 378 TELLCOM-AS , TR 13188 1614 99 62 TRIOLAN , UA 8551 1602 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1448 1033 50 UNI2-AS , ES 6849 1322 355 22 UKRTELNET , UA 8402 1093 544 15 CORBINA-AS OJSC "Vimpelcom", RU 9198 1080 352 24 KAZTELECOM-AS , KZ 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 10620 3542 547 139 Telmex Colombia S.A., CO 26615 3016 2329 44 Tim Celular S.A., BR 8151 2482 3381 557 Uninet S.A. de C.V., MX 11830 1804 368 66 Instituto Costarricense de Electricidad 6503 1570 437 54 Axtel, S.A.B. de C.V., MX 7303 1526 974 254 Telecom Argentina S.A., AR 6147 1350 377 27 Telefonica del Peru S.A.A., PE 28573 1055 2271 178 CLARO S.A., BR 3816 1005 481 176 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 982 280 35 Techtel LMDS Comunicaciones Interactiva 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 1294 398 42 LINKdotNET-AS, EG 36903 719 361 123 MT-MPLS, MA 37611 689 67 6 Afrihost, ZA 36992 587 1373 25 ETISALAT-MISR, EG 24835 490 658 16 RAYA-AS, EG 8452 464 1474 16 TE-AS TE-AS, EG 37492 392 316 74 ORANGE-TN, TN 29571 367 36 10 CITelecom-AS, CI 15399 325 35 6 WANANCHI-KE, KE 2018 276 327 74 TENET-1, ZA 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 4538 5544 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3723 391 255 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3625 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3542 547 139 Telmex Colombia S.A., CO 6327 3349 1333 83 SHAW - Shaw Communications Inc., CA 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3021 1136 2140 AKAMAI-ASN1 , US 26615 3016 2329 44 Tim Celular S.A., BR 17974 2979 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3625 3474 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3723 3468 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3542 3403 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3349 3266 SHAW - Shaw Communications Inc., CA 26615 3016 2972 Tim Celular S.A., BR 17974 2979 2908 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9808 2282 2249 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2717 2175 BSNL-NIB National Internet Backbone, IN 18566 2192 2083 MEGAPATH5-US - MegaPath Corporation, 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 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.165.128.0/24 395475 SCSALSKA - Southeast Communication Services LLC, US 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 41.73.21.0/24 37004 Suburban-Broadband-AS, NG 41.73.22.0/24 37004 Suburban-Broadband-AS, NG 41.73.23.0/24 37004 Suburban-Broadband-AS, NG 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:16 /9:13 /10:36 /11:103 /12:276 /13:534 /14:1046 /15:1795 /16:13180 /17:7772 /18:12993 /19:25190 /20:38053 /21:40726 /22:73958 /23:62472 /24:354420 /25:560 /26:414 /27:295 /28:34 /29:19 /30:18 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3145 3349 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2822 3625 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2534 3016 Tim Celular S.A., BR 18566 2085 2192 MEGAPATH5-US - MegaPath Corporation, US 9121 1536 2170 TTNET , TR 30036 1495 1684 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1448 3542 Telmex Colombia S.A., CO 6389 1392 2094 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1359 1614 TRIOLAN , UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1599 2:823 4:25 5:2448 6:32 8:1046 12:1815 13:72 14:1772 15:22 16:2 17:102 18:128 19:1 20:52 23:1989 24:1843 27:2376 31:1870 32:89 33:2 34:1 35:18 36:356 37:2528 38:1314 39:43 40:100 41:2889 42:450 43:1923 44:61 45:2348 46:2564 47:109 49:1212 50:941 51:18 52:702 54:356 55:5 56:4 57:40 58:1605 59:984 60:389 61:1894 62:1503 63:1929 64:4558 65:2188 66:4412 67:2225 68:1169 69:3320 70:1301 71:570 72:2051 74:2597 75:401 76:413 77:1433 78:1534 79:1281 80:1378 81:1398 82:983 83:727 84:873 85:1684 86:482 87:1129 88:778 89:2049 90:208 91:6124 92:954 93:2375 94:2346 95:2793 96:572 97:357 98:938 99:91 100:148 101:1242 103:13445 104:2690 105:158 106:478 107:1524 108:789 109:2541 110:1288 111:1667 112:1149 113:1300 114:1026 115:1726 116:1725 117:1633 118:2061 119:1565 120:944 121:1099 122:2272 123:2034 124:1541 125:1821 128:717 129:617 130:412 131:1386 132:522 133:189 134:530 135:213 136:386 137:415 138:1868 139:490 140:615 141:518 142:732 143:910 144:766 145:167 146:1013 147:657 148:1407 149:569 150:688 151:929 152:722 153:313 154:754 155:962 156:546 157:579 158:438 159:1390 160:566 161:725 162:2473 163:531 164:780 165:1144 166:362 167:1263 168:2465 169:732 170:2717 171:273 172:933 173:1825 174:795 175:711 176:1770 177:4227 178:2464 179:1657 180:2097 181:1993 182:2204 183:1019 184:827 185:8630 186:3202 187:2723 188:2350 189:1813 190:8134 191:1949 192:9329 193:5771 194:4622 195:3842 196:1946 197:1238 198:5582 199:5834 200:7315 201:4136 202:10062 203:9880 204:4461 205:2768 206:2974 207:3158 208:3998 209:3884 210:3924 211:2099 212:2799 213:2457 214:849 215:64 216:5808 217:1985 218:831 219:606 220:1688 221:902 222:726 223:1156 End of report From brough at netblazr.com Fri Feb 3 19:35:23 2017 From: brough at netblazr.com (Brough Turner) Date: Fri, 3 Feb 2017 14:35:23 -0500 Subject: Weekly Routing Table Report In-Reply-To: <20170203180247.5950DC44A1@thyme.apnic.net> References: <20170203180247.5950DC44A1@thyme.apnic.net> Message-ID: On Fri, Feb 3, 2017 at 1:02 PM, Routing Analysis Role Account < cscora at apnic.net> wrote: > Transit ASes present in the Internet Routing Table: 7547 Last week there were 6561. I've seen the number jump a few or a dozen in one week, but nearly 1000 in one week?? What am I missing? Thanks, Brough Brough Turner netBlazr Inc. ? Free your Broadband! Mobile: 617-285-0433 <(617)%20285-0433> Skype: brough netBlazr Inc. | Google+ | Twitter | LinkedIn | Facebook | Blog | Personal website From pfsinoz at gmail.com Sat Feb 4 08:06:27 2017 From: pfsinoz at gmail.com (Philip Smith) Date: Sat, 4 Feb 2017 18:06:27 +1000 Subject: Weekly Routing Table Report In-Reply-To: References: <20170203180247.5950DC44A1@thyme.apnic.net> Message-ID: <403cdcbc-d9fd-7109-9bf4-1a6d5edb4c3c@gmail.com> Hello Brough, Very well spotted!! :-) I finally fixed a problem in my analysis programme which was miscounting the extended range of 32-bit ASNs (those from 65536 and above). It wasn't counting them at all in fact, something spotted by one of our industry colleagues a couple of months back. So the jump is caused by that. Misery for me now is I have to go back through a few years of daily reports and figure out when I made the change to cause the breakage. And rerun everything (sigh). The other bonus of the fix is that I'm dealing with 32-bit ASNs properly now - I'm catching the 65536 to 131071 range as bogons, and also catching any origin ASNs from above 458752 as bogons too. Thanks! philip -- Brough Turner wrote on 4/2/17 05:35 : > On Fri, Feb 3, 2017 at 1:02 PM, Routing Analysis Role Account < > cscora at apnic.net> wrote: > >> Transit ASes present in the Internet Routing Table: 7547 > > > Last week there were 6561. > I've seen the number jump a few or a dozen in one week, but nearly 1000 in > one week?? > What am I missing? > > Thanks, > Brough > > Brough Turner > netBlazr Inc. ? Free your Broadband! > Mobile: 617-285-0433 <(617)%20285-0433> Skype: brough > netBlazr Inc. | Google+ > | Twitter > | LinkedIn > | Facebook > | Blog > | Personal website > > From jhellenthal at dataix.net Sat Feb 4 22:38:30 2017 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sat, 4 Feb 2017 16:38:30 -0600 Subject: 403 Labs "Sikich" Message-ID: <20170204223830.3F443724A32F@localhost> Is anyone from 403 Labs present on this list ? We have a stuck automated test that was never turned off that is effecting our customers and coming from your network to a shared IP block in Chicago. Contact me off list for details please. Thanks From jhellenthal at dataix.net Sat Feb 4 23:18:47 2017 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sat, 4 Feb 2017 17:18:47 -0600 Subject: 403 Labs "Sikich" In-Reply-To: <20170204223830.3F443724A32F@localhost> References: <20170204223830.3F443724A32F@localhost> Message-ID: <20170204231847.EF024724B0CC@localhost> Situation has been resolved. > On Feb 4, 2017, at 16:38, Jason Hellenthal wrote: > > Is anyone from 403 Labs present on this list ? > > We have a stuck automated test that was never turned off that is effecting our customers and coming from your network to a shared IP block in Chicago. > > Contact me off list for details please. > > > Thanks From carl at five-ten-sg.com Sat Feb 4 23:56:30 2017 From: carl at five-ten-sg.com (Carl Byington) Date: Sat, 04 Feb 2017 15:56:30 -0800 Subject: DOT FRA website broken on ipv6 In-Reply-To: References: Message-ID: <1486252590.8682.13.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2017-02-02 at 10:22 -0800, Ca By wrote: > Anyone have a contact at DOT or FRA that can solve this? It would be > really nice if they remove the DNS AAAA record on www.fra.dot.gov > until it works correctly, customers are complaining Their SOA record suggests hostmaster at dot.gov. You could temporarily (ab)use a bind rpz zone to override that. www.fra.dot.gov A 204.68.194.250 That rpz A record will suppress the real AAAA record. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAliWaigACgkQL6j7milTFsFnagCcD8Cxq6rW9fmP4yREA2Vbt4FU XQQAniIhLcnUUmsfzkyY9mZzsBto2wKm =ePCp -----END PGP SIGNATURE----- From greg at gregsowell.com Sat Feb 4 23:36:52 2017 From: greg at gregsowell.com (Greg Sowell) Date: Sat, 4 Feb 2017 17:36:52 -0600 Subject: Telia network quality In-Reply-To: References: Message-ID: I've been using them out of Dallas for about 2.5 years now with very good success. Their NOC has been top notch in responding to our issues, though I've seen repeated peering issues for them with a single provider, but who's to say that's their fault and not the other parties? On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich wrote: > I would say that information is not 100% accurate. We use Telia for waves > nationwide and also have several DIA ingest(transit) points from them. If > anything, the IRU carriers they are using may have a problem sometimes due > to fiber cuts, but that is why you build redundant paths. > > They are very ontop of the ball when one of the waves goes down. We > actually don't utilize a ton of their transit due to the nature of our > network design, because we are connected to all of the major IXs. > > Erich Kaiser > The Fusion Network > erich at gotfusion.net > Office: 630-621-4804 > Cell: 630-777-9291 > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > > > I heard Telia's quality had been on the decline lately as they were > > signing on lots of high-capacity new customers, and Cloudflare had some > > complaint about them a few months prior too. Does anybody have any > insight > > into whether this is still the case? I was trying to evaluate whether > Telia > > would be a good carrier to switch over to as a primary provider, as their > > pricing does look pretty attractive. > > > > B/R > > Don > -- -------------------------------- GregSowell.com TheBrothersWISP.com StrayaNet.com From davidpeahi at gmail.com Mon Feb 6 01:21:21 2017 From: davidpeahi at gmail.com (david peahi) Date: Sun, 5 Feb 2017 17:21:21 -0800 Subject: ATT-Level 3 Peering Message-ID: We're seeing frequent dropped packets between ATT and Level 3 in Atlanta with traffic sourced from an ATT user destined for Microsoft Office 365, making Office 365 apps unusable during critical business hours. Anyone else have this problem with ATT? From mpetach at netflight.com Mon Feb 6 13:09:32 2017 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 6 Feb 2017 05:09:32 -0800 Subject: Peering BOF/Peering social @NANOG69? Message-ID: I'm squinting at the Guidebook for NANOG69, and I don't seem to see any peering BOF or peering social this time around. Am I being blind again, and it's on the agenda somewhere but I'm just overlooking it? Pointers in the right direction would be appreciated. Thanks! :) Matt From bob at FiberInternetCenter.com Mon Feb 6 13:51:24 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 6 Feb 2017 05:51:24 -0800 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: References: Message-ID: On that same topic, Peering, I would like to see the green peering dot for name badges. Kind of "one" of the fundamental things that NANOG came into existing over. Thank You Bob Evans CTO > I'm squinting at the Guidebook for NANOG69, > and I don't seem to see any peering BOF or > peering social this time around. Am I being > blind again, and it's on the agenda somewhere > but I'm just overlooking it? > Pointers in the right direction would be appreciated. > > Thanks! :) > > Matt > From carlosm3011 at gmail.com Mon Feb 6 14:17:20 2017 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Mon, 06 Feb 2017 12:17:20 -0200 Subject: BGP IP prefix hijacking In-Reply-To: References: Message-ID: <122D4F25-B030-4139-974D-D9F15AF7598E@gmail.com> We use a mix of BGPMon and RPKI+RIPE Validator. On 30 Jan 2017, at 4:41, Nagarjun Govindraj via NANOG wrote: > Hi All, > > I am planning to write a tool to detect real time BGP IP prefix hijacking. > I am glad to know some of the open problems faced by > providers/companies/community. > I would like to know how the community is currently dealing and mitigating > with such problems. > It will be very helpful to know some of the adopted strategies by the > community to detect bgp IP prefix hijacking and problems that are yet to be > solved. > Also I would like to know some of the very well industry standard open > source tools used in the area of BGP which makes life easier. > > Regards, > Nagarjun From Charles.Manser at charter.com Mon Feb 6 13:04:34 2017 From: Charles.Manser at charter.com (Manser, Charles J) Date: Mon, 6 Feb 2017 13:04:34 +0000 Subject: ticketmaster.com 403 Forbidden Message-ID: List, It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? If anyone from Ticketmaster could reach out to me off-list, it would be helpful. Charles Manser | Principal Engineer I, Network Security Charles.Manser at charter.com E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From tshaw at oitc.com Mon Feb 6 15:26:50 2017 From: tshaw at oitc.com (TR Shaw) Date: Mon, 6 Feb 2017 10:26:50 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: Message-ID: <72B552F6-A35B-4DEE-8267-937674322441@oitc.com> Can get to them fine from Florida via level3. Tom? > On Feb 6, 2017, at 8:04 AM, Manser, Charles J wrote: > > List, > > It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? > > If anyone from Ticketmaster could reach out to me off-list, it would be helpful. > Charles Manser | Principal Engineer I, Network Security > Charles.Manser at charter.com > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From aplato at coldwater.org Mon Feb 6 15:33:51 2017 From: aplato at coldwater.org (Plato, Art) Date: Mon, 6 Feb 2017 10:33:51 -0500 (EST) Subject: ticketmaster.com 403 Forbidden In-Reply-To: <72B552F6-A35B-4DEE-8267-937674322441@oitc.com> References: <72B552F6-A35B-4DEE-8267-937674322441@oitc.com> Message-ID: <1821312178.81.1486395272589.JavaMail.art@IntEng-Surface> Can get to them from Equinox connected Peer. ----- Original Message ----- From: "TR Shaw" To: "Charles J Manser" Cc: nanog at nanog.org Sent: Monday, February 6, 2017 10:26:50 AM Subject: Re: ticketmaster.com 403 Forbidden Can get to them fine from Florida via level3. Tom? > On Feb 6, 2017, at 8:04 AM, Manser, Charles J wrote: > > List, > > It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? > > If anyone from Ticketmaster could reach out to me off-list, it would be helpful. > Charles Manser | Principal Engineer I, Network Security > Charles.Manser at charter.com > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From lists at chrisk.de Mon Feb 6 15:42:53 2017 From: lists at chrisk.de (Christian Kildau) Date: Mon, 6 Feb 2017 16:42:53 +0100 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: Message-ID: 403 forbidden from as12306 via level3. On Mon, Feb 6, 2017 at 2:04 PM, Manser, Charles J < Charles.Manser at charter.com> wrote: > List, > > It seems that browsing to ticketmaster.com or any of the associated IP > addresses results in a 403 Forbidden for our customers today. Is anyone > else having this issue? > > If anyone from Ticketmaster could reach out to me off-list, it would be > helpful. > Charles Manser | Principal Engineer I, Network Security > Charles.Manser at charter.com > > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > From bhatton at htva.net Mon Feb 6 15:47:28 2017 From: bhatton at htva.net (Benjamin Hatton) Date: Mon, 6 Feb 2017 10:47:28 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: Message-ID: No Issues from AS26269 via HE NYC (AS6939) *Ben Hatton* Network Engineer Haefele TV Inc. d:(607)589-8000 bhatton at htva.net www.htva.net On Mon, Feb 6, 2017 at 10:42 AM, Christian Kildau wrote: > 403 forbidden from as12306 via level3. > > On Mon, Feb 6, 2017 at 2:04 PM, Manser, Charles J < > Charles.Manser at charter.com> wrote: > > > List, > > > > It seems that browsing to ticketmaster.com or any of the associated IP > > addresses results in a 403 Forbidden for our customers today. Is anyone > > else having this issue? > > > > If anyone from Ticketmaster could reach out to me off-list, it would be > > helpful. > > Charles Manser | Principal Engineer I, Network Security > > Charles.Manser at charter.com > > > > E-MAIL CONFIDENTIALITY NOTICE: > > The contents of this e-mail message and any attachments are intended > > solely for the addressee(s) and may contain confidential and/or legally > > privileged information. If you are not the intended recipient of this > > message or if this message has been addressed to you in error, please > > immediately alert the sender by reply e-mail and then delete this message > > and any attachments. If you are not the intended recipient, you are > > notified that any use, dissemination, distribution, copying, or storage > of > > this message or any attachment is strictly prohibited. > > > From niels=nanog at bakker.net Mon Feb 6 16:09:01 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 6 Feb 2017 17:09:01 +0100 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: Message-ID: <20170206160901.GA86663@excession.tpb.net> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: >It seems that browsing to ticketmaster.com or any of the associated >IP addresses results in a 403 Forbidden for our customers today. Is >anyone else having this issue? http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ -- Niels. From edee at globalvision.net Mon Feb 6 16:35:12 2017 From: edee at globalvision.net (Ethan E. Dee) Date: Mon, 6 Feb 2017 11:35:12 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <20170206160901.GA86663@excession.tpb.net> References: <20170206160901.GA86663@excession.tpb.net> Message-ID: It gives me a Forbidden error. It has for over a year. There support says they are not allowed to me why by their policy. it is across an entire /19. I gave up after the fifth time and encourage the customers to call them individually. On 02/06/2017 11:09 AM, Niels Bakker wrote: > * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, > 16:21 CET]: >> It seems that browsing to ticketmaster.com or any of the associated >> IP addresses results in a 403 Forbidden for our customers today. Is >> anyone else having this issue? > > http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ > > > > -- Niels. From mike.lyon at gmail.com Mon Feb 6 16:45:24 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Mon, 6 Feb 2017 08:45:24 -0800 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: <20170206160901.GA86663@excession.tpb.net> Message-ID: <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> Yup, i have a /22 that has the same problem. Support is useless... > On Feb 6, 2017, at 08:35, Ethan E. Dee wrote: > > It gives me a Forbidden error. > It has for over a year. > There support says they are not allowed to me why by their policy. > it is across an entire /19. > I gave up after the fifth time and encourage the customers to call them individually. > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: >>> It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? >> >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ >> >> >> -- Niels. > From ops.lists at gmail.com Mon Feb 6 16:49:49 2017 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 06 Feb 2017 08:49:49 -0800 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> Message-ID: <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> My guess is you have or had sometime in the long distant past a scalper operating on your network, using automated ticket purchase bots. If you still have that scalper around, you might want to turf him. If he?s ancient history, saying so might induce them to remove the block. --srs On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of mike.lyon at gmail.com" wrote: Yup, i have a /22 that has the same problem. Support is useless... > On Feb 6, 2017, at 08:35, Ethan E. Dee wrote: > > It gives me a Forbidden error. > It has for over a year. > There support says they are not allowed to me why by their policy. > it is across an entire /19. > I gave up after the fifth time and encourage the customers to call them individually. > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: >>> It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? >> >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ >> >> >> -- Niels. > From meekjt at gmail.com Mon Feb 6 17:01:25 2017 From: meekjt at gmail.com (Jon Meek) Date: Mon, 6 Feb 2017 12:01:25 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> Message-ID: Another way to get on their block list is to have a lot of users behind a single NAT or proxy IP address. In my experience they blocked single IPs. The first time it was easy to explain that there were 30,000 users behind the single address and get the block cleared. After that it became more difficult to get someone to listen. In one case I gave up because we were about to make a data center change and the blocked address would no longer be used. However, I don't believe that the problem ever came back, maybe because we had fewer users behind individual IP addresses, or because they finally note that the netblocks were owned by $LARGE_CORPORATION. On Mon, Feb 6, 2017 at 11:49 AM, Suresh Ramasubramanian wrote: > My guess is you have or had sometime in the long distant past a scalper > operating on your network, using automated ticket purchase bots. > > If you still have that scalper around, you might want to turf him. If > he?s ancient history, saying so might induce them to remove the block. > > --srs > > On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of > mike.lyon at gmail.com" mike.lyon at gmail.com> wrote: > > Yup, i have a /22 that has the same problem. Support is useless... > > > On Feb 6, 2017, at 08:35, Ethan E. Dee > wrote: > > > > It gives me a Forbidden error. > > It has for over a year. > > There support says they are not allowed to me why by their policy. > > it is across an entire /19. > > I gave up after the fifth time and encourage the customers to call > them individually. > > > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: > >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, > 16:21 CET]: > >>> It seems that browsing to ticketmaster.com or any of the > associated IP addresses results in a 403 Forbidden for our customers today. > Is anyone else having this issue? > >> > >> http://help.ticketmaster.com/why-am-i-getting-a-blocked- > forbidden-or-403-error-message/ > >> > >> > >> -- Niels. > > > > > > -- Jon T. Meek, Ph.D. https://linkedin.com/in/meekjt https://meekj.github.io From edee at globalvision.net Mon Feb 6 17:19:00 2017 From: edee at globalvision.net (Ethan E. Dee) Date: Mon, 6 Feb 2017 12:19:00 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> Message-ID: So their policy says, if an ISP has one scalper, we'll block their entire subnet and not tell them why? On 02/06/2017 11:49 AM, Suresh Ramasubramanian wrote: > My guess is you have or had sometime in the long distant past a scalper operating on your network, using automated ticket purchase bots. > > If you still have that scalper around, you might want to turf him. If he?s ancient history, saying so might induce them to remove the block. > > --srs > > On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of mike.lyon at gmail.com" wrote: > > Yup, i have a /22 that has the same problem. Support is useless... > > > On Feb 6, 2017, at 08:35, Ethan E. Dee wrote: > > > > It gives me a Forbidden error. > > It has for over a year. > > There support says they are not allowed to me why by their policy. > > it is across an entire /19. > > I gave up after the fifth time and encourage the customers to call them individually. > > > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: > >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: > >>> It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? > >> > >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ > >> > >> > >> -- Niels. > > > > > From matlockken at gmail.com Mon Feb 6 17:22:42 2017 From: matlockken at gmail.com (Ken Matlock) Date: Mon, 6 Feb 2017 10:22:42 -0700 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> Message-ID: Honestly, I'm surprised they don't try and charge a 'convenience fee' while implementing the block! ;-) Ken On Mon, Feb 6, 2017 at 10:19 AM, Ethan E. Dee wrote: > So their policy says, if an ISP has one scalper, we'll block their entire > subnet and not tell them why? > > > > On 02/06/2017 11:49 AM, Suresh Ramasubramanian wrote: > >> My guess is you have or had sometime in the long distant past a scalper >> operating on your network, using automated ticket purchase bots. >> >> If you still have that scalper around, you might want to turf him. If >> he?s ancient history, saying so might induce them to remove the block. >> >> --srs >> >> On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of >> mike.lyon at gmail.com" > mike.lyon at gmail.com> wrote: >> >> Yup, i have a /22 that has the same problem. Support is useless... >> > On Feb 6, 2017, at 08:35, Ethan E. Dee >> wrote: >> > >> > It gives me a Forbidden error. >> > It has for over a year. >> > There support says they are not allowed to me why by their policy. >> > it is across an entire /19. >> > I gave up after the fifth time and encourage the customers to call >> them individually. >> > >> >> On 02/06/2017 11:09 AM, Niels Bakker wrote: >> >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb >> 2017, 16:21 CET]: >> >>> It seems that browsing to ticketmaster.com or any of the >> associated IP addresses results in a 403 Forbidden for our customers today. >> Is anyone else having this issue? >> >> >> >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forb >> idden-or-403-error-message/ >> >> >> >> >> >> -- Niels. >> > >> >> >> > From edee at globalvision.net Mon Feb 6 17:24:30 2017 From: edee at globalvision.net (Ethan E. Dee) Date: Mon, 6 Feb 2017 12:24:30 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> Message-ID: <31e3345e-893d-0308-0617-2fad8ba5ecef@globalvision.net> I'm interested to see if any one has beat this. On 02/06/2017 12:22 PM, Ken Matlock wrote: > Honestly, I'm surprised they don't try and charge a 'convenience fee' > while implementing the block! ;-) > > Ken > > On Mon, Feb 6, 2017 at 10:19 AM, Ethan E. Dee > wrote: > > So their policy says, if an ISP has one scalper, we'll block their > entire subnet and not tell them why? > > > > On 02/06/2017 11:49 AM, Suresh Ramasubramanian wrote: > > My guess is you have or had sometime in the long distant past > a scalper operating on your network, using automated ticket > purchase bots. > > If you still have that scalper around, you might want to turf > him. If he?s ancient history, saying so might induce them to > remove the block. > > --srs > > On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org > on behalf of > mike.lyon at gmail.com " > on > behalf of mike.lyon at gmail.com > wrote: > > Yup, i have a /22 that has the same problem. Support is > useless... > > On Feb 6, 2017, at 08:35, Ethan E. Dee > > wrote: > > > > It gives me a Forbidden error. > > It has for over a year. > > There support says they are not allowed to me why by > their policy. > > it is across an entire /19. > > I gave up after the fifth time and encourage the > customers to call them individually. > > > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: > >> * Charles.Manser at charter.com > (Manser, Charles J) [Mon > 06 Feb 2017, 16:21 CET]: > >>> It seems that browsing to ticketmaster.com > or any of the associated IP > addresses results in a 403 Forbidden for our customers today. > Is anyone else having this issue? > >> > >> > http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ > > >> > >> > >> -- Niels. > > > > > > From math at sizone.org Mon Feb 6 17:39:44 2017 From: math at sizone.org (Ken Chase) Date: Mon, 6 Feb 2017 12:39:44 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> Message-ID: <20170206173944.GR10696@sizone.org> Seems to me this random prefix-based blocking by major sites, then let's-use-nanog-to-fix-it, is not a great methodology. I block whole /18s and such to deal with .cn/.ru botnets too, but luckily my cxs' cxs are mostly North American, few complaints yet. Sledgehammer style - indelicate. Is there a better method other than us sheep bleating helplessly at behemoths who might not even have a presence on Nanog-l? This sledgehammer blacklisting results in a filter where smaller than /16 doesnt get addressed due to time cost of dealing with fewer revenue-generating eyeballs per ticket. Result: big ISPs win though sieve effect. Google has adopted a 'blacklist for a while' policy with their spam control, which mostly works but can leave you in the dark as to why you're continually relisted for no obvious reason - no humans out there to help directly, so it's back to bleating on nanog by Nate and friends. What more 'official' and formalized mechanisms can we use? /kc On Mon, Feb 06, 2017 at 12:19:00PM -0500, Ethan E. Dee said: >So their policy says, if an ISP has one scalper, we'll block their entire >subnet and not tell them why? -- Ken Chase - math at sizone.org Guelph Canada From karim.adel at gmail.com Mon Feb 6 19:10:11 2017 From: karim.adel at gmail.com (Kasper Adel) Date: Mon, 6 Feb 2017 11:10:11 -0800 Subject: Brainstorming acceptance issues - WAN impediment Message-ID: Hi, I am in the process of testing an 'automation/sdn' kind of controller, it will be managing configuration on our routers and also deploying some VNFs too. Before accepting it, i'd like to perform some testing, to make sure of the behavior if there are network issues between the controller and the devices (routers or servers), during creation of services. >From the top of my head, I can think of the basic tests like introducing jitter and delay but i would appreciate more ideas or even test cases that i can re-use. Thanks From dave at temk.in Mon Feb 6 22:06:17 2017 From: dave at temk.in (Dave Temkin) Date: Mon, 6 Feb 2017 17:06:17 -0500 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: References: Message-ID: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> The Peering Personals has been shelved while we try to figure out a better option. There was no peering content submitted to the Program Committee that justified a separate track, and so they chose to include the content in the general session throughout the program. Regards, -Dave On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , wrote: > I'm squinting at the Guidebook for NANOG69, > and I don't seem to see any peering BOF or > peering social this time around. Am I being > blind again, and it's on the agenda somewhere > but I'm just overlooking it? > Pointers in the right direction would be appreciated. > > Thanks! :) > > Matt From rsk at gsp.org Mon Feb 6 22:09:43 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 6 Feb 2017 17:09:43 -0500 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <20170206173944.GR10696@sizone.org> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> <20170206173944.GR10696@sizone.org> Message-ID: <20170206220943.GA19346@gsp.org> On Mon, Feb 06, 2017 at 12:39:44PM -0500, Ken Chase wrote: > Seems to me this random prefix-based blocking by major sites, > then let's-use-nanog-to-fix-it, is not a great methodology. You're correct. It's not. > What more 'official' and formalized mechanisms can we use? RFC 2142 stipulates role addresses for a variety of functions, many of which were in common use and some of which were considered best practices even before they were formalized 20 years ago. A *lot* of the traffic here (and on other mailing lists) winds up here (and on other mailing lists) because some incompetent/negligent operations don't support those. ---rsk From bill at herrin.us Mon Feb 6 22:31:10 2017 From: bill at herrin.us (William Herrin) Date: Mon, 6 Feb 2017 17:31:10 -0500 Subject: IoT security Message-ID: This afternoon's panel about IoT's lack of security got me thinking... On the issue of ISPs unable to act on insecure devices because they can't detect the devices until they're compromised and then only have the largest hammer (full account ban) to act... What about some kind of requirement or convention that upon boot and successful attachment to the network (and maybe once a month thereafter), any IoT device must _by default_ emit a UDP packet to an anycast address reserved for the purpose which identifies the device model and software build. The ISP can capture traffic to that anycast address, compare the data against a list of devices known to be defective and, if desired, respond with a fail message. If the IoT device receives the fail message, it must try to report the problem to its owner and remove its default route so that it can only communicate on the local lan. The user can override the fail and if desired configure the device not to emit the init messages at all. But by default the ISP is allowed to disable the device by responding to the init message. Would have to cryptographically sign the fail message and let the device query the signer's reputation or something like that to avoid the obvious security issue. Obvious privacy issues to consider. Anyway, throwing it out there as a potential discussion starting point. The presentation on bandwidth policers... Seems like we could use some form of ICMP message similar to destination unreachable that provides some kind of arbitrary string plus the initial part of the dropped packet. One of the potential strings would be an explicit notice to the sender that packets were dropped and the bandwidth available. Yes, we already have ECN, but ECN tells the receiver about congestion, not the sender. More to the point, ECN can only be flagged on packets that are passed, not the packets that are dropped, so the policer would have to be complicated enough to note on the next packet that the prior packet was dropped. Also, ECN only advises that you're close to the limit not any information about the policer's target limit. This thought is not fully baked. Throwing it out for conversation purposes. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jayhanke at gmail.com Mon Feb 6 23:14:38 2017 From: jayhanke at gmail.com (Jay Hanke) Date: Mon, 6 Feb 2017 17:14:38 -0600 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> References: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> Message-ID: The peering social at previous NANOG meetings has been excellent and very useful. As you mentioned, the peering personals are perhaps not as valuable. It would be great to see the social portion come back in some form. Jay On Mon, Feb 6, 2017 at 4:06 PM, Dave Temkin wrote: > The Peering Personals has been shelved while we try to figure out a better option. > > There was no peering content submitted to the Program Committee that justified a separate track, and so they chose to include the content in the general session throughout the program. > > Regards, > > -Dave > > On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , wrote: >> I'm squinting at the Guidebook for NANOG69, >> and I don't seem to see any peering BOF or >> peering social this time around. Am I being >> blind again, and it's on the agenda somewhere >> but I'm just overlooking it? >> Pointers in the right direction would be appreciated. >> >> Thanks! :) >> >> Matt From mehmet at akcin.net Mon Feb 6 23:39:38 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 06 Feb 2017 23:39:38 +0000 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: References: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> Message-ID: Someone will need to volunteer and organize this track just like others. It has been challenging to find content. Topic can be contraversial and of course people might not want to always speak as open as they should in order to make the time useful. I have really liked peering bof personally from many years ago where it provided a great platform to speak. I will volunteer to organize peering bof in nanog 70 and present it to PC's consideration as it seems some folks want to see that back including myself Mehmet On Mon, Feb 6, 2017 at 6:14 PM Jay Hanke wrote: > The peering social at previous NANOG meetings has been excellent and > very useful. As you mentioned, the peering personals are perhaps not > as valuable. It would be great to see the social portion come back in > some form. > > Jay > > On Mon, Feb 6, 2017 at 4:06 PM, Dave Temkin wrote: > > The Peering Personals has been shelved while we try to figure out a > better option. > > > > There was no peering content submitted to the Program Committee that > justified a separate track, and so they chose to include the content in the > general session throughout the program. > > > > Regards, > > > > -Dave > > > > On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , > wrote: > >> I'm squinting at the Guidebook for NANOG69, > >> and I don't seem to see any peering BOF or > >> peering social this time around. Am I being > >> blind again, and it's on the agenda somewhere > >> but I'm just overlooking it? > >> Pointers in the right direction would be appreciated. > >> > >> Thanks! :) > >> > >> Matt > From jpinnow at xipe.net Mon Feb 6 21:38:56 2017 From: jpinnow at xipe.net (Joel Pinnow) Date: Mon, 6 Feb 2017 13:38:56 -0800 Subject: Technical contact at Yahoo Message-ID: Sorry for the added noise, but I need to reach out to a technical contact at Yahoo regarding incorrect geolocation on a /24 block. I've had no luck getting in contact with anyone via WHOIS or other contact info. Can someone from Yahoo please private email me at: jpinnow at xipe.net Thanks, Joel From bob at FiberInternetCenter.com Mon Feb 6 23:58:53 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Mon, 6 Feb 2017 15:58:53 -0800 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> References: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> Message-ID: <5fb25deef55a708b50e3bfcee2745ce4.squirrel@66.201.44.180> I suggest in the future NOT to get rid of something because a new method is attempted. I.E nanog had a nice method of identifying potential and existing peers with a simple green dot at registration to indicate an individual was involved with BGP in their company. That went away and today there is nothing. Cost of implementation was less than 5 dollars at any office supply retailer. Just a thought. Thank You Bob Evans CTO > The Peering Personals has been shelved while we try to figure out a better > option. > > There was no peering content submitted to the Program Committee that > justified a separate track, and so they chose to include the content in > the general session throughout the program. > > Regards, > > -Dave > > On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , > wrote: >> I'm squinting at the Guidebook for NANOG69, >> and I don't seem to see any peering BOF or >> peering social this time around. Am I being >> blind again, and it's on the agenda somewhere >> but I'm just overlooking it? >> Pointers in the right direction would be appreciated. >> >> Thanks! :) >> >> Matt > From mike at mtcc.com Tue Feb 7 00:10:01 2017 From: mike at mtcc.com (Michael Thomas) Date: Mon, 6 Feb 2017 16:10:01 -0800 Subject: IoT security In-Reply-To: References: Message-ID: <9c6d66e8-da58-eeee-95c0-0d37b53d58d4@mtcc.com> On 2/6/17 2:31 PM, William Herrin wrote: > This afternoon's panel about IoT's lack of security got me thinking... > > > On the issue of ISPs unable to act on insecure devices because they > can't detect the devices until they're compromised and then only have > the largest hammer (full account ban) to act... > > What about some kind of requirement or convention that upon boot and > successful attachment to the network (and maybe once a month > thereafter), any IoT device must _by default_ emit a UDP packet to an > anycast address reserved for the purpose which identifies the device > model and software build. The ISP can capture traffic to that anycast > address, compare the data against a list of devices known to be > defective and, if desired, respond with a fail message. If the IoT > device receives the fail message, it must try to report the problem to > its owner and remove its default route so that it can only communicate > on the local lan. The user can override the fail and if desired > configure the device not to emit the init messages at all. But by > default the ISP is allowed to disable the device by responding to the > init message. Uh, yuck at many levels. Do you leak your cisco ios versions to the internet? Do you really want the responsibility for the remote kill switch for IoT S&M gear? And of course, you're depending on rfc 3514, right? Mike From joelja at bogus.com Tue Feb 7 00:14:54 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 6 Feb 2017 16:14:54 -0800 Subject: IoT security In-Reply-To: References: Message-ID: <199a1c03-b995-14d0-fd5e-dd3a4b8073cf@bogus.com> On 2/6/17 2:31 PM, William Herrin wrote: > This afternoon's panel about IoT's lack of security got me thinking... > > > On the issue of ISPs unable to act on insecure devices because they > can't detect the devices until they're compromised and then only have > the largest hammer (full account ban) to act... > > What about some kind of requirement or convention that upon boot and > successful attachment to the network (and maybe once a month > thereafter), any IoT device must _by default_ emit a UDP packet to an > anycast address reserved for the purpose which identifies the device > model and software build. The ISP can capture traffic to that anycast > address, compare the data against a list of devices known to be > defective and, if desired, respond with a fail message. If the IoT > device receives the fail message, it must try to report the problem to > its owner and remove its default route so that it can only communicate > on the local lan. The user can override the fail and if desired > configure the device not to emit the init messages at all. But by > default the ISP is allowed to disable the device by responding to the > init message. self identification is privacy hostile and tantamount to indicating a willingness to be subverted (this is why we disable lldp on external interfaces) even if it would otherwise be rather useful. the use of modified eui64 addresses as part of v6 address selection hash basically gone away for similar reasons. > Would have to cryptographically sign the fail message and let the > device query the signer's reputation or something like that to avoid > the obvious security issue. Obvious privacy issues to consider. > Anyway, throwing it out there as a potential discussion starting > point. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Tue Feb 7 00:37:37 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 6 Feb 2017 16:37:37 -0800 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> Message-ID: <676ebaf4-48c9-1bd4-9de3-1a3fe3c5f97b@bogus.com> On 2/6/17 8:49 AM, Suresh Ramasubramanian wrote: > My guess is you have or had sometime in the long distant past a scalper operating on your network, using automated ticket purchase bots. > > If you still have that scalper around, you might want to turf him. If he?s ancient history, saying so might induce them to remove the block. Note that scalper bots benefit from pools of residential ip addresses to work with in subverting the anti-bot countermeasures of ticket sale platforms. so there are the legitimate possibility that subverted hosts are being used for that sort of thing. > --srs > > On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of mike.lyon at gmail.com" wrote: > > Yup, i have a /22 that has the same problem. Support is useless... > > > On Feb 6, 2017, at 08:35, Ethan E. Dee wrote: > > > > It gives me a Forbidden error. > > It has for over a year. > > There support says they are not allowed to me why by their policy. > > it is across an entire /19. > > I gave up after the fifth time and encourage the customers to call them individually. > > > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: > >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: > >>> It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? > >> > >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ > >> > >> > >> -- Niels. > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From dave at temk.in Tue Feb 7 02:17:52 2017 From: dave at temk.in (Dave Temkin) Date: Mon, 6 Feb 2017 21:17:52 -0500 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: <5fb25deef55a708b50e3bfcee2745ce4.squirrel@66.201.44.180> References: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> <5fb25deef55a708b50e3bfcee2745ce4.squirrel@66.201.44.180> Message-ID: Hi Bob, This was inadvertent and we will bring this back for NANOG 70. Regards, -Dave On Feb 6, 2017, 6:58 PM -0500, Bob Evans , wrote: > I suggest in the future NOT to get rid of something because a new method > is attempted. I.E nanog had a nice method of identifying potential and > existing peers with a simple green dot at registration to indicate an > individual was involved with BGP in their company. That went away and > today there is nothing. Cost of implementation was less than 5 dollars at > any office supply retailer. > > Just a thought. > > Thank You > Bob Evans > CTO > > > > > > The Peering Personals has been shelved while we try to figure out a better > > option. > > > > There was no peering content submitted to the Program Committee that > > justified a separate track, and so they chose to include the content in > > the general session throughout the program. > > > > Regards, > > > > -Dave > > > > On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , > > wrote: > > > I'm squinting at the Guidebook for NANOG69, > > > and I don't seem to see any peering BOF or > > > peering social this time around. Am I being > > > blind again, and it's on the agenda somewhere > > > but I'm just overlooking it? > > > Pointers in the right direction would be appreciated. > > > > > > Thanks! :) > > > > > > Matt > > > > From bill at herrin.us Tue Feb 7 02:44:29 2017 From: bill at herrin.us (William Herrin) Date: Mon, 6 Feb 2017 21:44:29 -0500 Subject: IoT security In-Reply-To: <199a1c03-b995-14d0-fd5e-dd3a4b8073cf@bogus.com> References: <199a1c03-b995-14d0-fd5e-dd3a4b8073cf@bogus.com> Message-ID: On Mon, Feb 6, 2017 at 7:14 PM, joel jaeggli wrote: > On 2/6/17 2:31 PM, William Herrin wrote: >> This afternoon's panel about IoT's lack of security got me thinking... Hi Joel, For clarification I was referring to this: http://nanog.org/meetings/abstract?id=3051 The long and short of the panel was: as an industry (device vendors and service providers both) it behooves us to voluntarily get on top of the IoT security problem before some catastrophic event requires the government to dictate the precise manner in which we will get on top of the problem. >> What about some kind of requirement or convention that upon boot and >> successful attachment to the network (and maybe once a month >> thereafter), any IoT device must _by default_ emit a UDP packet to an >> anycast address reserved for the purpose which identifies the device >> model and software build. > self identification is privacy hostile and tantamount to indicating a > willingness to be subverted (this is why we disable lldp on external > interfaces) even if it would otherwise be rather useful. the use of > modified eui64 addresses as part of v6 address selection hash basically > gone away for similar reasons. I'm not sure how we get on top of the problem without offering an effective network kill switch to the nearest security-competent person. I think I'd prefer a user-disableable kill-switch used on a single piece of equipment to a kill switch for my entire Internet connection. The IPv6 SLAAC address suffers a rather worse case of the privacy problem since it allows the entire Internet to track your hardware, not just your local ISP. In any case, I thought "how do we fix this long term" could stand discussion on the list. Because yes, the IoT device vendors mostly produce trash and if (to borrow a phrase) it saves them a buck at retail they will keep producing trash. But we're the ones letting that trash cause nation-scale problems and when the regulatory hammer crashes down it's gonna hit us all. On Mon, Feb 6, 2017 at 7:10 PM, Michael Thomas wrote: > Uh, yuck at many levels. Do you leak your cisco ios versions to the > internet? Hi Michael, I'm not aware of any Cisco IOS devices that qualify as IoT. Some lighter weight Cisco gear, yes. And no, I do not want to broadcast my information. But I'm professional who customizes my gear when I plug it in. I don't run with the defaults. > Do you really want the responsibility for the remote kill switch for IoT S&M > gear? I already have the kill switch for the customer's entire S&M transit link. I'd prefer to also have a smaller hammer whose use won't net me a furious call from Sales. > And of course, you're depending on rfc 3514, right? Nope. I'll decide what's evil and what's not (more likely I'll pay a service to provide me a regularly updated database) and I depend only on a high enough percentage of the devices offering themselves up for that decision that it becomes impractical to construct another Mirai. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From kemp at network-services.uoregon.edu Tue Feb 7 02:51:08 2017 From: kemp at network-services.uoregon.edu (John Kemp) Date: Mon, 6 Feb 2017 21:51:08 -0500 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: References: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> <5fb25deef55a708b50e3bfcee2745ce4.squirrel@66.201.44.180> Message-ID: <5899361C.50205@network-services.uoregon.edu> I would like to see the session continue in some form. Social was close to good. The peering presentations weren't as useful to me personally. They sometimes made the time for actual peering conversations too short. The extra food and drinks were not important to me personally. ... Perhaps an "extended break" 45 minutes, with typical break food, and no presentations. Or if you want, a *silent* rolling slide show on a screen, with 1-slide per submitter, for peering news items or general peering requests... Cheaper... quieter... shorter... But having all the people in the same room at the same time for the same purpose, usually pretty useful. 2 cents, John Kemp On 2/6/17 9:17 PM, Dave Temkin wrote: > Hi Bob, > > This was inadvertent and we will bring this back for NANOG 70. > > Regards, > > -Dave > > On Feb 6, 2017, 6:58 PM -0500, Bob Evans , wrote: >> I suggest in the future NOT to get rid of something because a new method >> is attempted. I.E nanog had a nice method of identifying potential and >> existing peers with a simple green dot at registration to indicate an >> individual was involved with BGP in their company. That went away and >> today there is nothing. Cost of implementation was less than 5 dollars at >> any office supply retailer. >> >> Just a thought. >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >>> The Peering Personals has been shelved while we try to figure out a better >>> option. >>> >>> There was no peering content submitted to the Program Committee that >>> justified a separate track, and so they chose to include the content in >>> the general session throughout the program. >>> >>> Regards, >>> >>> -Dave >>> >>> On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , >>> wrote: >>>> I'm squinting at the Guidebook for NANOG69, >>>> and I don't seem to see any peering BOF or >>>> peering social this time around. Am I being >>>> blind again, and it's on the agenda somewhere >>>> but I'm just overlooking it? >>>> Pointers in the right direction would be appreciated. >>>> >>>> Thanks! :) >>>> >>>> Matt >>> >> >> From rsk at gsp.org Tue Feb 7 10:26:26 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 7 Feb 2017 05:26:26 -0500 Subject: IoT security In-Reply-To: References: Message-ID: <20170207102625.GA29707@gsp.org> On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote: > What about some kind of requirement or convention that upon boot and > successful attachment to the network (and maybe once a month > thereafter), any IoT device must _by default_ emit a UDP packet to an > anycast address reserved for the purpose which identifies the device > model and software build. I can think of at least four reasons why this idea must be killed immediately and permanently. This is off the top of my head *before* coffee, so I strongly suspect there are more. 1. An attacker who takes control of an IoT device can change the contents of that packet, cause it to be emitted, suppress it from being emitted, etc. 2. This will allow ISPs to build a database of which customers have which IOT devices. This is an appalling invasion of privacy. 3. This will allow ISPs to build a database of which customers have which IOT devices. This will create one-stop shopping for attackers. 4. It won't take long for this to be used as a DDoS vector. ---rsk From bill at herrin.us Tue Feb 7 11:56:40 2017 From: bill at herrin.us (William Herrin) Date: Tue, 7 Feb 2017 06:56:40 -0500 Subject: IoT security In-Reply-To: <20170207102625.GA29707@gsp.org> References: <20170207102625.GA29707@gsp.org> Message-ID: On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec wrote: > On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote: >> What about some kind of requirement or convention that upon boot and >> successful attachment to the network (and maybe once a month >> thereafter), any IoT device must _by default_ emit a UDP packet to an >> anycast address reserved for the purpose which identifies the device >> model and software build. > > I can think of at least four reasons why this idea must be killed > immediately and permanently. This is off the top of my head *before* > coffee, so I strongly suspect there are more. > > 1. An attacker who takes control of an IoT device can change the contents > of that packet, cause it to be emitted, suppress it from being emitted, etc. Hi Rich, Immaterial. The point is to catch vulnerable devices before they're hacked. That can't always happen (even with customers and vendors engaged in best practice patching), but it need only happen often enough to limit the size of the resulting botnets. > 2. This will allow ISPs to build a database of which customers have > which IOT devices. This is an appalling invasion of privacy. As I envision it, it's an opt-out system. Anyone who cares and knows enough to secure their network can turn it off for their devices. No permission or action from the ISP required to turn it off. In fact, you need only block packets to the well-known anycast address to disable it for all devices on your network. > 3. This will allow ISPs to build a database of which customers have > which IOT devices. This will create one-stop shopping for attackers. Possible, though an ISP which retains the data opens itself to a class action lawsuit if it can't keep control of it. Nevertheless, let's not oversell the privacy implications: most of the IoT devices we're talking about phone home anyway. They're tied to this or that cloud service rather than accepting local access. An ISP can't learn as much information by watching who they phone home to (deep packet inspection), but they can learn an awful lot. > 4. It won't take long for this to be used as a DDoS vector. If the ISP can't keep control of its security head-end then sure, at least until the ISP regains control. Regardless, I encourage you to suggest alternate solutions which don't run afoul of the problems you mention. The problem isn't going away. Entirely cutting off customers doesn't work because there are too many impacted customers and ISPs don't have the resources or the will to do so. Demanding that trash vendors not produce trash won't get it done either. When you eliminate responsible device hardening, cutting customer connections and the kill switch, what's left? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From dave at temk.in Tue Feb 7 12:09:01 2017 From: dave at temk.in (Dave Temkin) Date: Tue, 7 Feb 2017 07:09:01 -0500 Subject: Peering BOF/Peering social @NANOG69? In-Reply-To: <5899361C.50205@network-services.uoregon.edu> References: <4094203a-c8ba-4afa-b16c-2506b7dd0f10@Spark> <5fb25deef55a708b50e3bfcee2745ce4.squirrel@66.201.44.180> <5899361C.50205@network-services.uoregon.edu> Message-ID: Thank you, that's great feedback and great ideas. Regards, -Dave On Mon, Feb 6, 2017 at 9:51 PM, John Kemp wrote: > > I would like to see the session continue in some form. > Social was close to good. > > The peering presentations weren't as useful to me personally. > They sometimes made the time for actual peering conversations > too short. > > The extra food and drinks were not important to me personally. > > ... > > Perhaps an "extended break" 45 minutes, with typical > break food, and no presentations. Or if you want, a *silent* > rolling slide show on a screen, with 1-slide per submitter, > for peering news items or general peering requests... > > Cheaper... quieter... shorter... But having all the people > in the same room at the same time for the same purpose, usually > pretty useful. > > 2 cents, > John Kemp > > > On 2/6/17 9:17 PM, Dave Temkin wrote: > > Hi Bob, > > > > This was inadvertent and we will bring this back for NANOG 70. > > > > Regards, > > > > -Dave > > > > On Feb 6, 2017, 6:58 PM -0500, Bob Evans , > wrote: > >> I suggest in the future NOT to get rid of something because a new method > >> is attempted. I.E nanog had a nice method of identifying potential and > >> existing peers with a simple green dot at registration to indicate an > >> individual was involved with BGP in their company. That went away and > >> today there is nothing. Cost of implementation was less than 5 dollars > at > >> any office supply retailer. > >> > >> Just a thought. > >> > >> Thank You > >> Bob Evans > >> CTO > >> > >> > >> > >> > >>> The Peering Personals has been shelved while we try to figure out a > better > >>> option. > >>> > >>> There was no peering content submitted to the Program Committee that > >>> justified a separate track, and so they chose to include the content in > >>> the general session throughout the program. > >>> > >>> Regards, > >>> > >>> -Dave > >>> > >>> On Feb 6, 2017, 8:12 AM -0500, Matthew Petach , > >>> wrote: > >>>> I'm squinting at the Guidebook for NANOG69, > >>>> and I don't seem to see any peering BOF or > >>>> peering social this time around. Am I being > >>>> blind again, and it's on the agenda somewhere > >>>> but I'm just overlooking it? > >>>> Pointers in the right direction would be appreciated. > >>>> > >>>> Thanks! :) > >>>> > >>>> Matt > >>> > >> > >> > > From dmitry at interhost.net Tue Feb 7 12:24:29 2017 From: dmitry at interhost.net (Dmitry Sherman) Date: Tue, 7 Feb 2017 12:24:29 +0000 Subject: Telia network quality In-Reply-To: References: Message-ID: Same here 2 BGP flaps in past week. Dmitry Sherman dmitry at interhost.net Interhost Networks Ltd Web: http://www.interhost.co.il fb: https://www.facebook.com/InterhostIL Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Sowell Sent: Sunday, February 5, 2017 1:37 AM To: Kaiser, Erich Cc: nanog at nanog.org Subject: Re: Telia network quality I've been using them out of Dallas for about 2.5 years now with very good success. Their NOC has been top notch in responding to our issues, though I've seen repeated peering issues for them with a single provider, but who's to say that's their fault and not the other parties? On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich wrote: > I would say that information is not 100% accurate. We use Telia for > waves nationwide and also have several DIA ingest(transit) points from > them. If anything, the IRU carriers they are using may have a problem > sometimes due to fiber cuts, but that is why you build redundant paths. > > They are very ontop of the ball when one of the waves goes down. We > actually don't utilize a ton of their transit due to the nature of our > network design, because we are connected to all of the major IXs. > > Erich Kaiser > The Fusion Network > erich at gotfusion.net > Office: 630-621-4804 > Cell: 630-777-9291 > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > > > I heard Telia's quality had been on the decline lately as they were > > signing on lots of high-capacity new customers, and Cloudflare had > > some complaint about them a few months prior too. Does anybody have > > any > insight > > into whether this is still the case? I was trying to evaluate > > whether > Telia > > would be a good carrier to switch over to as a primary provider, as > > their pricing does look pretty attractive. > > > > B/R > > Don > -- -------------------------------- GregSowell.com TheBrothersWISP.com StrayaNet.com This mail was received via PineApp Mail-SeCure System. From beecher at beecher.cc Tue Feb 7 12:47:23 2017 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 7 Feb 2017 07:47:23 -0500 Subject: Telia network quality In-Reply-To: References: Message-ID: At the risk of sounding exceptionally snarky here, I don't think it really makes sense to judge a carrier's performance based on the short term status of a single BGP session. On Tue, Feb 7, 2017 at 7:24 AM, Dmitry Sherman wrote: > Same here 2 BGP flaps in past week. > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Sowell > Sent: Sunday, February 5, 2017 1:37 AM > To: Kaiser, Erich > Cc: nanog at nanog.org > Subject: Re: Telia network quality > > I've been using them out of Dallas for about 2.5 years now with very good > success. Their NOC has been top notch in responding to our issues, though > I've seen repeated peering issues for them with a single provider, but > who's to say that's their fault and not the other parties? > > On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich wrote: > > > I would say that information is not 100% accurate. We use Telia for > > waves nationwide and also have several DIA ingest(transit) points from > > them. If anything, the IRU carriers they are using may have a problem > > sometimes due to fiber cuts, but that is why you build redundant paths. > > > > They are very ontop of the ball when one of the waves goes down. We > > actually don't utilize a ton of their transit due to the nature of our > > network design, because we are connected to all of the major IXs. > > > > Erich Kaiser > > The Fusion Network > > erich at gotfusion.net > > Office: 630-621-4804 > > Cell: 630-777-9291 > > > > > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > > > > > I heard Telia's quality had been on the decline lately as they were > > > signing on lots of high-capacity new customers, and Cloudflare had > > > some complaint about them a few months prior too. Does anybody have > > > any > > insight > > > into whether this is still the case? I was trying to evaluate > > > whether > > Telia > > > would be a good carrier to switch over to as a primary provider, as > > > their pricing does look pretty attractive. > > > > > > B/R > > > Don > > > > > > -- > -------------------------------- > GregSowell.com > TheBrothersWISP.com > StrayaNet.com > > This mail was received via PineApp Mail-SeCure System. > > > From dmitry at interhost.net Tue Feb 7 12:50:01 2017 From: dmitry at interhost.net (Dmitry Sherman) Date: Tue, 7 Feb 2017 12:50:01 +0000 Subject: Telia network quality In-Reply-To: References: , Message-ID: You're absolutely right. Usually the quality is perfect and stable. Telia is very respectful T1 provider. Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry at interhost.net Mob: 054-3181182 Sent from Steve's creature [X] On 7 Feb 2017, at 14:47, Tom Beecher > wrote: At the risk of sounding exceptionally snarky here, I don't think it really makes sense to judge a carrier's performance based on the short term status of a single BGP session. On Tue, Feb 7, 2017 at 7:24 AM, Dmitry Sherman > wrote: Same here 2 BGP flaps in past week. Dmitry Sherman dmitry at interhost.net Interhost Networks Ltd Web: http://www.interhost.co.il fb: https://www.facebook.com/InterhostIL Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Sowell Sent: Sunday, February 5, 2017 1:37 AM To: Kaiser, Erich > Cc: nanog at nanog.org Subject: Re: Telia network quality I've been using them out of Dallas for about 2.5 years now with very good success. Their NOC has been top notch in responding to our issues, though I've seen repeated peering issues for them with a single provider, but who's to say that's their fault and not the other parties? On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich > wrote: > I would say that information is not 100% accurate. We use Telia for > waves nationwide and also have several DIA ingest(transit) points from > them. If anything, the IRU carriers they are using may have a problem > sometimes due to fiber cuts, but that is why you build redundant paths. > > They are very ontop of the ball when one of the waves goes down. We > actually don't utilize a ton of their transit due to the nature of our > network design, because we are connected to all of the major IXs. > > Erich Kaiser > The Fusion Network > erich at gotfusion.net > Office: 630-621-4804 > Cell: 630-777-9291 > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don > wrote: > > > I heard Telia's quality had been on the decline lately as they were > > signing on lots of high-capacity new customers, and Cloudflare had > > some complaint about them a few months prior too. Does anybody have > > any > insight > > into whether this is still the case? I was trying to evaluate > > whether > Telia > > would be a good carrier to switch over to as a primary provider, as > > their pricing does look pretty attractive. > > > > B/R > > Don > -- -------------------------------- GregSowell.com TheBrothersWISP.com StrayaNet.com This mail was received via PineApp Mail-SeCure System. This mail was received via PineApp Mail-SeCure System. From beecher at beecher.cc Tue Feb 7 13:13:03 2017 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 7 Feb 2017 08:13:03 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> Message-ID: " any IoT device must _by default_ emit a UDP packet to an anycast address reserved for the purpose which identifies the device model and software build. " Any semi-competent attacker will simply alter the way the network stack on the device works to make it _not_ look like an IoT device for the purposes of this check, rendering it moot. "If the IoT device receives the fail message, it must try to report the problem to its owner and remove its default route so that it can only communicate on the local lan." If the vendor isn't thinking about security already, as evidenced by the current issues with these devices, how are they to be convinced to add code to make said device do something exceptionally specific? I believe it's important to remember that network endpoints will never be sure fully secure. They will never be fully in compliance with $standard . They will never always follow best practices. This is not to say we should do nothing (obligatory 'Perfect is the enemy of good' comment) but it's something to think about when discussing possibilities. On Tue, Feb 7, 2017 at 6:56 AM, William Herrin wrote: > On Tue, Feb 7, 2017 at 5:26 AM, Rich Kulawiec wrote: > > On Mon, Feb 06, 2017 at 05:31:10PM -0500, William Herrin wrote: > >> What about some kind of requirement or convention that upon boot and > >> successful attachment to the network (and maybe once a month > >> thereafter), any IoT device must _by default_ emit a UDP packet to an > >> anycast address reserved for the purpose which identifies the device > >> model and software build. > > > > I can think of at least four reasons why this idea must be killed > > immediately and permanently. This is off the top of my head *before* > > coffee, so I strongly suspect there are more. > > > > 1. An attacker who takes control of an IoT device can change the contents > > of that packet, cause it to be emitted, suppress it from being emitted, > etc. > > Hi Rich, > > Immaterial. The point is to catch vulnerable devices before they're > hacked. That can't always happen (even with customers and vendors > engaged in best practice patching), but it need only happen often > enough to limit the size of the resulting botnets. > > > > 2. This will allow ISPs to build a database of which customers have > > which IOT devices. This is an appalling invasion of privacy. > > As I envision it, it's an opt-out system. Anyone who cares and knows > enough to secure their network can turn it off for their devices. No > permission or action from the ISP required to turn it off. In fact, > you need only block packets to the well-known anycast address to > disable it for all devices on your network. > > > > 3. This will allow ISPs to build a database of which customers have > > which IOT devices. This will create one-stop shopping for attackers. > > Possible, though an ISP which retains the data opens itself to a class > action lawsuit if it can't keep control of it. > > Nevertheless, let's not oversell the privacy implications: most of the > IoT devices we're talking about phone home anyway. They're tied to > this or that cloud service rather than accepting local access. An ISP > can't learn as much information by watching who they phone home to > (deep packet inspection), but they can learn an awful lot. > > > > 4. It won't take long for this to be used as a DDoS vector. > > If the ISP can't keep control of its security head-end then sure, at > least until the ISP regains control. > > > Regardless, I encourage you to suggest alternate solutions which don't > run afoul of the problems you mention. The problem isn't going away. > Entirely cutting off customers doesn't work because there are too many > impacted customers and ISPs don't have the resources or the will to do > so. Demanding that trash vendors not produce trash won't get it done > either. When you eliminate responsible device hardening, cutting > customer connections and the kill switch, what's left? > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From rps at maine.edu Tue Feb 7 13:58:46 2017 From: rps at maine.edu (Ray Soucy) Date: Tue, 7 Feb 2017 08:58:46 -0500 Subject: IoT security In-Reply-To: References: Message-ID: I think the fundamental problem here is that these devices aren't good network citizens in the first place. The odds of getting them to add functionality to support a new protocol are even likely than getting them to not have open services externally IMHO. Couldn't a lot of this be caught by proactive vulnerability scanning and working with customers to have an SPI firewall in place, or am I missing something? Historically residential ISP CPE options have been terrible. If you could deliver something closer to user expectations you would likely see much more adoption and less desire to rip and replace. Ideally a cloud-managed device so that the config wouldn't need to be rebuilt in the event of a hardware swap. On Mon, Feb 6, 2017 at 5:31 PM, William Herrin wrote: > This afternoon's panel about IoT's lack of security got me thinking... > > > On the issue of ISPs unable to act on insecure devices because they > can't detect the devices until they're compromised and then only have > the largest hammer (full account ban) to act... > > What about some kind of requirement or convention that upon boot and > successful attachment to the network (and maybe once a month > thereafter), any IoT device must _by default_ emit a UDP packet to an > anycast address reserved for the purpose which identifies the device > model and software build. The ISP can capture traffic to that anycast > address, compare the data against a list of devices known to be > defective and, if desired, respond with a fail message. If the IoT > device receives the fail message, it must try to report the problem to > its owner and remove its default route so that it can only communicate > on the local lan. The user can override the fail and if desired > configure the device not to emit the init messages at all. But by > default the ISP is allowed to disable the device by responding to the > init message. > > Would have to cryptographically sign the fail message and let the > device query the signer's reputation or something like that to avoid > the obvious security issue. Obvious privacy issues to consider. > Anyway, throwing it out there as a potential discussion starting > point. > > > > The presentation on bandwidth policers... > > Seems like we could use some form of ICMP message similar to > destination unreachable that provides some kind of arbitrary string > plus the initial part of the dropped packet. One of the potential > strings would be an explicit notice to the sender that packets were > dropped and the bandwidth available. > > Yes, we already have ECN, but ECN tells the receiver about congestion, > not the sender. More to the point, ECN can only be flagged on packets > that are passed, not the packets that are dropped, so the policer > would have to be complicated enough to note on the next packet that > the prior packet was dropped. Also, ECN only advises that you're close > to the limit not any information about the policer's target limit. > > This thought is not fully baked. Throwing it out for conversation purposes. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > -- Ray Patrick Soucy Senior Cyber Security Engineer Networkmaine, University of Maine System US:IT 207-581-3526 From stankiewicz at njedge.net Tue Feb 7 13:38:08 2017 From: stankiewicz at njedge.net (James Stankiewicz) Date: Tue, 7 Feb 2017 08:38:08 -0500 Subject: Telia network quality In-Reply-To: References: Message-ID: We have been using Telia for the last several years and they have top notch!! On Tue, Feb 7, 2017 at 7:24 AM, Dmitry Sherman wrote: > Same here 2 BGP flaps in past week. > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: http://www.interhost.co.il > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Sowell > Sent: Sunday, February 5, 2017 1:37 AM > To: Kaiser, Erich > Cc: nanog at nanog.org > Subject: Re: Telia network quality > > I've been using them out of Dallas for about 2.5 years now with very good > success. Their NOC has been top notch in responding to our issues, though > I've seen repeated peering issues for them with a single provider, but > who's to say that's their fault and not the other parties? > > On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich wrote: > > > I would say that information is not 100% accurate. We use Telia for > > waves nationwide and also have several DIA ingest(transit) points from > > them. If anything, the IRU carriers they are using may have a problem > > sometimes due to fiber cuts, but that is why you build redundant paths. > > > > They are very ontop of the ball when one of the waves goes down. We > > actually don't utilize a ton of their transit due to the nature of our > > network design, because we are connected to all of the major IXs. > > > > Erich Kaiser > > The Fusion Network > > erich at gotfusion.net > > Office: 630-621-4804 > > Cell: 630-777-9291 > > > > > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > > > > > I heard Telia's quality had been on the decline lately as they were > > > signing on lots of high-capacity new customers, and Cloudflare had > > > some complaint about them a few months prior too. Does anybody have > > > any > > insight > > > into whether this is still the case? I was trying to evaluate > > > whether > > Telia > > > would be a good carrier to switch over to as a primary provider, as > > > their pricing does look pretty attractive. > > > > > > B/R > > > Don > > > > > > -- > -------------------------------- > GregSowell.com > TheBrothersWISP.com > StrayaNet.com > > This mail was received via PineApp Mail-SeCure System. > > > -- *Jim Stankiewicz* *NJEDge.Net* stankiewicz at njedge.net From edugas at unknowndevice.ca Tue Feb 7 14:19:12 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 07 Feb 2017 14:19:12 +0000 Subject: Telia network quality In-Reply-To: References: Message-ID: Was connected to them in NYC and in the past two years, we only had one issue and it was a faulty card in one of their core. New workplace is connected to them in Montreal. No issue so far! On Feb 7 2017, at 9:14 am, James Stankiewicz wrote: > We have been using Telia for the last several years and they have top notch!! > > On Tue, Feb 7, 2017 at 7:24 AM, Dmitry Sherman wrote: > > > Same here 2 BGP flaps in past week. > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > > \-----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Sowell > Sent: Sunday, February 5, 2017 1:37 AM > To: Kaiser, Erich > Cc: nanog at nanog.org > Subject: Re: Telia network quality > > I've been using them out of Dallas for about 2.5 years now with very good > success. Their NOC has been top notch in responding to our issues, though > I've seen repeated peering issues for them with a single provider, but > who's to say that's their fault and not the other parties? > > On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich wrote: > > > I would say that information is not 100% accurate. We use Telia for > > waves nationwide and also have several DIA ingest(transit) points from > > them. If anything, the IRU carriers they are using may have a problem > > sometimes due to fiber cuts, but that is why you build redundant paths. > > > > They are very ontop of the ball when one of the waves goes down. We > > actually don't utilize a ton of their transit due to the nature of our > > network design, because we are connected to all of the major IXs. > > > > Erich Kaiser > > The Fusion Network > > erich at gotfusion.net > > Office: 630-621-4804 > > Cell: 630-777-9291 > > > > > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > > > > > I heard Telia's quality had been on the decline lately as they were > > > signing on lots of high-capacity new customers, and Cloudflare had > > > some complaint about them a few months prior too. Does anybody have > > > any > > insight > > > into whether this is still the case? I was trying to evaluate > > > whether > > Telia > > > would be a good carrier to switch over to as a primary provider, as > > > their pricing does look pretty attractive. > > > > > > B/R > > > Don > > > > > > \-- > \-------------------------------- > GregSowell.com > TheBrothersWISP.com > StrayaNet.com > > This mail was received via PineApp Mail-SeCure System. > > > > > \-- *Jim Stankiewicz* *NJEDge.Net* stankiewicz at njedge.net From rsk at gsp.org Tue Feb 7 14:50:24 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 7 Feb 2017 09:50:24 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> Message-ID: <20170207145024.GA1224@gsp.org> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote: > Immaterial. The point is to catch vulnerable devices before they're > hacked. That can't always happen (even with customers and vendors > engaged in best practice patching), but it need only happen often > enough to limit the size of the resulting botnets. This won't work on the majority of devices: they're pre-compromised at the factory. By the time you see the first packet from them, IF you see the first packet from them, it will already be too late. And a lot of them are deliberately designed and built to conduct attacks, e.g.: Vizio tracked and sold your TV viewing habits without consent https://www.engadget.com/2017/02/06/vizio-smart-tv-viewing-history-settlement-ftc/ What a nice favor to do for attackers: Vizio spent its time and money putting this in place for them, so they didn't have to. This is going to get worse -- MUCH worse -- as the few flimsy consumer protections in place are systematically dismantled and the agencies charged with enforcing them defunded. > As I envision it, it's an opt-out system. No. In fact, HELL NO. Too many ISPs have already put absolutely clinching proof on the table that they will silently opt-in customers to all manner of tracking, surveillance, and security/privacy attacks. (I'm looking at you, Verizon, at the moment.) Opt-out is inherently abusive. > Possible, though an ISP which retains the data opens itself to a class > action lawsuit if it can't keep control of it. First, that's a meaningless remedy. Even if someone has the financial resources to sue an ISP, they're going to wind up quietly settling years later, the lawyers will get rich(er), the settlement will be sealed, and they'll just keep right on doing it. See the Vizio case above. Did anybody go to prison? No. Did it cost them anything? Not really: the fine is just chump change. Will Vizio do it again? OF COURSE they will, they'd be crazy not to. All they have to do is wait a little while, rename it, shuffle things around a bit, and they'll be fine. Second, the most likely outcome here is that the ISP will use this data to spy on its users and market to them. The next outcome is that someone inside the ISP will figure out that this is a potential revenue source and start selling it, under the argument that consumers didn't opt-out, therefore they WANT their private data sold. So let's not pretend that the delusional fiction of a successful class-action lawsuit is a deterrent. It's just a belly laugh for the executives and a windfall for the attorneys. > If the ISP can't keep control of its security head-end then sure, at > least until the ISP regains control. I think you're severely underestimating the threat. And note that even though you're just thinking about the problem from the perspective of ISPs, they're not the only ones affected. There are a lot of attack vectors available to anyone who's already on the inside. > Regardless, I encourage you to suggest alternate solutions which don't > run afoul of the problems you mention. The problem isn't going away. I'm aware of that. But this is not the way. I've seen this movie WAY too many times: 1. We must do something 2. This is something. 3. Let's do this. 4. We have done something. 5. Congrats and awards all around, everybody. ---rsk From bill at herrin.us Tue Feb 7 15:55:25 2017 From: bill at herrin.us (William Herrin) Date: Tue, 7 Feb 2017 10:55:25 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> Message-ID: On Tue, Feb 7, 2017 at 8:13 AM, Tom Beecher wrote: >> " any IoT device must _by default_ emit a UDP packet to an >> anycast address reserved for the purpose which identifies the device >> model and software build. " > > Any semi-competent attacker will simply alter the way the network stack on > the device works to make it _not_ look like an IoT device for the purposes > of this check, rendering it moot. Hi Tom, Again, the idea is to remediate devices with insecure software -before- they're breached. Obviously once breached the attacker can present any profile he wants save that it has to emit packets consistent with his desired attack. >> "If the IoT >> device receives the fail message, it must try to report the problem to >> its owner and remove its default route so that it can only communicate >> on the local lan." > > If the vendor isn't thinking about security already, as evidenced by the > current issues with these devices, how are they to be convinced to add code > to make said device do something exceptionally specific? Because it's consistent with the carelessly throw-together free open source software process the trash vendors currently follow and when the industry promotes its "look for the safe network logo" program they won't want to have problems with their retailers over a trivially added bit of free software. > I believe it's important to remember that network endpoints will never be > sure fully secure. They will never be fully in compliance with $standard . > They will never always follow best practices. You can say that again. On Tue, Feb 7, 2017 at 8:58 AM, Ray Soucy wrote: > I think the fundamental problem here is that these devices aren't good > network citizens in the first place. The odds of getting them to add > functionality to support a new protocol are even likely than getting them to > not have open services externally IMHO. Hi Ray, I can speak to that with authority, but again my working theory is that adding the kill switch is consistent with the carelessly throw-together free open source software process the trash vendors currently follow. > Couldn't a lot of this be caught by proactive vulnerability scanning and > working with customers to have an SPI firewall in place, or am I missing > something? One of us is missing something. The customer isn't scanning his network (if he was, we wouldn't have the problem), and from the outside of an SPI firewall how is the ISP supposed to do that? > Historically residential ISP CPE options have been terrible. If you could > deliver something closer to user expectations you would likely see much more > adoption and less desire to rip and replace. The customer buys cool stuff he finds at CostCo. Seeking different behavior seems unlikely to succeed to me. On Tue, Feb 7, 2017 at 9:50 AM, Rich Kulawiec wrote: > On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote: >> Immaterial. The point is to catch vulnerable devices before they're >> hacked. > > This won't work on the majority of devices: they're pre-compromised > at the factory. Well that's a silly misdirection Rich. Manufacturer's misbehavior is a whole different class of problem than equipment breached by a third party after deployment. Unless you claim a convenient way to merge solutions, take it to your own thread. >> If the ISP can't keep control of its security head-end then sure, at >> least until the ISP regains control. > > I think you're severely underestimating the threat. I'm not estimating the threat at all, just stating the precondition for a kill switch to be a denial of service vector. >> Regardless, I encourage you to suggest alternate solutions which don't >> run afoul of the problems you mention. The problem isn't going away. > > I'm aware of that. But this is not the way. I've seen this movie > WAY too many times: > > 1. We must do something > 2. This is something. > 3. Let's do this. > 4. We have done something. > 5. Congrats and awards all around, everybody. And I've heard this song before too: If you choose not to decide you still have made a choice. Neither one of us will like the government solution, so if you have an idea that hasn't already demonstrated its failure, let's hear it. When there's no consensus on an optimal solution, we move forward by trying ideas until something sticks. That's progress, including the attempts which fail. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From aojea at hotmail.com Tue Feb 7 15:56:55 2017 From: aojea at hotmail.com (Antonio Ojea Garcia) Date: Tue, 7 Feb 2017 16:56:55 +0100 Subject: Brainstorming acceptance issues - WAN impediment In-Reply-To: References: Message-ID: Hi, For sure you need to check failover scenarios, reboot the controller or isolate it during some time. 2017-02-06 20:10 GMT+01:00 Kasper Adel : > Hi, > > I am in the process of testing an 'automation/sdn' kind of controller, it > will be managing configuration on our routers and also deploying some VNFs > too. > > Before accepting it, i'd like to perform some testing, to make sure of the > behavior if there are network issues between the controller and the devices > (routers or servers), during creation of services. > > From the top of my head, I can think of the basic tests like introducing > jitter and delay but i would appreciate more ideas or even test cases that > i can re-use. > > Thanks > From hugo at slabnet.com Tue Feb 7 19:09:41 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Tue, 7 Feb 2017 11:09:41 -0800 Subject: Brainstorming acceptance issues - WAN impediment In-Reply-To: References: Message-ID: <20170207190941.GF28625@bamboo.slabnet.com> On Tue 2017-Feb-07 16:56:55 +0100, Antonio Ojea Garcia wrote: >2017-02-06 20:10 GMT+01:00 Kasper Adel : > >> Hi, >> >> I am in the process of testing an 'automation/sdn' kind of controller, it >> will be managing configuration on our routers and also deploying some VNFs >> too. >> >> Before accepting it, i'd like to perform some testing, to make sure of the >> behavior if there are network issues between the controller and the devices >> (routers or servers), during creation of services. >> >> From the top of my head, I can think of the basic tests like introducing >> jitter and delay but i would appreciate more ideas or even test cases that >> i can re-use. >> >> Thanks >> >Hi, > >For sure you need to check failover scenarios, reboot the controller or >isolate it during some time. - Traffic getting blackholed in one direction or the other (e.g. not something obvious like links down or ICMP unreachables) - "fun" things like MTU issues resulting in some traffic getting through but not all - Are there redundant controllers? Can they get split-brained? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From randy at psg.com Tue Feb 7 20:27:50 2017 From: randy at psg.com (Randy Bush) Date: Wed, 08 Feb 2017 05:27:50 +0900 Subject: IoT security In-Reply-To: <20170207145024.GA1224@gsp.org> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> Message-ID: > On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote: >> Immaterial. The point is to catch vulnerable devices before they're >> hacked. you have a 30 second window there, maybe five minutes if you are lucky. From rgolodner at infratection.com Tue Feb 7 20:41:19 2017 From: rgolodner at infratection.com (Richard) Date: Tue, 7 Feb 2017 14:41:19 -0600 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> Message-ID: On 02/07/2017 02:27 PM, Randy Bush wrote: >> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote: >>> Immaterial. The point is to catch vulnerable devices before they're >>> hacked. > you have a 30 second window there, maybe five minutes if you are lucky. > > Looking at my logs from the past couple of months I think you are being generous by giving it thirty seconds. Richard From Charles.Manser at charter.com Tue Feb 7 17:05:31 2017 From: Charles.Manser at charter.com (Manser, Charles J) Date: Tue, 7 Feb 2017 17:05:31 +0000 Subject: ticketmaster.com 403 Forbidden In-Reply-To: <676ebaf4-48c9-1bd4-9de3-1a3fe3c5f97b@bogus.com> References: <20170206160901.GA86663@excession.tpb.net> <0B7AD244-66FD-4CC2-95AD-DCC0316432C4@gmail.com> <64260455-395C-4864-B492-0BFD99EDC89D@gmail.com> <676ebaf4-48c9-1bd4-9de3-1a3fe3c5f97b@bogus.com> Message-ID: <3d031ecfff91450c879c18aaa99cce1f@SC58MEXGP033.CORP.CHARTERCOM.com> All, Thank you for the suggestions. All (3) of the e-mail addresses associated with their ARIN records bounced back. Remote Server returned '< #5.7.133 smtp;550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group>' It can be difficult for consumers to work these issues individually, so we reached out to the NANOG community for an assist. The problem seemed widespread and not isolated to single customers and referring them to a web form did not seem like an option. Good news: I am making some progress with the Live Nation/Ticketmaster team. "Thank you for bringing this to our attention. We are conducting an investigation on suspicious activity that has been observed on the range of IP's are associated to your connectivity and will make every effort to do this as fast as possible." Thank you all again for the help and I will keep the archive updated if we reach a repeatable resolution. Regards, Charles Manser | Principal Engineer I, Network Security Charles.Manser at charter.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of joel jaeggli Sent: Monday, February 06, 2017 7:38 PM To: Suresh Ramasubramanian ; mike.lyon at gmail.com; Ethan E. Dee Cc: Niels Bakker ; nanog at nanog.org Subject: Re: ticketmaster.com 403 Forbidden On 2/6/17 8:49 AM, Suresh Ramasubramanian wrote: > My guess is you have or had sometime in the long distant past a scalper operating on your network, using automated ticket purchase bots. > > If you still have that scalper around, you might want to turf him. If he?s ancient history, saying so might induce them to remove the block. Note that scalper bots benefit from pools of residential ip addresses to work with in subverting the anti-bot countermeasures of ticket sale platforms. so there are the legitimate possibility that subverted hosts are being used for that sort of thing. > --srs > > On 06/02/17, 8:45 AM, "nanog-bounces at nanog.org on behalf of mike.lyon at gmail.com" wrote: > > Yup, i have a /22 that has the same problem. Support is useless... > > > On Feb 6, 2017, at 08:35, Ethan E. Dee wrote: > > > > It gives me a Forbidden error. > > It has for over a year. > > There support says they are not allowed to me why by their policy. > > it is across an entire /19. > > I gave up after the fifth time and encourage the customers to call them individually. > > > >> On 02/06/2017 11:09 AM, Niels Bakker wrote: > >> * Charles.Manser at charter.com (Manser, Charles J) [Mon 06 Feb 2017, 16:21 CET]: > >>> It seems that browsing to ticketmaster.com or any of the associated IP addresses results in a 403 Forbidden for our customers today. Is anyone else having this issue? > >> > >> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/ > >> > >> > >> -- Niels. > > > > > > E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From valdis.kletnieks at vt.edu Tue Feb 7 21:24:52 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 07 Feb 2017 16:24:52 -0500 Subject: Brainstorming acceptance issues - WAN impediment In-Reply-To: References: Message-ID: <58286.1486502692@turing-police.cc.vt.edu> On Mon, 06 Feb 2017 11:10:11 -0800, Kasper Adel said: > From the top of my head, I can think of the basic tests like introducing > jitter and delay but i would appreciate more ideas or even test cases that > i can re-use. Introduce packet loss. Trigger timeouts. Arrange to have packets arrive out of order. Send it fragged packets. Send it fragged packets of incorrect length. Send it fragged packets, and omit one frag and see if it behaves. Test its behavior if the frags overlap, or the offset of a packet plus its size put it over 64K. Send it christmas tree packets. Send it commands that aren't authenticated by whatever you're using. Find out what the underlying OS (probably linux or *bsd), and hose it down with nmap to find surprises. Syn-flood it. Send it a long sequence of commands that change from state 1 to state 2 and back, see if it gets confused if the commands arrive faster than the amount of time it takes to process a command. I could probably think of more, but I'm low on caffeine at the moment... https://twitter.com/sempf/status/514473420277694465 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From bill at herrin.us Tue Feb 7 22:05:21 2017 From: bill at herrin.us (William Herrin) Date: Tue, 7 Feb 2017 17:05:21 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> Message-ID: On Tue, Feb 7, 2017 at 3:27 PM, Randy Bush wrote: >> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote: >>> Immaterial. The point is to catch vulnerable devices before they're >>> hacked. > > you have a 30 second window there, maybe five minutes if you are lucky. Hi Randy, I'd expect a tattler kill switch to take maybe a tenth of that from the anycast notification when the nic comes up to the ISPs response that it is known to be vulnerable and should disconnect. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From mike at mtcc.com Tue Feb 7 22:14:03 2017 From: mike at mtcc.com (Michael Thomas) Date: Tue, 7 Feb 2017 14:14:03 -0800 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> Message-ID: <484b6c78-d00f-f872-a22e-707f0063eecc@mtcc.com> On 02/07/2017 02:05 PM, William Herrin wrote: > On Tue, Feb 7, 2017 at 3:27 PM, Randy Bush wrote: >>> On Tue, Feb 07, 2017 at 06:56:40AM -0500, William Herrin wrote: >>>> Immaterial. The point is to catch vulnerable devices before they're >>>> hacked. >> you have a 30 second window there, maybe five minutes if you are lucky. > Hi Randy, > > I'd expect a tattler kill switch to take maybe a tenth of that from > the anycast notification when the nic comes up to the ISPs response > that it is known to be vulnerable and should disconnect. assuming that it wasn't conveniently factory installed, cf usb sticks. Mike From nagarjun.govindraj at imaginea.com Wed Feb 8 08:48:25 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Wed, 08 Feb 2017 08:48:25 +0000 Subject: Data Plane open solutions available for BGP Prefix hijacking Message-ID: Hi All, Does there exists any open source implementations for detection of BGP prefix hijacking using data plane solutions. If not data plane, what are the methods used for detecting BGP IP prefix hijacking. Regards, Nagarjun From fourzerofour at gmail.com Wed Feb 8 12:51:57 2017 From: fourzerofour at gmail.com (Justin) Date: Wed, 8 Feb 2017 07:51:57 -0500 Subject: Data Plane open solutions available for BGP Prefix hijacking In-Reply-To: References: Message-ID: Christos Papadopoulos from Colorado State University just spoke about this yesterday at NANOG 69. The presentation https://www.nanog.org/sites/default/files/3_Papadopoulos_Bgpmon_The_Next_v1.pdf. I'm sure the video will be out soon if it isn't already. On Wed, Feb 8, 2017 at 3:48 AM, Nagarjun Govindraj via NANOG < nanog at nanog.org> wrote: > Hi All, > > Does there exists any open source implementations for detection of BGP > prefix hijacking using data plane solutions. > > If not data plane, what are the methods used for detecting BGP IP prefix > hijacking. > > Regards, > Nagarjun > From dvandyk at akamai.com Wed Feb 8 14:05:41 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Wed, 8 Feb 2017 14:05:41 +0000 Subject: ATT-Level 3 Peering In-Reply-To: References: Message-ID: <8495A668-B232-4467-B8CB-13A11CAD0364@akamai.com> We?ve been running into a lot of problems lately with ATT peering lately. Level3 included. We have multiple carriers and most of them have run into this issue over the past couple months where there is congestion between ATT and our carriers, it appears there is a political issue on who should pay for the peering and bandwidth. My colleague says he heard on the grapevine (Horrible source I know) that ATT is playing super hardball and requesting big cash for peering with them. Anyways, that?s all I got. Cheers -- Donovan Van Dyk The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. On 2/5/17, 8:21 PM, "david peahi" wrote: We're seeing frequent dropped packets between ATT and Level 3 in Atlanta with traffic sourced from an ATT user destined for Microsoft Office 365, making Office 365 apps unusable during critical business hours. Anyone else have this problem with ATT? From dvandyk at akamai.com Wed Feb 8 14:21:11 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Wed, 8 Feb 2017 14:21:11 +0000 Subject: Telia network quality In-Reply-To: References: Message-ID: <0B3A6BCE-4FDD-4991-B1EF-3742EC5EAEA3@akamai.com> We use them globally and often work with their teams. Pros ? customer service is excellent, very fast response times and good engineers. They are don?t beat around the bush if the issue is their fault, they will come right out and tell you so you can stop scrambling. They are also pretty good at resolving the issues on their network in a timely manner. Cons ? Out of all our carriers, they have the most problems. Most of the time it comes down to minor issues in their NA and EU backbone, sometimes congestion in the backbone. We have very network sensitive traffic so we pick up on most internet issues. They?ve also had the most mis-configuration issues of all our carriers. The configuration issues were quite a while ago. We got on them pretty hard about this and since then no more configuration issues. All in all, their service is good and have no problem recommending them. Good luck -- Donovan Van Dyk The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. On 2/2/17, 11:12 AM, "Don" wrote: I heard Telia's quality had been on the decline lately as they were signing on lots of high-capacity new customers, and Cloudflare had some complaint about them a few months prior too. Does anybody have any insight into whether this is still the case? I was trying to evaluate whether Telia would be a good carrier to switch over to as a primary provider, as their pricing does look pretty attractive. B/R Don From ed.lopez at corsa.com Tue Feb 7 22:01:29 2017 From: ed.lopez at corsa.com (Ed Lopez) Date: Tue, 07 Feb 2017 22:01:29 +0000 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> Message-ID: In a recent article ( https://www.schneier.com/blog/archives/2017/02/security_and_th.html), Bruce Schneier sums up the IoT security mitigation issue quite nicely in this paragraph: "The market can't fix this because neither the buyer nor the seller cares. The owners of the webcams and DVRs used in the denial-of-service attacks don't care. Their devices were cheap to buy, they still work, and they don't know any of the victims of the attacks. The sellers of those devices don't care: They're now selling newer and better models, and the original buyers only cared about price and features. There is no market solution, because the insecurity is what economists call an externality: It's an effect of the purchasing decision that affects other people. Think of it kind of like invisible pollution." - Ed Lopez -- Ed Lopez | Security Architect | Corsa Technology Email: ed.lopez at corsa.com Mobile: +1.703.220.0988 www.corsa.com sent from my iPad ... I apologize for any auto-correct errors From Klaas.Tammling at akquinet.de Wed Feb 8 09:33:38 2017 From: Klaas.Tammling at akquinet.de (Tammling, Klaas) Date: Wed, 8 Feb 2017 09:33:38 +0000 Subject: AW: Telia network quality In-Reply-To: References: , Message-ID: <1486546418356.53160@akquinet.de> We are connected to Telia in Europe for about 2 years now. We've never had any issues with them and the response times of the NOC, when we do have questions, have always been great. Latencies to several destinations are good and we don't have any bandwidth issues. ________________________________________ Von: NANOG im Auftrag von Eric Dugas Gesendet: Dienstag, 7. Februar 2017 15:19 An: NANOG Betreff: Re: Telia network quality Was connected to them in NYC and in the past two years, we only had one issue and it was a faulty card in one of their core. New workplace is connected to them in Montreal. No issue so far! On Feb 7 2017, at 9:14 am, James Stankiewicz wrote: > We have been using Telia for the last several years and they have top notch!! > > On Tue, Feb 7, 2017 at 7:24 AM, Dmitry Sherman wrote: > > > Same here 2 BGP flaps in past week. > > Dmitry Sherman > dmitry at interhost.net > Interhost Networks Ltd > Web: > fb: https://www.facebook.com/InterhostIL > Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157 > > > \-----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Greg Sowell > Sent: Sunday, February 5, 2017 1:37 AM > To: Kaiser, Erich > Cc: nanog at nanog.org > Subject: Re: Telia network quality > > I've been using them out of Dallas for about 2.5 years now with very good > success. Their NOC has been top notch in responding to our issues, though > I've seen repeated peering issues for them with a single provider, but > who's to say that's their fault and not the other parties? > > On Thu, Feb 2, 2017 at 8:55 PM, Kaiser, Erich wrote: > > > I would say that information is not 100% accurate. We use Telia for > > waves nationwide and also have several DIA ingest(transit) points from > > them. If anything, the IRU carriers they are using may have a problem > > sometimes due to fiber cuts, but that is why you build redundant paths. > > > > They are very ontop of the ball when one of the waves goes down. We > > actually don't utilize a ton of their transit due to the nature of our > > network design, because we are connected to all of the major IXs. > > > > Erich Kaiser > > The Fusion Network > > erich at gotfusion.net > > Office: 630-621-4804 > > Cell: 630-777-9291 > > > > > > > > On Thu, Feb 2, 2017 at 10:12 AM, Don wrote: > > > > > I heard Telia's quality had been on the decline lately as they were > > > signing on lots of high-capacity new customers, and Cloudflare had > > > some complaint about them a few months prior too. Does anybody have > > > any > > insight > > > into whether this is still the case? I was trying to evaluate > > > whether > > Telia > > > would be a good carrier to switch over to as a primary provider, as > > > their pricing does look pretty attractive. > > > > > > B/R > > > Don > > > > > > \-- > \-------------------------------- > GregSowell.com > TheBrothersWISP.com > StrayaNet.com > > This mail was received via PineApp Mail-SeCure System. > > > > > \-- *Jim Stankiewicz* *NJEDge.Net* stankiewicz at njedge.net From rsk at gsp.org Wed Feb 8 15:12:54 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 8 Feb 2017 10:12:54 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> Message-ID: <20170208151254.GA14304@gsp.org> On Tue, Feb 07, 2017 at 10:01:29PM +0000, Ed Lopez quoted Bruce Schneier: > There is no market solution, because the insecurity is what economists > call an externality: It's an effect of the purchasing decision that > affects other people. This is precisely correct. The only way to change this is to make *our* problem *their* problem. Let me remind everyone of one of very best things ever said on this mailing list: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie This movie has been playing here 24x7 for the last few decades with the spam problem (among others): most operations which emit it will take absolutely no action of any kind until/unless it stops being *our* problem and starts being *their* problem. Having observed and studied that particular issue since it existed to be observed and studied, I've concluded that the only thing that has ever worked effectively is blacklisting: that is, the revocation of access/service privileges. And that's because it makes *our* problem *their* problem. Everything else is just avoidance and evasion. It's feel-good stuff that might, on a good day, deal with the symptoms of the problem -- but that's all it is. And dealing with symptoms isn't bad, per se: it makes the patient feel better. But it should never be accepted as a substitute for dealing with the underlying problem. Now we can either spend another couple more decades trying to tapdance around this or we can learn the lesson that's been taught to us thousands of times over many years and just cut to the chase. So how about if we save some time? If IOT-driven attacks and abuse are coming from X, then that needs to be made X's problem. Because right now X has no idea that this is happening, and even if told, will take no action because it's not X's problem. So make it X's problem. And I don't just mean "X", the person who bought some badly-designed poorly-engineered rushed-to-market never-tested piece of shiny new cruft that was pre-compromised at the factory and hijacked by attackers the moment it went live: I mean "X" the vendor who pulled that stunt in order to make a quick buck and then dumped it on us. We, for many values of "we" are not obligated to provide services to that vendor. (I do recognize that some are, due to contractual agreements.) We should cut them off until/unless they recall all those devices, get them removed from service, and solve what is now *their* problem to *our* satisfaction. I strongly suspect that it'll only take a few pointed lessons in order for the message that this conduct is unacceptable to be communicated in a language they understand. I don't like this. In a better world, vendors would be far more responsible, professional, and ethical. But we don't live in that world. We live in one where they will happily dump toxic waste on the Internet as fast as they can shovel it -- as long as it's not their problem. We need to make it their problem. ---rsk From bill at herrin.us Wed Feb 8 15:22:11 2017 From: bill at herrin.us (William Herrin) Date: Wed, 8 Feb 2017 10:22:11 -0500 Subject: IoT security In-Reply-To: <20170208151254.GA14304@gsp.org> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> Message-ID: On Wed, Feb 8, 2017 at 10:12 AM, Rich Kulawiec wrote: > In a better world, vendors would be far more > responsible, professional, and ethical. But we don't live in that > world. We live in one where they will happily dump toxic waste on > the Internet as fast as they can shovel it -- as long as it's not > their problem. > > We need to make it their problem. How? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From menscher at gmail.com Wed Feb 8 16:30:15 2017 From: menscher at gmail.com (Damian Menscher) Date: Wed, 8 Feb 2017 08:30:15 -0800 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> Message-ID: On Wed, Feb 8, 2017 at 7:22 AM, William Herrin wrote: > On Wed, Feb 8, 2017 at 10:12 AM, Rich Kulawiec wrote: > > In a better world, vendors would be far more > > responsible, professional, and ethical. But we don't live in that > > world. We live in one where they will happily dump toxic waste on > > the Internet as fast as they can shovel it -- as long as it's not > > their problem. > > > > We need to make it their problem. > > How? The devices are trivially compromised (just log in with the default root password). So here's a modest proposal: log in as root and brick the device. This will encourage the consumer to seek a solution. When 100k consumers all discover their devices broke at the same time, they'll file a class-action lawsuit against the manufacturer, or at least never buy from them again. Market forces then solve the problem naturally, both for that manufacturer and for others who don't want the same fate. I realize there are drawbacks (including legal implications) to this method (which is why I'm posting from a personal, not work, account). But I challenge anyone to propose another solution that will work as well. Most other proposals I've heard depend on individual ISPs to take action, or governments to regulate devices and hope that foreign manufacturers care, or .... Damian From bill at herrin.us Wed Feb 8 16:40:25 2017 From: bill at herrin.us (William Herrin) Date: Wed, 8 Feb 2017 11:40:25 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> Message-ID: On Wed, Feb 8, 2017 at 11:30 AM, Damian Menscher wrote: > On Wed, Feb 8, 2017 at 7:22 AM, William Herrin wrote: >> On Wed, Feb 8, 2017 at 10:12 AM, Rich Kulawiec wrote: >> > We need to make it their problem. >> >> How? > > > The devices are trivially compromised (just log in with the default root > password). So here's a modest proposal: log in as root and brick the > device. Okay, so within the confines of lawful activity, how? 'Cause I'm guessing that coordinated criminal activity is going to be a community non-starter. At least when it's this unambiguous. ;) Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From john at west-canaan.net Wed Feb 8 19:13:58 2017 From: john at west-canaan.net (John Zettlemoyer) Date: Wed, 8 Feb 2017 14:13:58 -0500 Subject: Telia network quality Message-ID: <0fb835f8-394a-4dd1-b036-0140e0f7e932@west-canaan.net> We've been using Telia for about 3 years in Philly, and have great success. Most of our European customers noticed faster services right away when we turned them up. John Zettlemoyer Sr. Director of I.T. Infrastructure ::? WCiT LLC 856.310.1375 x221 :: john at wcit.net :: www.wcit.net Philadelphia now has an IX! www.peering.exchange From lists at mtin.net Wed Feb 8 22:44:58 2017 From: lists at mtin.net (Justin Wilson) Date: Wed, 8 Feb 2017 17:44:58 -0500 Subject: ATT-Level 3 Peering In-Reply-To: <8495A668-B232-4467-B8CB-13A11CAD0364@akamai.com> References: <8495A668-B232-4467-B8CB-13A11CAD0364@akamai.com> Message-ID: <99C7CF45-61CC-49CB-B5FF-AB98A819973E@mtin.net> I had a very clueless ATT salesperson tell me yesterday that ?Our company policy is we don?t do BGP sessions.? I have a client wanting to use ATT as an upstream and they won?t do BGP (mainly due to clueless sales). If this is the level of comp tenancy then good luck. :-) Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Feb 8, 2017, at 9:05 AM, Van Dyk, Donovan via NANOG wrote: > > We?ve been running into a lot of problems lately with ATT peering lately. Level3 included. > > We have multiple carriers and most of them have run into this issue over the past couple months where there is congestion between ATT and our carriers, it appears there is a political issue on who should pay for the peering and bandwidth. > My colleague says he heard on the grapevine (Horrible source I know) that ATT is playing super hardball and requesting big cash for peering with them. > > Anyways, that?s all I got. > > Cheers > > -- > Donovan Van Dyk > > > > > The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. > > > On 2/5/17, 8:21 PM, "david peahi" wrote: > > We're seeing frequent dropped packets between ATT and Level 3 in Atlanta > with traffic sourced from an ATT user destined for Microsoft Office 365, > making Office 365 apps unusable during critical business hours. Anyone else > have this problem with ATT? > > From myoon at mikeyoon.com Wed Feb 8 15:26:49 2017 From: myoon at mikeyoon.com (Michael Yoon) Date: Wed, 8 Feb 2017 10:26:49 -0500 Subject: IoT security Message-ID: Very clear illustration, thanks for sharing. It would seem solution would involve non market regulation (EPA for pollution), or aligning with market forces such as aligning impact to buyer of security with risk of public access to compromised information (like videos from IP cameras). Michael Yoon On Feb 8, 2017 9:36 AM, "Ed Lopez" wrote: In a recent article ( https://www.schneier.com/blog/archives/2017/02/security_and_th.html), Bruce Schneier sums up the IoT security mitigation issue quite nicely in this paragraph: "The market can't fix this because neither the buyer nor the seller cares. The owners of the webcams and DVRs used in the denial-of-service attacks don't care. Their devices were cheap to buy, they still work, and they don't know any of the victims of the attacks. The sellers of those devices don't care: They're now selling newer and better models, and the original buyers only cared about price and features. There is no market solution, because the insecurity is what economists call an externality: It's an effect of the purchasing decision that affects other people. Think of it kind of like invisible pollution." - Ed Lopez -- Ed Lopez | Security Architect | Corsa Technology Email: ed.lopez at corsa.com Mobile: +1.703.220.0988 www.corsa.com sent from my iPad ... I apologize for any auto-correct errors From carl at five-ten-sg.com Thu Feb 9 02:03:16 2017 From: carl at five-ten-sg.com (Carl Byington) Date: Wed, 08 Feb 2017 18:03:16 -0800 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> Message-ID: <1486605796.15263.13.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-02-08 at 08:30 -0800, Damian Menscher wrote: > So here's a modest proposal: log in as root and brick the > device. I strongly suspect that when the problem gets bad *enough*, someone will do exactly that. Yes, it is illegal in many places. Since when has the fact that any particular act is illegal been sufficient to deter *everyone*? People still drive while drunk. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlibzdIACgkQL6j7milTFsH/WgCdEvde+zMvm8lRUyx2ay3EltZT 97kAn3Hl2tjPe2eUqiagDXxlE75OO/Xg =W+Cq -----END PGP SIGNATURE----- From mvoity at uvm.edu Thu Feb 9 03:11:57 2017 From: mvoity at uvm.edu (Michael Voity) Date: Thu, 9 Feb 2017 03:11:57 +0000 Subject: American Airlines down Message-ID: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> Hello Stuck at DCA after NANOG because America airlines system are down. Anyone know anything? Mike Sent from my iPhone From mvoity at uvm.edu Thu Feb 9 03:12:54 2017 From: mvoity at uvm.edu (Michael Voity) Date: Thu, 9 Feb 2017 03:12:54 +0000 Subject: American Airlines down In-Reply-To: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> References: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> Message-ID: Looks like it _just_ came back..... Sent from my iPhone > On Feb 8, 2017, at 22:12, Michael Voity wrote: > > Hello > > Stuck at DCA after NANOG because America airlines system are down. > > Anyone know anything? > > Mike > > Sent from my iPhone From pr at isprime.com Thu Feb 9 03:15:31 2017 From: pr at isprime.com (Phil Rosenthal) Date: Wed, 8 Feb 2017 22:15:31 -0500 Subject: American Airlines down In-Reply-To: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> References: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> Message-ID: <8A21D567-E96A-4F81-B230-7ED7FB7685E8@isprime.com> http://www.flyertalk.com/forum/american-airlines-aadvantage/1820617-aa-com-technical-outage-8feb17.html > On Feb 8, 2017, at 10:11 PM, Michael Voity wrote: > > Hello > > Stuck at DCA after NANOG because America airlines system are down. > > Anyone know anything? > > Mike > > Sent from my iPhone From omonnig at gmail.com Thu Feb 9 03:17:32 2017 From: omonnig at gmail.com (Otto Monnig) Date: Wed, 8 Feb 2017 21:17:32 -0600 Subject: American Airlines down In-Reply-To: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> References: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> Message-ID: Downdetector spiking at 20:00. Reports that captains cannot get flight plans because computers are down. -- Otto Monnig omonnig at gmail.com > On Feb 8, 2017, at 9:11 PM, Michael Voity wrote: > > Hello > > Stuck at DCA after NANOG because America airlines system are down. > > Anyone know anything? > > Mike > > Sent from my iPhone From brett at the-watsons.org Thu Feb 9 03:21:57 2017 From: brett at the-watsons.org (Brett Watson) Date: Wed, 8 Feb 2017 19:21:57 -0800 Subject: American Airlines down In-Reply-To: References: <181E3517-FFBC-4ACC-8E2E-D893B3664DF2@uvm.edu> Message-ID: <8601513D-78FC-4CBE-9321-4158F76EBBBA@the-watsons.org> > On Feb 8, 2017, at 19:12, Michael Voity wrote: > > Looks like it _just_ came back..... > I was delayed at LAX but apparently a global reboot of Windows actually worked and I'm on my plane. -b From clinton.mielke at gmail.com Thu Feb 9 05:04:07 2017 From: clinton.mielke at gmail.com (clinton mielke) Date: Wed, 8 Feb 2017 21:04:07 -0800 Subject: IoT security In-Reply-To: <1486605796.15263.13.camel@ns.five-ten-sg.com> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> Message-ID: Having spent the last few months systematically scanning ~700k of these hosts, Im thinking the following could be considered: As an ISP, scan your customers netrange, and notify customers with known vulnerable devices. With regards to the current Mirai threat, theres only a handful of devices that are the most critical importance. IE, biggest fraction of the infected host pie. Maybe someday I'll get around to parsing my database and auto-emailing the abuse emails of the affected netranges. That was my intention..... but dayjob got in the way. This breaks down however when you look at the geographic distribution of infected devices. Most are in Asian countries, so there would need to be more cooperation among network operators there. On Wed, Feb 8, 2017 at 6:03 PM, Carl Byington wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Wed, 2017-02-08 at 08:30 -0800, Damian Menscher wrote: > > So here's a modest proposal: log in as root and brick the > > device. > > I strongly suspect that when the problem gets bad *enough*, someone will > do exactly that. Yes, it is illegal in many places. Since when has the > fact that any particular act is illegal been sufficient to deter > *everyone*? > > People still drive while drunk. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlibzdIACgkQL6j7milTFsH/WgCdEvde+zMvm8lRUyx2ay3EltZT > 97kAn3Hl2tjPe2eUqiagDXxlE75OO/Xg > =W+Cq > -----END PGP SIGNATURE----- > > > From valdis.kletnieks at vt.edu Thu Feb 9 06:00:02 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 09 Feb 2017 01:00:02 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> Message-ID: <105404.1486620002@turing-police.cc.vt.edu> On Wed, 08 Feb 2017 21:04:07 -0800, clinton mielke said: > As an ISP, scan your customers netrange, and notify customers with known > vulnerable devices. With regards to the current Mirai threat, theres only a > handful of devices that are the most critical importance. IE, biggest > fraction of the infected host pie. Do enough of these poorly designed devices punch themselves a UPNP hole in the CPE firewall and make themselves detectable, to make this a viable approach? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From clinton.mielke at gmail.com Thu Feb 9 06:19:01 2017 From: clinton.mielke at gmail.com (clinton mielke) Date: Wed, 8 Feb 2017 22:19:01 -0800 Subject: IoT security In-Reply-To: <105404.1486620002@turing-police.cc.vt.edu> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> <105404.1486620002@turing-police.cc.vt.edu> Message-ID: Yup! All the mapping Ive done is over port 80. Id have a lot more than I currently have if I was looking at other ports, probably. On Wed, Feb 8, 2017 at 10:00 PM, wrote: > On Wed, 08 Feb 2017 21:04:07 -0800, clinton mielke said: > > > As an ISP, scan your customers netrange, and notify customers with known > > vulnerable devices. With regards to the current Mirai threat, theres > only a > > handful of devices that are the most critical importance. IE, biggest > > fraction of the infected host pie. > > Do enough of these poorly designed devices punch themselves a UPNP hole > in the CPE firewall and make themselves detectable, to make this a viable > approach? > From ramy.ihashish at gmail.com Thu Feb 9 11:32:46 2017 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Thu, 9 Feb 2017 13:32:46 +0200 Subject: Bandwidth Savings (Keenan Singh) Message-ID: Hello Luke and all, I stumbled upon some news about Facebook edge network servers, does anybody know anything about the caches the FB use and the ISPs can host? and is Facebook a part of SVA alliance? Thanks, Ramy Hi Luke, > > Regarding HTTPS Streaming and Netflix... > > Netflix announced in the spring of 2015 that it would move to HTTPS > delivery by April of 2016. At the time of that first announcement, some > concluded Netflix might not be able to afford the capital investment > required to enable HTTPS delivery. > > Given Netflix did not complete the HTTPS project by their first deadline, > we believe they have been focused on other priorities such as their global > expansion, So, given this history, it's not clear just when or if Netflix > will make the move to majority HTTPS for delivery. Furthermore, Netflix is > under considerable pressure from investors to improve subscriber growth, > revenue growth and profitability. The HTTPS project does not support any of > these goals. In fact, Netflix reported net income is marginal and a move to > full HTTPS delivery would likely consume all profits for the year. > > Along with the rest of the industry, we recognize the need for Open > Caching systems to support HTTPS streaming from upstream content > providers. This is one of the reasons why we were a Founding Member, along > with 16 other streaming companies, in the Streaming Video Alliance in the > fall of 2014. The SVA now includes almost 50 member companies from across > the streaming ecosystem and around the world. More importantly, the Open > Caching Working Group has issued functional requirements, unanimously > approved by SVA members, which include support for HTTPS streams. > > The SVA Board has invited Netflix to join the Alliance and, in doing so, > endorse the Open Caching work underway. This would open up a path in the > short run to ensure any open cache can continue to support Netflix content > even if Netflix moves to HTTPS delivery. We expect to see Netflix become > more active in the SVA soon given other major streaming providers, such as > Hulu and Amazon, are joining now. > > In conclusion, the SVA has developed a solution for Open Cache support of > HTTPS streaming and we expect all streaming providers, including Netflix, > will align with the SVA's direction. > > http://www.streamingvideoalliance.org/ > > Let me know if you have any more questions. > > Regards, > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keenan Singh > Sent: Tuesday, January 10, 2017 10:09 PM > To: nanog at nanog.org > Subject: Bandwidth Savings > > Hi Guys > > We are an ISP in the Caribbean, and are faced with extremely high > Bandwidth costs, compared to the US, we currently use Peer App for Caching > however with most services now moving to HTTPS the cache is proving to be > less and less effective. We are currently looking at any way we can save on > Bandwidth or to be more Efficient with the Bandwidth we currently have. We > do have a Layer 2 Circuit between the Island and Miami, I am seeing there > are WAN Accelerators where they would put a Server on either end and sort > of Compress and decompress the Traffic before it goes over the Layer 2, I > have never used this before, has any one here used anything like this, what > results would I be able to expect for ISP Traffic? > > If not any ideas on Bandwidth Savings, or being more Efficient with want > we currently. > > Many thanks for any Help > > Keenan > > From keenansingh at airlinktt.net Thu Feb 9 12:40:14 2017 From: keenansingh at airlinktt.net (Keenan Singh) Date: Thu, 9 Feb 2017 07:40:14 -0500 Subject: Bandwidth Savings (Keenan Singh) In-Reply-To: References: Message-ID: Hi Ramy I reached out to FB and they are looking for a min of 5G Traffic coming from your AS to qualify for a Cache. Not sure how they came up with 5G as normally everyone else would ask for 1G Traffic. Can anyone one else confirm, maybe some one from FB is here and can clarify? Keenan On Feb 9, 2017 6:32 AM, "Ramy Hashish" wrote: Hello Luke and all, I stumbled upon some news about Facebook edge network servers, does anybody know anything about the caches the FB use and the ISPs can host? and is Facebook a part of SVA alliance? Thanks, Ramy Hi Luke, > > Regarding HTTPS Streaming and Netflix... > > Netflix announced in the spring of 2015 that it would move to HTTPS > delivery by April of 2016. At the time of that first announcement, some > concluded Netflix might not be able to afford the capital investment > required to enable HTTPS delivery. > > Given Netflix did not complete the HTTPS project by their first deadline, > we believe they have been focused on other priorities such as their global > expansion, So, given this history, it's not clear just when or if Netflix > will make the move to majority HTTPS for delivery. Furthermore, Netflix is > under considerable pressure from investors to improve subscriber growth, > revenue growth and profitability. The HTTPS project does not support any of > these goals. In fact, Netflix reported net income is marginal and a move to > full HTTPS delivery would likely consume all profits for the year. > > Along with the rest of the industry, we recognize the need for Open > Caching systems to support HTTPS streaming from upstream content > providers. This is one of the reasons why we were a Founding Member, along > with 16 other streaming companies, in the Streaming Video Alliance in the > fall of 2014. The SVA now includes almost 50 member companies from across > the streaming ecosystem and around the world. More importantly, the Open > Caching Working Group has issued functional requirements, unanimously > approved by SVA members, which include support for HTTPS streams. > > The SVA Board has invited Netflix to join the Alliance and, in doing so, > endorse the Open Caching work underway. This would open up a path in the > short run to ensure any open cache can continue to support Netflix content > even if Netflix moves to HTTPS delivery. We expect to see Netflix become > more active in the SVA soon given other major streaming providers, such as > Hulu and Amazon, are joining now. > > In conclusion, the SVA has developed a solution for Open Cache support of > HTTPS streaming and we expect all streaming providers, including Netflix, > will align with the SVA's direction. > > http://www.streamingvideoalliance.org/ > > Let me know if you have any more questions. > > Regards, > > > > Luke Guillory > Network Operations Manager > > Tel: 985.536.1212 <(985)%20536-1212> > Fax: 985.536.0300 <(985)%20536-0300> > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Keenan Singh > Sent: Tuesday, January 10, 2017 10:09 PM > To: nanog at nanog.org > Subject: Bandwidth Savings > > Hi Guys > > We are an ISP in the Caribbean, and are faced with extremely high > Bandwidth costs, compared to the US, we currently use Peer App for Caching > however with most services now moving to HTTPS the cache is proving to be > less and less effective. We are currently looking at any way we can save on > Bandwidth or to be more Efficient with the Bandwidth we currently have. We > do have a Layer 2 Circuit between the Island and Miami, I am seeing there > are WAN Accelerators where they would put a Server on either end and sort > of Compress and decompress the Traffic before it goes over the Layer 2, I > have never used this before, has any one here used anything like this, what > results would I be able to expect for ISP Traffic? > > If not any ideas on Bandwidth Savings, or being more Efficient with want > we currently. > > Many thanks for any Help > > Keenan > > From rsk at gsp.org Thu Feb 9 17:04:40 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 9 Feb 2017 12:04:40 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> Message-ID: <20170209170440.GA25494@gsp.org> On Wed, Feb 08, 2017 at 08:30:15AM -0800, Damian Menscher wrote: > The devices are trivially compromised (just log in with the default root > password). So here's a modest proposal: log in as root and brick the > device. No. It's never a good idea to respond to abuse with abuse. Not only is it unethical and probably illegal (IANAL, this is not legal advice) but it won't take more than a day for someone to figure out that this is happening and use some variety of misdirection to cause third parties to target devices that aren't actually part of the problem. ---rsk From bill at herrin.us Thu Feb 9 19:54:26 2017 From: bill at herrin.us (William Herrin) Date: Thu, 9 Feb 2017 14:54:26 -0500 Subject: IoT security In-Reply-To: <20170209170440.GA25494@gsp.org> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <20170209170440.GA25494@gsp.org> Message-ID: On Thu, Feb 9, 2017 at 12:04 PM, Rich Kulawiec wrote: > On Wed, Feb 08, 2017 at 08:30:15AM -0800, Damian Menscher wrote: >> The devices are trivially compromised (just log in with the default root >> password). So here's a modest proposal: log in as root and brick the >> device. > > No. It's never a good idea to respond to abuse with abuse. Hi Rich, On that we agree. Vigilantism is a non-starter. > [regarding the tattler kill switch] > 2. This will allow ISPs to build a database of which customers have > which IOT devices. This is an appalling invasion of privacy. Is there some way an industry association could overcome this? Perhaps have some trivial way to assign each model of IoT device some kind of integer and have the device report the integer instead of its plain text manufacturer and hardware model number? Where the assigned integer is intentionally not published by the industry association though of course trivially determinable by anyone who owns one of the devices. Wouldn't especially impair building a database of vulnerable devices but it would raise the bar for trying to turn the self-reporting in to business intelligence. Particularly if industry association rules forbid retaining a record of device self-reports on pain of whatever. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rod.beck at unitedcablecompany.com Thu Feb 9 19:55:16 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 9 Feb 2017 19:55:16 +0000 Subject: 350 East Main - Buffalo In-Reply-To: <1486546418356.53160@akquinet.de> References: , , <1486546418356.53160@akquinet.de> Message-ID: Looking for a customer list for this building. Best, Roderick. From valdis.kletnieks at vt.edu Thu Feb 9 20:03:55 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 09 Feb 2017 15:03:55 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> <105404.1486620002@turing-police.cc.vt.edu> Message-ID: <167072.1486670635@turing-police.cc.vt.edu> On Wed, 08 Feb 2017 22:19:01 -0800, clinton mielke said: > Yup! All the mapping Ive done is over port 80. Id have a lot more than I > currently have if I was looking at other ports, probably. Wow. How does this work if more than one IoPT(*) device is in play in the home network, especially from different manufacturers? (*) Internet of Pwned Things. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From clinton at scripty.com Thu Feb 9 20:13:21 2017 From: clinton at scripty.com (Clinton Work) Date: Thu, 09 Feb 2017 13:13:21 -0700 Subject: GTT AS3257 router server Message-ID: <1486671201.1573374.876038768.6119C1ED@webmail.messagingengine.com> If anybody is reading the NANOG list from the GTT NOC, can you look at your route-server with the BGP session flapping every couple of minutes. route-server.as3257.net>show ip bgp sum Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 213.200.64.93 4 3257 68799843 331607 0 0 0 00:00:50 Active -- Clinton Work From valdis.kletnieks at vt.edu Thu Feb 9 20:18:15 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 09 Feb 2017 15:18:15 -0500 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <20170209170440.GA25494@gsp.org> Message-ID: <168192.1486671495@turing-police.cc.vt.edu> On Thu, 09 Feb 2017 14:54:26 -0500, William Herrin said: > Is there some way an industry association could overcome this? Perhaps > have some trivial way to assign each model of IoT device some kind of > integer and have the device report the integer instead of its plain > text manufacturer and hardware model number? Where the assigned > integer is intentionally not published by the industry association > though of course trivially determinable by anyone who owns one of the > devices. Or anybody who knows how to use the internet to look for reports of owners who have issues. All it takes is one smarter than the average bear user posting "I've got a MobyWombat 3000 light bulb, and it keeps sending 1193432542 to some server someplace...." > Wouldn't especially impair building a database of vulnerable > devices but it would raise the bar for trying to turn the If it doesn't *heavily* impair building a database of vulnerable devices, it's not a solution to the problem under discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From clinton.mielke at gmail.com Thu Feb 9 20:28:11 2017 From: clinton.mielke at gmail.com (clinton mielke) Date: Thu, 9 Feb 2017 12:28:11 -0800 Subject: IoT security In-Reply-To: <167072.1486670635@turing-police.cc.vt.edu> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> <105404.1486620002@turing-police.cc.vt.edu> <167072.1486670635@turing-police.cc.vt.edu> Message-ID: It probably doesn't account for those situations. In the case of security products, it's also likely that multiple devices are hosting port 80 But it doesn't matter too much. Having this kind of data helps us prioritize what devices have the biggest chunk of the infected pie. On Feb 9, 2017 12:04 PM, wrote: > On Wed, 08 Feb 2017 22:19:01 -0800, clinton mielke said: > > > Yup! All the mapping Ive done is over port 80. Id have a lot more than I > > currently have if I was looking at other ports, probably. > > Wow. How does this work if more than one IoPT(*) > device is in play in the home network, especially from different > manufacturers? > > (*) Internet of Pwned Things. > From adam at davenpro.com Thu Feb 9 22:03:39 2017 From: adam at davenpro.com (Adam Davenport) Date: Thu, 9 Feb 2017 17:03:39 -0500 Subject: GTT AS3257 router server In-Reply-To: <1486671201.1573374.876038768.6119C1ED@webmail.messagingengine.com> References: <1486671201.1573374.876038768.6119C1ED@webmail.messagingengine.com> Message-ID: <7ee4cf59-bf1f-320d-01e2-fed97b8dfa3b@davenpro.com> Clinton, I'll give this a look on our side and ping you directly off-list. Thanks. On 2/9/17 3:13 PM, Clinton Work wrote: > If anybody is reading the NANOG list from the GTT NOC, can you look at > your route-server with the BGP session flapping every couple of minutes. > > route-server.as3257.net>show ip bgp sum > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > State/PfxRcd > 213.200.64.93 4 3257 68799843 331607 0 0 0 00:00:50 > Active > > > -- > Clinton Work From bzs at theworld.com Thu Feb 9 23:22:20 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 9 Feb 2017 18:22:20 -0500 Subject: IoT security In-Reply-To: <20170209170440.GA25494@gsp.org> References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <20170209170440.GA25494@gsp.org> Message-ID: <22684.63916.982565.116461@gargle.gargle.HOWL> On February 9, 2017 at 12:04 rsk at gsp.org (Rich Kulawiec) wrote: > On Wed, Feb 08, 2017 at 08:30:15AM -0800, Damian Menscher wrote: > > The devices are trivially compromised (just log in with the default root > > password). So here's a modest proposal: log in as root and brick the > > device. > > No. It's never a good idea to respond to abuse with abuse. Not only > is it unethical and probably illegal (IANAL, this is not legal advice) > but it won't take more than a day for someone to figure out that this > is happening and use some variety of misdirection to cause third parties > to target devices that aren't actually part of the problem. Ok but what if you broke in and fixed their security w/o breaking the user experience? Would a vendor, presented with a good demo, sign off on that? If so isn't it just a mandatory patch? -- -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 sotnickd-nanog at ddv.com Fri Feb 10 00:59:25 2017 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 9 Feb 2017 16:59:25 -0800 Subject: Updating Geolocation of /24 within corporate /16 Message-ID: Hi NANOG, You have given good advice on updating IP Geolocation data in the past, including visiting 'www.google.com' from a mobile device and selecting "use exact location [from GPS]". This worked out well for us a few years ago for a single IP which we were NATting out of in a new geographic location. Now we are in a position where we have been assigned site-local /24 (out of the corporation's larger /20 space) networks for a couple of locations and I'm wondering how I go about updating IP Geolocation data to note that two /24 networks are no longer at the Corporate HQ location. I understand that when users first start using these site-specific /24 networks, they will be lumped in with the larger /20 space as far as their geolocation goes, but besides the Google/GPS method, is there a cleaner/better way to do this? Do Geolocation services use SWIP data? Should I have the /24s have separate SWIP data noting the geo location? I'd love a place to be able to say: "This /24 is at this geoloc; this /24 is at this geoloc; and the corporate /20 remains where it always has been." Many thanks for your insights in this matter, -Dave From kmedcalf at dessus.com Fri Feb 10 01:01:59 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 09 Feb 2017 18:01:59 -0700 Subject: IoT security In-Reply-To: Message-ID: <6046016be900ba4ca555adbf92218aeb@mail.dessus.com> On Tuesday, 7 February, 2017 06:59, Ray Soucy said: > I think the fundamental problem here is that these devices aren't good > network citizens in the first place. The odds of getting them to add > functionality to support a new protocol are even likely than getting them > to not have open services externally IMHO. > > Couldn't a lot of this be caught by proactive vulnerability scanning and > working with customers to have an SPI firewall in place, or am I missing > something? > > Historically residential ISP CPE options have been terrible. If you could > deliver something closer to user expectations you would likely see much > more adoption and less desire to rip and replace. Ideally a cloud-managed > device so that the config wouldn't need to be rebuilt in the event of a > hardware swap. I do not permit "cloud managed" devices on my network unless the "cloud" also belongs to me and is located on my network (in other words, a good old fashioned server on my network run by me). No ISP is permitted to put "cloud" or even remotely configured (by anyone who is not me) devices on my network. Such devices go on THEIR network not MY network. If they malfunction or get hacked, the problem is THEIRS not MINE. Such a policy ensures that I am entirely and exclusively responsible for the good behaviour of the equipment on MY network. If I were to permit devices managed by NOT-ME on MY network, then I would not be responsible. Therefore such filth should stay on NOT-MY network. So the CPE equipment owned, managed and configured by the ISP is on the ISP network, not my network. The demarc is the ethernet connection between the ISP network and MY network. The ISP cannot configure nor touch anything on MY network, nor I on THEIRS. As for "cloud" crap, anything that even mentions the work "cloud" on the box or glossy brochure gets an immediate 10,000,000 point penalty applied to ensure that it is forever off the consideration list. If someone is opposed to this policy and cannot live with it, either a network carrier or ISP, product vendor or whatever, I really do not give a rats butt. I will simply go do business with someone who has more sense. From sotnickd-nanog at ddv.com Fri Feb 10 03:19:11 2017 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Thu, 9 Feb 2017 19:19:11 -0800 Subject: Updating Geolocation of /24 within corporate /16 In-Reply-To: References: Message-ID: Hi Tyler, I have not yet tried this, but am doing so now, thanks! -Dave On Thu, Feb 9, 2017 at 6:27 PM, Tyler Conrad wrote: > Have you tried submitting a correction to some geolocation services > directly yet? Maxmind is pretty heavily used. > > https://support.maxmind.com/correction-faq/submit-a- > correction/how-do-i-submit-a-correction-to-geoip-data/ > > > On Thursday, February 9, 2017, David Sotnick > wrote: > >> Hi NANOG, >> >> You have given good advice on updating IP Geolocation data in the past, >> including visiting 'www.google.com' from a mobile device and selecting >> "use >> exact location [from GPS]". This worked out well for us a few years ago >> for >> a single IP which we were NATting out of in a new geographic location. >> >> Now we are in a position where we have been assigned site-local /24 (out >> of >> the corporation's larger /20 space) networks for a couple of locations and >> I'm wondering how I go about updating IP Geolocation data to note that two >> /24 networks are no longer at the Corporate HQ location. >> >> I understand that when users first start using these site-specific /24 >> networks, they will be lumped in with the larger /20 space as far as their >> geolocation goes, but besides the Google/GPS method, is there a >> cleaner/better way to do this? Do Geolocation services use SWIP data? >> Should I have the /24s have separate SWIP data noting the geo location? >> I'd >> love a place to be able to say: "This /24 is at this geoloc; this /24 is >> at >> this geoloc; and the corporate /20 remains where it always has been." >> >> Many thanks for your insights in this matter, >> >> -Dave >> > From math at sizone.org Fri Feb 10 04:18:24 2017 From: math at sizone.org (Ken Chase) Date: Thu, 9 Feb 2017 23:18:24 -0500 Subject: backbones filtering unsanctioned sites Message-ID: <20170210041824.GB16526@sizone.org> https://torrentfreak.com/internet-backbone-provider-cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ /kc -- Ken Chase - math at sizone.org Guelph Canada From robert at mckay.com Fri Feb 10 11:47:21 2017 From: robert at mckay.com (Robert McKay) Date: Fri, 10 Feb 2017 11:47:21 +0000 Subject: backbones filtering unsanctioned sites In-Reply-To: <20170210041824.GB16526@sizone.org> References: <20170210041824.GB16526@sizone.org> Message-ID: <953b15ec007b172aef9b7b91b251ce1c@webmail.mckay.com> On 2017-02-10 04:18, Ken Chase wrote: > https://torrentfreak.com/internet-backbone-provider-cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > /kc Strange indeed.. but they forgot to ban it on IPv6 - maybe they're trying to push IPv6 adoption! Banning any Cloudflare hosted sites by IP is particularly ineffective because it doesn't really matter which cloudflare IP you connect to as long as you present the right SNI name and HTTP Host header.. basically just add www.thepiratebay.org to your hosts file and point it at any other cloudflare IP.. like they banned 104.31.18.30 so change it to 104.31.18.31 and ban evaded. Rob From jeje at jeje.org Fri Feb 10 00:27:31 2017 From: jeje at jeje.org (=?UTF-8?B?SsOpcsO0bWUgRmxldXJ5?=) Date: Thu, 9 Feb 2017 19:27:31 -0500 Subject: Telia network quality In-Reply-To: References: Message-ID: Cloudflare issues with Telia are a thing of the past. They remain one of the top Tier1 provider in term of reach and quality. On Thu, Feb 2, 2017 at 11:12 AM, Don wrote: > I heard Telia's quality had been on the decline lately as they were > signing on lots of high-capacity new customers, and Cloudflare had some > complaint about them a few months prior too. Does anybody have any insight > into whether this is still the case? I was trying to evaluate whether Telia > would be a good carrier to switch over to as a primary provider, as their > pricing does look pretty attractive. > > B/R > Don From marco at marcoslater.com Thu Feb 9 18:48:37 2017 From: marco at marcoslater.com (Marco Slater) Date: Thu, 9 Feb 2017 18:48:37 +0000 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> Message-ID: > As an ISP, scan your customers netrange, and notify customers with known > vulnerable devices. With regards to the current Mirai threat, theres only a > handful of devices that are the most critical importance. IE, biggest > fraction of the infected host pie. Virgin Media in the UK do this for Mirai-infected or susceptible devices already. What they send out: https://twitter.com/2sec4u/status/825337376692121601 Quite interesting approach. If more consumers were aware of this, they may do something about it.. although.. people are lazy. :( From timothy at creswick.eu Thu Feb 9 23:45:00 2017 From: timothy at creswick.eu (Timothy Creswick) Date: Thu, 9 Feb 2017 23:45:00 +0000 Subject: Same day PDU and power cable suppliers for NYC / Newark Message-ID: Hi All, We're after a couple of L5-30 to n * IEC C13 PDUs in the NYC / Newark area on short notice (i.e. same day). Can anyone recommend a local supplier who can help with this? Many thanks in advance, Tim - Timothy Creswick From tyler at tgconrad.com Fri Feb 10 02:27:08 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Thu, 9 Feb 2017 18:27:08 -0800 Subject: Updating Geolocation of /24 within corporate /16 In-Reply-To: References: Message-ID: Have you tried submitting a correction to some geolocation services directly yet? Maxmind is pretty heavily used. https://support.maxmind.com/correction-faq/submit-a-correction/how-do-i-submit-a-correction-to-geoip-data/ On Thursday, February 9, 2017, David Sotnick wrote: > Hi NANOG, > > You have given good advice on updating IP Geolocation data in the past, > including visiting 'www.google.com' from a mobile device and selecting > "use > exact location [from GPS]". This worked out well for us a few years ago for > a single IP which we were NATting out of in a new geographic location. > > Now we are in a position where we have been assigned site-local /24 (out of > the corporation's larger /20 space) networks for a couple of locations and > I'm wondering how I go about updating IP Geolocation data to note that two > /24 networks are no longer at the Corporate HQ location. > > I understand that when users first start using these site-specific /24 > networks, they will be lumped in with the larger /20 space as far as their > geolocation goes, but besides the Google/GPS method, is there a > cleaner/better way to do this? Do Geolocation services use SWIP data? > Should I have the /24s have separate SWIP data noting the geo location? I'd > love a place to be able to say: "This /24 is at this geoloc; this /24 is at > this geoloc; and the corporate /20 remains where it always has been." > > Many thanks for your insights in this matter, > > -Dave > From morrowc.lists at gmail.com Fri Feb 10 16:45:11 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Feb 2017 11:45:11 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <953b15ec007b172aef9b7b91b251ce1c@webmail.mckay.com> References: <20170210041824.GB16526@sizone.org> <953b15ec007b172aef9b7b91b251ce1c@webmail.mckay.com> Message-ID: On Fri, Feb 10, 2017 at 6:47 AM, Robert McKay wrote: > On 2017-02-10 04:18, Ken Chase wrote: > >> https://torrentfreak.com/internet-backbone-provider-cogent- >> blocks-pirate-bay-and-other-pirate-sites-170209/ >> >> /kc >> > > Strange indeed.. but they forgot to ban it on IPv6 - maybe they're trying > to push IPv6 adoption! > > ha, you are hilarious. > Banning any Cloudflare hosted sites by IP is particularly ineffective > because it doesn't really matter which cloudflare IP you connect to as long > as you present the right SNI name and HTTP Host header.. basically just add > www.thepiratebay.org to your hosts file and point it at any other > cloudflare IP.. like they banned 104.31.18.30 so change it to 104.31.18.31 > and ban evaded. > > isn't any 'copyright driven' censorship move really just a half-a$$ed move anyway? it's all about knocking out 90% of the users? ALL of these restrictions can be avoided if you can encap around, or fix-your-local-resolver, or ... which 90% of the people just won't do... From a.harrowell at gmail.com Fri Feb 10 17:40:51 2017 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 10 Feb 2017 17:40:51 +0000 Subject: Someone's scraping NANOG for phishing purposes again Message-ID: I'm getting suspicious e-mail pretending to come from leading NANOGers. Not the first time this has happened, but you may want to be warned. Yours, Alex Harrowell From josh at imaginenetworksllc.com Fri Feb 10 17:42:28 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 10 Feb 2017 12:42:28 -0500 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: References: Message-ID: Thank you for the notice. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Feb 10, 2017 12:42 PM, "Alexander Harrowell" wrote: > I'm getting suspicious e-mail pretending to come from leading NANOGers. Not > the first time this has happened, but you may want to be warned. > > Yours, > > Alex Harrowell > From a.harrowell at gmail.com Fri Feb 10 17:44:48 2017 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 10 Feb 2017 17:44:48 +0000 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: References: Message-ID: Interestingly, the phishes are both using NANOG members' names as forged From: fields, they're also being sent to NANOG people specifically - each one comes with half a dozen addresses of which usually one or two are familiar to me as frequent contributors. On Fri, Feb 10, 2017 at 5:42 PM, Josh Luthman wrote: > Thank you for the notice. > > Josh Luthman > Office: 937-552-2340 <(937)%20552-2340> > Direct: 937-552-2343 <(937)%20552-2343> > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Feb 10, 2017 12:42 PM, "Alexander Harrowell" > wrote: > >> I'm getting suspicious e-mail pretending to come from leading NANOGers. >> Not >> the first time this has happened, but you may want to be warned. >> >> Yours, >> >> Alex Harrowell >> > From ops.lists at gmail.com Fri Feb 10 17:46:36 2017 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 10 Feb 2017 09:46:36 -0800 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: References: Message-ID: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> Or a nanog member might be infected and the malware is scraping his mailbox for bogus froms. Got headers? On 10/02/17, 9:40 AM, "NANOG on behalf of Alexander Harrowell" wrote: I'm getting suspicious e-mail pretending to come from leading NANOGers. Not the first time this has happened, but you may want to be warned. Yours, Alex Harrowell From lathama at gmail.com Fri Feb 10 17:56:02 2017 From: lathama at gmail.com (Andrew Latham) Date: Fri, 10 Feb 2017 11:56:02 -0600 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> References: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> Message-ID: On a great many mailing lists, Suresh is spot on as this looks more like infected user but headers would be good. On Fri, Feb 10, 2017 at 11:46 AM, Suresh Ramasubramanian < ops.lists at gmail.com> wrote: > > Or a nanog member might be infected and the malware is scraping his mailbox for bogus froms. Got headers? > > On 10/02/17, 9:40 AM, "NANOG on behalf of Alexander Harrowell" < nanog-bounces at nanog.org on behalf of a.harrowell at gmail.com> wrote: > > I'm getting suspicious e-mail pretending to come from leading NANOGers. Not > the first time this has happened, but you may want to be warned. > > Yours, > > Alex Harrowell > -- - Andrew "lathama" Latham http://lathama.org - From cscora at apnic.net Fri Feb 10 18:02:50 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Feb 2017 04:02:50 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170210180250.2BC25C44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 11 Feb, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 635010 Prefixes after maximum aggregation (per Origin AS): 247431 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 305846 Total ASes present in the Internet Routing Table: 56204 Prefixes per ASN: 11.30 Origin-only ASes present in the Internet Routing Table: 48647 Origin ASes announcing only one prefix: 21683 Transit ASes present in the Internet Routing Table: 7557 Transit-only ASes present in the Internet Routing Table: 208 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 80 Numnber of instances of unregistered ASNs: 81 Number of 32-bit ASNs allocated by the RIRs: 17256 Number of 32-bit ASNs visible in the Routing Table: 13413 Prefixes from 32-bit ASNs in the Routing Table: 53971 Number of bogon 32-bit ASNs visible in the Routing Table: 50 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 429 Number of addresses announced to Internet: 2832797668 Equivalent to 168 /8s, 217 /16s and 15 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 211930 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 173285 Total APNIC prefixes after maximum aggregation: 49607 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 172688 Unique aggregates announced from the APNIC address blocks: 71398 APNIC Region origin ASes present in the Internet Routing Table: 7845 APNIC Prefixes per ASN: 22.01 APNIC Region origin ASes announcing only one prefix: 2190 APNIC Region transit ASes present in the Internet Routing Table: 1119 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2672 Number of APNIC addresses announced to Internet: 760441732 Equivalent to 45 /8s, 83 /16s and 107 /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-137529 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: 193476 Total ARIN prefixes after maximum aggregation: 92928 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 195792 Unique aggregates announced from the ARIN address blocks: 89820 ARIN Region origin ASes present in the Internet Routing Table: 17789 ARIN Prefixes per ASN: 11.01 ARIN Region origin ASes announcing only one prefix: 6642 ARIN Region transit ASes present in the Internet Routing Table: 1766 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1756 Number of ARIN addresses announced to Internet: 1104034720 Equivalent to 65 /8s, 206 /16s and 59 /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-397212 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: 169226 Total RIPE prefixes after maximum aggregation: 83704 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 164564 Unique aggregates announced from the RIPE address blocks: 99725 RIPE Region origin ASes present in the Internet Routing Table: 23672 RIPE Prefixes per ASN: 6.95 RIPE Region origin ASes announcing only one prefix: 10968 RIPE Region transit ASes present in the Internet Routing Table: 3356 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5534 Number of RIPE addresses announced to Internet: 709553024 Equivalent to 42 /8s, 74 /16s and 235 /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-207259 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: 82544 Total LACNIC prefixes after maximum aggregation: 17448 LACNIC Deaggregation factor: 4.73 Prefixes being announced from the LACNIC address blocks: 83648 Unique aggregates announced from the LACNIC address blocks: 37823 LACNIC Region origin ASes present in the Internet Routing Table: 5645 LACNIC Prefixes per ASN: 14.82 LACNIC Region origin ASes announcing only one prefix: 1557 LACNIC Region transit ASes present in the Internet Routing Table: 1039 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3161 Number of LACNIC addresses announced to Internet: 170804288 Equivalent to 10 /8s, 46 /16s and 68 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16366 Total AfriNIC prefixes after maximum aggregation: 3683 AfriNIC Deaggregation factor: 4.44 Prefixes being announced from the AfriNIC address blocks: 17889 Unique aggregates announced from the AfriNIC address blocks: 6717 AfriNIC Region origin ASes present in the Internet Routing Table: 1017 AfriNIC Prefixes per ASN: 17.59 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 198 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 290 Number of AfriNIC addresses announced to Internet: 87502592 Equivalent to 5 /8s, 55 /16s and 47 /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 5531 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3724 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2718 1501 542 BSNL-NIB National Internet Backbone, IN 9808 2283 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2058 421 220 TATACOMM-AS TATA Communications formerl 45899 1861 1299 100 VNPT-AS-VN VNPT Corp, VN 4808 1636 1784 445 CHINA169-BJ China Unicom Beijing Provin 24560 1564 571 250 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd 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 22773 3629 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3260 1333 83 SHAW - Shaw Communications Inc., CA 18566 2191 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2063 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1970 2034 406 CHARTER-NET-HKY-NC - Charter Communicat 209 1725 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1688 317 459 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1680 848 227 ITCDELTA - Earthlink, Inc., US 16509 1642 3064 537 AMAZON-02 - Amazon.com, Inc., US 701 1594 10597 657 UUNET - MCI Communications Services, In 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 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3013 1129 2135 AKAMAI-ASN1 , US 9121 2138 1691 18 TTNET , TR 34984 1994 328 380 TELLCOM-AS , TR 13188 1615 99 62 TRIOLAN , UA 8551 1607 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1468 1033 50 UNI2-AS , ES 6849 1318 355 22 UKRTELNET , UA 9198 1300 352 24 KAZTELECOM-AS , KZ 8402 1151 544 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3541 545 158 Telmex Colombia S.A., CO 26615 3027 2330 44 Tim Celular S.A., BR 8151 2488 3390 549 Uninet S.A. de C.V., MX 11830 1804 368 66 Instituto Costarricense de Electricidad 6503 1570 437 54 Axtel, S.A.B. de C.V., MX 7303 1430 878 255 Telecom Argentina S.A., AR 6147 1353 377 27 Telefonica del Peru S.A.A., PE 28573 1059 2273 182 CLARO S.A., BR 3816 1001 479 185 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 984 280 35 Techtel LMDS Comunicaciones Interactiva 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 1298 398 41 LINKdotNET-AS, EG 36903 719 361 123 MT-MPLS, MA 37611 690 67 6 Afrihost, ZA 36992 587 1373 25 ETISALAT-MISR, EG 24835 490 658 16 RAYA-AS, EG 8452 461 1474 16 TE-AS TE-AS, EG 37492 392 316 74 ORANGE-TN, TN 29571 367 36 10 CITelecom-AS, CI 15399 327 35 6 WANANCHI-KE, KE 2018 273 327 74 TENET-1, ZA 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 4538 5531 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3724 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3629 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3541 545 158 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3260 1333 83 SHAW - Shaw Communications Inc., CA 26615 3027 2330 44 Tim Celular S.A., BR 20940 3013 1129 2135 AKAMAI-ASN1 , US 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2729 11133 744 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3629 3478 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3724 3468 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3541 3383 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3260 3177 SHAW - Shaw Communications Inc., CA 26615 3027 2983 Tim Celular S.A., BR 17974 2984 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9808 2283 2250 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2718 2176 BSNL-NIB National Internet Backbone, IN 9121 2138 2120 TTNET , TR Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 41.73.21.0/24 37004 Suburban-Broadband-AS, NG 41.73.22.0/24 37004 Suburban-Broadband-AS, NG 41.73.23.0/24 37004 Suburban-Broadband-AS, NG 41.76.232.0/21 203496 AB-TELECOM , RU 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:16 /9:13 /10:36 /11:103 /12:276 /13:535 /14:1047 /15:1801 /16:13175 /17:7751 /18:12998 /19:25124 /20:38119 /21:40837 /22:74093 /23:62687 /24:355030 /25:561 /26:415 /27:294 /28:35 /29:19 /30:18 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3056 3260 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2825 3629 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2543 3027 Tim Celular S.A., BR 18566 2084 2191 MEGAPATH5-US - MegaPath Corporation, US 9121 1503 2138 TTNET , TR 30036 1499 1688 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1452 3541 Telmex Colombia S.A., CO 6389 1372 2063 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1359 1615 TRIOLAN , UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1596 2:832 4:25 5:2443 6:34 8:1047 12:1810 13:74 14:1777 15:22 16:2 17:100 18:128 19:1 20:53 23:2012 24:1847 25:2 27:2385 31:1858 32:89 33:2 34:1 35:3 36:357 37:2526 38:1308 39:43 40:101 41:2846 42:452 43:1929 44:59 45:2382 46:2548 47:110 49:1218 50:945 51:18 52:709 54:357 55:7 56:4 57:41 58:1616 59:989 60:386 61:1898 62:1505 63:1928 64:4558 65:2185 66:4451 67:2222 68:1168 69:3324 70:1302 71:570 72:2050 74:2609 75:405 76:411 77:1436 78:1583 79:1280 80:1342 81:1401 82:982 83:722 84:869 85:1691 86:482 87:1132 88:781 89:2054 90:201 91:6125 92:985 93:2378 94:2356 95:2793 96:570 97:357 98:936 99:91 100:152 101:1261 103:13569 104:2706 105:147 106:482 107:1530 108:794 109:2575 110:1287 111:1662 112:1149 113:1234 114:1028 115:1733 116:1745 117:1649 118:2056 119:1564 120:952 121:1099 122:2341 123:2016 124:1527 125:1813 128:745 129:616 130:412 131:1391 132:520 133:193 134:529 135:209 136:505 137:430 138:1841 139:499 140:367 141:518 142:731 143:908 144:764 145:167 146:1021 147:658 148:1361 149:569 150:686 151:938 152:722 153:316 154:750 155:963 156:548 157:589 158:443 159:1393 160:566 161:734 162:2473 163:528 164:782 165:1153 166:370 167:1260 168:2519 169:738 170:2777 171:275 172:934 173:1827 174:805 175:720 176:1774 177:4234 178:2477 179:1644 180:2096 181:2032 182:2210 183:1041 184:830 185:8713 186:3208 187:2684 188:2367 189:1786 190:8138 191:1945 192:9288 193:5777 194:4624 195:3845 196:1957 197:1231 198:5572 199:5835 200:7387 201:4132 202:10117 203:9879 204:4454 205:2772 206:2985 207:3150 208:3999 209:3882 210:3914 211:2096 212:2789 213:2456 214:861 215:64 216:5814 217:1988 218:834 219:607 220:1685 221:901 222:723 223:1172 End of report From rsk at gsp.org Fri Feb 10 18:22:31 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 10 Feb 2017 13:22:31 -0500 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: References: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> Message-ID: <20170210182231.GA9188@gsp.org> On Fri, Feb 10, 2017 at 11:56:02AM -0600, Andrew Latham wrote: > On a great many mailing lists, Suresh is spot on as this looks more like > infected user but headers would be good. Here are a couple recent specimens that appear to fit this pattern: -------------------------------------------------------- Received: from route-level2.fsdata.se (route-level2.fsdata.se [89.221.252.217]) by taos.firemountain.net (8.15.1/8.14.9) with ESMTPS id v190EnHs001330 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 8 Feb 2017 19:15:01 -0500 (EST) From: To: Jon Lewis , jamie rishaw , Michael Thomas , Rich Kulawiec Subject: =?utf-8?B?d2hhdCBhIG5pY2Ugc3VycHJpc2U=?= Date: Wed, 8 Feb 2017 19:14:20 -0500 Message-ID: <1355759249.20170209031420 at onlinemarket.se> -------------------------------------------------------- -------------------------------------------------------- Received: from mcegress-14-lw-3.correio.biz (mcegress-14-lw-3.correio.biz [191.252.14.3]) by taos.firemountain.net (8.15.1/8.14.9) with ESMTP id v0B5dsb7001374 for ; Wed, 11 Jan 2017 00:40:06 -0500 (EST) From: "Mikael Abrahamsson" To: "John Curran" , "Paul Graydon" , "Rich Kulawiec" , "Seth Mattinen" Subject: =?utf-8?B?ZmFudGFzdGljIHBsYWNl?= Date: Wed, 11 Jan 2017 01:38:43 -0400 Message-ID: <1961406061.20170111083843 at jdlabs.fr> -------------------------------------------------------- ---rsk From bruns at 2mbit.com Fri Feb 10 18:28:53 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 10 Feb 2017 11:28:53 -0700 Subject: backbones filtering unsanctioned sites In-Reply-To: <20170210041824.GB16526@sizone.org> References: <20170210041824.GB16526@sizone.org> Message-ID: <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> On 2/9/17 9:18 PM, Ken Chase wrote: > https://torrentfreak.com/internet-backbone-provider-cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > /kc > Funny. Someone else got back: "Abuse cannot not provide you a list of websites that may be encountering reduced visibility via Cogent" I almost wish I had a Cogent circuit just to bring this up with an account rep. Almost. I'd very much so view this as a contractual violation on Cogent's part. Cogent keeps contacting me every year wanting to sell me service. This will be a good one to bring up when they call me next time. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From a.harrowell at gmail.com Fri Feb 10 18:05:13 2017 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 10 Feb 2017 18:05:13 +0000 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> References: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> Message-ID: Yes. The names are used in the From: but not the e-mail addresses. The payload is inside SecureServer.net's 43.255.154.0/24 - 43.255.154.125 and 43.255.154.66. Headers follow. Note: I think Anne P. Mitchell is a LinkedIn contact of mine. Message 1) Delivered-To: a.harrowell at gmail.com Received: by 10.80.169.228 with SMTP id n91csp49041edc; Wed, 8 Feb 2017 16:09:01 -0800 (PST) X-Received: by 10.223.131.34 with SMTP id 31mr179054wrd.119.1486598941445; Wed, 08 Feb 2017 16:09:01 -0800 (PST) Return-Path: Received: from mx21lb.world4you.com (mx21lb.world4you.com. [81.19.149.131]) by mx.google.com with ESMTPS id p26si10875705wrp.311.2017.02.08.16.09.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 16:09:01 -0800 (PST) Received-SPF: pass (google.com: domain of wolfgang at cziczatka.com designates 81.19.149.131 as permitted sender) client-ip=81.19.149.131; Authentication-Results: mx.google.com; spf=pass (google.com: domain of wolfgang at cziczatka.com designates 81.19.149.131 as permitted sender) smtp.mailfrom=wolfgang at cziczatka.com Received: from [117.243.182.154] (helo=dydt-PC) by mx21lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cbcIF-0005OX-87; Thu, 09 Feb 2017 01:09:00 +0100 From: Brandon Galbraith To: Alexander Harrowell , "Nathanael C. Cariaga" , aduitsis , David Ulevitch Subject: take a look at that Date: Thu, 9 Feb 2017 00:08:49 +0000 Message-ID: <1514273443.20170209030849 at cziczatka.com> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_017DBA64.1747A7CE" Content-Language: en-gb MIME-Version: 1.0 X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 117.243.182.154 X-SA-Exim-Mail-From: wolfgang at cziczatka.com X-SA-Exim-Scanned: No (on mx21lb.world4you.com); SAEximRunCond expanded to false ------=_NextPart_000_0016_017DBA64.1747A7CE Message 2) Delivered-To: a.harrowell at gmail.com Received: by 10.80.169.228 with SMTP id n91csp50480edc; Wed, 8 Feb 2017 16:14:21 -0800 (PST) X-Received: by 10.28.135.82 with SMTP id j79mr18959559wmd.19.1486599261495; Wed, 08 Feb 2017 16:14:21 -0800 (PST) Return-Path: Received: from smtp.nfrance.com (smtp-4.nfrance.com. [80.247.229.46]) by mx.google.com with ESMTPS id f124si4142408wmd.153.2017.02.08.16.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 16:14:21 -0800 (PST) Received-SPF: neutral (google.com: 80.247.229.46 is neither permitted nor denied by best guess record for domain of info at ocreschauvin.fr) client-ip=80.247.229.46; Authentication-Results: mx.google.com; spf=neutral (google.com: 80.247.229.46 is neither permitted nor denied by best guess record for domain of info at ocreschauvin.fr) smtp.mailfrom=info at ocreschauvin.fr Received: from tqzb-PC (unknown [197.45.161.242]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.nfrance.com (Postfix) with ESMTPSA id 28E1612D7A7; Thu, 9 Feb 2017 01:14:18 +0100 (CET) From: Owen DeLong To: Brian Mengel , Andrew Latham , Alexander Harrowell , "Anne P. Mitchell Esq." Subject: do you have any ideas? Date: Thu, 9 Feb 2017 06:14:13 +0600 Message-ID: <1846552645.20170209031413 at ocreschauvin.fr> Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_010D479E.32101F4A" Content-Language: en-us MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 80.247.229.46 ------=_NextPart_000_005C_010D479E.32101F4A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBmcmllbmQhIA0KDQpJJ3ZlIGJlZW4gd3JpdGluZyBhbiAgYXJ0aWNsZSBhbmQgSSd2ZSBj b21lIGFjcm9zcyB0aGF0ICBzdHJhbmdlICBzdHVmZiwgIGRvIHlvdSBoYXZlICBhbnkgIGlkZWFz IHdoYXQgY291bGQgaXQgYmU/IEp1c3QgdGFrZSBhICBsb29rIGh0dHA6Ly9tYXgudHJpcHN0aXht ZW1vcmllcy5jb20vZjRmNQ0KDQpCZXN0IHdpc2hlcywgT3dlbiBEZUxvbmcNCg0K ------=_NextPart_000_005C_010D479E.32101F4A ------=_NextPart_000_005C_010D479E.32101F4A-- On Fri, Feb 10, 2017 at 5:46 PM, Suresh Ramasubramanian wrote: > Or a nanog member might be infected and the malware is scraping his > mailbox for bogus froms. Got headers? > > On 10/02/17, 9:40 AM, "NANOG on behalf of Alexander Harrowell" < > nanog-bounces at nanog.org on behalf of a.harrowell at gmail.com> wrote: > > I'm getting suspicious e-mail pretending to come from leading > NANOGers. Not > the first time this has happened, but you may want to be warned. > > Yours, > > Alex Harrowell > > > > From nanog at ics-il.net Fri Feb 10 18:39:48 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 10 Feb 2017 12:39:48 -0600 (CST) Subject: backbones filtering unsanctioned sites In-Reply-To: <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> Message-ID: <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Have we determined that this is intentional vs. some screw up? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: nanog at nanog.org Sent: Friday, February 10, 2017 12:28:53 PM Subject: Re: backbones filtering unsanctioned sites On 2/9/17 9:18 PM, Ken Chase wrote: > https://torrentfreak.com/internet-backbone-provider-cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > /kc > Funny. Someone else got back: "Abuse cannot not provide you a list of websites that may be encountering reduced visibility via Cogent" I almost wish I had a Cogent circuit just to bring this up with an account rep. Almost. I'd very much so view this as a contractual violation on Cogent's part. Cogent keeps contacting me every year wanting to sell me service. This will be a good one to bring up when they call me next time. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jason at rokeach.net Fri Feb 10 18:46:57 2017 From: jason at rokeach.net (Jason Rokeach) Date: Fri, 10 Feb 2017 13:46:57 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: This looks pretty intentional to me. From http://www.cogentco.com/en/network/looking-glass: BGP routing table entry for 104.31.18.30/32, version 611495773 Paths: (1 available, best #1, table Default-IP-Routing-Table) Local 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) Origin IGP, metric 0, localpref 150, valid, internal, best Community: 174:990 174:20912 174:21001 Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 BGP routing table entry for 104.31.19.30/32, version 611495772 Paths: (1 available, best #1, table Default-IP-Routing-Table) Local 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) Origin IGP, metric 0, localpref 150, valid, internal, best Community: 174:990 174:20912 174:21001 Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop router. On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: > Have we determined that this is intentional vs. some screw up? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Brielle Bruns" > To: nanog at nanog.org > Sent: Friday, February 10, 2017 12:28:53 PM > Subject: Re: backbones filtering unsanctioned sites > > On 2/9/17 9:18 PM, Ken Chase wrote: > > https://torrentfreak.com/internet-backbone-provider- > cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > > > /kc > > > > Funny. Someone else got back: > > "Abuse cannot not provide you a list of websites that may be > encountering reduced visibility via Cogent" > > I almost wish I had a Cogent circuit just to bring this up with an > account rep. Almost. > > I'd very much so view this as a contractual violation on Cogent's part. > > Cogent keeps contacting me every year wanting to sell me service. This > will be a good one to bring up when they call me next time. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > From nanog at ics-il.net Fri Feb 10 18:49:29 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 10 Feb 2017 12:49:29 -0600 (CST) Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: <1027456190.3729.1486752565281.JavaMail.mhammett@ThunderFuck> Never attribute to malice that which is adequately explained by stupidity? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jason Rokeach" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Friday, February 10, 2017 12:46:57 PM Subject: Re: backbones filtering unsanctioned sites This looks pretty intentional to me. From http://www.cogentco.com/en/network/looking-glass : BGP routing table entry for 104.31.18.30/32 , version 611495773 Paths: (1 available, best #1, table Default-IP-Routing-Table) Local 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) Origin IGP, metric 0, localpref 150, valid, internal, best Community: 174:990 174:20912 174:21001 Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 BGP routing table entry for 104.31.19.30/32 , version 611495772 Paths: (1 available, best #1, table Default-IP-Routing-Table) Local 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) Origin IGP, metric 0, localpref 150, valid, internal, best Community: 174:990 174:20912 174:21001 Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop router. On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett < nanog at ics-il.net > wrote: Have we determined that this is intentional vs. some screw up? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" < bruns at 2mbit.com > To: nanog at nanog.org Sent: Friday, February 10, 2017 12:28:53 PM Subject: Re: backbones filtering unsanctioned sites On 2/9/17 9:18 PM, Ken Chase wrote: > https://torrentfreak.com/internet-backbone-provider-cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > /kc > Funny. Someone else got back: "Abuse cannot not provide you a list of websites that may be encountering reduced visibility via Cogent" I almost wish I had a Cogent circuit just to bring this up with an account rep. Almost. I'd very much so view this as a contractual violation on Cogent's part. Cogent keeps contacting me every year wanting to sell me service. This will be a good one to bring up when they call me next time. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From zwicky at yahoo-inc.com Fri Feb 10 18:59:29 2017 From: zwicky at yahoo-inc.com (Elizabeth Zwicky) Date: Fri, 10 Feb 2017 18:59:29 +0000 (UTC) Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: References: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> Message-ID: <312993701.2091721.1486753169711@mail.yahoo.com> This is the sort of mail, based on stolen address books from numerous sites and sometimes on mined Facebook data, that the same spam group has been sending since mid 2013. At some point in 2016 they started permuting the data; previously, if A's addressbook had been stolen, the mail always came "From:" A, but now if A's addressbook had B and C in it, the mail might be "From:" B to C.? It is of course possible that they have new sources of data, although I haven't seen any particular evidence of that recently. (I have seen evidence that they have moderately increased competence in getting their spam delivered and read, which has been their main problem in recent years.) Addressbook data stays useful until all of your contacts get new email addresses. Elizabeth ZwickyOn Friday, February 10, 2017, 10:34:58 AM PST, Alexander Harrowell wrote:Yes. The names are used in the From: but not the e-mail addresses. The payload is inside SecureServer.net's 43.255.154.0/24 - 43.255.154.125 and 43.255.154.66. Headers follow. Note: I think Anne P. Mitchell is a LinkedIn contact of mine. Message 1) Delivered-To: a.harrowell at gmail.com Received: by 10.80.169.228 with SMTP id n91csp49041edc; ? ? ? ? Wed, 8 Feb 2017 16:09:01 -0800 (PST) X-Received: by 10.223.131.34 with SMTP id 31mr179054wrd.119.1486598941445; ? ? ? ? Wed, 08 Feb 2017 16:09:01 -0800 (PST) Return-Path: Received: from mx21lb.world4you.com (mx21lb.world4you.com. [81.19.149.131]) ? ? ? ? by mx.google.com with ESMTPS id p26si10875705wrp.311.2017.02.08.16.09.01 ? ? ? ? (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); ? ? ? ? Wed, 08 Feb 2017 16:09:01 -0800 (PST) Received-SPF: pass (google.com: domain of wolfgang at cziczatka.com designates 81.19.149.131 as permitted sender) client-ip=81.19.149.131; Authentication-Results: mx.google.com; ? ? ? spf=pass (google.com: domain of wolfgang at cziczatka.com designates 81.19.149.131 as permitted sender) smtp.mailfrom=wolfgang at cziczatka.com Received: from [117.243.182.154] (helo=dydt-PC) by mx21lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cbcIF-0005OX-87; Thu, 09 Feb 2017 01:09:00 +0100 From: Brandon Galbraith To: Alexander Harrowell , "Nathanael C. Cariaga" , aduitsis , David Ulevitch Subject: take a look at that Date: Thu, 9 Feb 2017 00:08:49 +0000 Message-ID: <1514273443.20170209030849 at cziczatka.com> Content-Type: multipart/alternative; ? ? ? ? boundary="----=_NextPart_000_0016_017DBA64.1747A7CE" Content-Language: en-gb MIME-Version: 1.0 X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 117.243.182.154 X-SA-Exim-Mail-From: wolfgang at cziczatka.com X-SA-Exim-Scanned: No (on mx21lb.world4you.com); SAEximRunCond expanded to false ------=_NextPart_000_0016_017DBA64.1747A7CE Message 2) Delivered-To: a.harrowell at gmail.com Received: by 10.80.169.228 with SMTP id n91csp50480edc; ? ? ? ? Wed, 8 Feb 2017 16:14:21 -0800 (PST) X-Received: by 10.28.135.82 with SMTP id j79mr18959559wmd.19.1486599261495; ? ? ? ? Wed, 08 Feb 2017 16:14:21 -0800 (PST) Return-Path: Received: from smtp.nfrance.com (smtp-4.nfrance.com. [80.247.229.46]) ? ? ? ? by mx.google.com with ESMTPS id f124si4142408wmd.153.2017.02.08.16.14.21 ? ? ? ? (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); ? ? ? ? Wed, 08 Feb 2017 16:14:21 -0800 (PST) Received-SPF: neutral (google.com: 80.247.229.46 is neither permitted nor denied by best guess record for domain of info at ocreschauvin.fr) client-ip=80.247.229.46; Authentication-Results: mx.google.com; ? ? ? spf=neutral (google.com: 80.247.229.46 is neither permitted nor denied by best guess record for domain of info at ocreschauvin.fr) smtp.mailfrom=info at ocreschauvin.fr Received: from tqzb-PC (unknown [197.45.161.242]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.nfrance.com (Postfix) with ESMTPSA id 28E1612D7A7; Thu, ? 9 Feb 2017 01:14:18 +0100 (CET) From: Owen DeLong To: Brian Mengel , Andrew Latham , Alexander Harrowell , "Anne P. Mitchell Esq." Subject: do you have any ideas? Date: Thu, 9 Feb 2017 06:14:13 +0600 Message-ID: <1846552645.20170209031413 at ocreschauvin.fr> Content-Type: multipart/alternative; ? ? ? ? boundary="----=_NextPart_000_005C_010D479E.32101F4A" Content-Language: en-us MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 80.247.229.46 ------=_NextPart_000_005C_010D479E.32101F4A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBmcmllbmQhIA0KDQpJJ3ZlIGJlZW4gd3JpdGluZyBhbiAgYXJ0aWNsZSBhbmQgSSd2ZSBj b21lIGFjcm9zcyB0aGF0ICBzdHJhbmdlICBzdHVmZiwgIGRvIHlvdSBoYXZlICBhbnkgIGlkZWFz IHdoYXQgY291bGQgaXQgYmU/IEp1c3QgdGFrZSBhICBsb29rIGh0dHA6Ly9tYXgudHJpcHN0aXht ZW1vcmllcy5jb20vZjRmNQ0KDQpCZXN0IHdpc2hlcywgT3dlbiBEZUxvbmcNCg0K ------=_NextPart_000_005C_010D479E.32101F4A ------=_NextPart_000_005C_010D479E.32101F4A-- On Fri, Feb 10, 2017 at 5:46 PM, Suresh Ramasubramanian wrote: > Or a nanog member might be infected and the malware is scraping his > mailbox for bogus froms.? Got headers? > > On 10/02/17, 9:40 AM, "NANOG on behalf of Alexander Harrowell" < > nanog-bounces at nanog.org on behalf of a.harrowell at gmail.com> wrote: > >? ? I'm getting suspicious e-mail pretending to come from leading > NANOGers. Not >? ? the first time this has happened, but you may want to be warned. > >? ? Yours, > >? ? Alex Harrowell > > > > From math at sizone.org Fri Feb 10 19:08:51 2017 From: math at sizone.org (Ken Chase) Date: Fri, 10 Feb 2017 14:08:51 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> Message-ID: <20170210190851.GN16526@sizone.org> >"Abuse cannot not provide you a list of websites that may be encountering >reduced visibility via Cogent" They could, if they kept a list of forward lookups they had done to get IPs that ended up in their blacklists. But just having the IPs it's impossible to get the whole list of possible hostnames that point at it (reverse records are singular, and often missing). Nonetheless, it'd be nice to know how a single IP got onto the list - and what Cogent's doing about situations where multiple other hostnames map onto the same ip. I have clietns that are Cogent customers, I'd just like to get informed before I bring the hammer down. /kc -- Ken Chase - math at sizone.org Guelph/Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From valdis.kletnieks at vt.edu Fri Feb 10 19:09:02 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 10 Feb 2017 14:09:02 -0500 Subject: Someone's scraping NANOG for phishing purposes again In-Reply-To: <20170210182231.GA9188@gsp.org> References: <8083B1B9-F65F-45EE-9632-474DA0AC7FB9@gmail.com> <20170210182231.GA9188@gsp.org> Message-ID: <15832.1486753742@turing-police.cc.vt.edu> On Fri, 10 Feb 2017 13:22:31 -0500, Rich Kulawiec said: > On Fri, Feb 10, 2017 at 11:56:02AM -0600, Andrew Latham wrote: > > On a great many mailing lists, Suresh is spot on as this looks more like > > infected user but headers would be good. The one I found in my mailbox yesterday tends to support "multiple users infected with a spamming botnet": Received: from smtp.interfree.it (smtp.interfree.it [80.91.55.53]) by mr3.cc.vt.edu (8.14.7/8.14.7) with ESMTP id v190Ro7i021554 for ; Wed, 8 Feb 2017 19:27:56 -0500 Received: from [59.55.63.88] (helo=jame-PC) by smtp.interfree.it with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1cbcaI-0007Zj-Cz; Thu, 09 Feb 2017 01:27:42 +0100 Message-id: <1427704941.20170209032724 at interfree.it> Subject: look at that, it's amazing! From: "William Herrin" Date: Thu, 9 Feb 2017 06:27:24 +0600 (Wed 19:27 EST) To: "Ronald F. Guilmette" , "Robert Webb" , "Valdis Kletnieks" , "Scott Brim" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From magicsata at gmail.com Fri Feb 10 19:49:26 2017 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 10 Feb 2017 19:49:26 +0000 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: Cogent also have a blackhole route-server that they will provide to you to announce /32's for blackholing. The address for this is 66.28.1.228 which is the originator for the 104.31.19.30/3 2 and 104.31.18.30/32 routes. On 10 February 2017 at 18:46, Jason Rokeach wrote: > This looks pretty intentional to me. From > http://www.cogentco.com/en/network/looking-glass: > > BGP routing table entry for 104.31.18.30/32, version 611495773 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Local > 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) > Origin IGP, metric 0, localpref 150, valid, internal, best > Community: 174:990 174:20912 174:21001 > Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 > > BGP routing table entry for 104.31.19.30/32, version 611495772 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Local > 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) > Origin IGP, metric 0, localpref 150, valid, internal, best > Community: 174:990 174:20912 174:21001 > Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 > > > Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop router. > > On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: > > > Have we determined that this is intentional vs. some screw up? > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Brielle Bruns" > > To: nanog at nanog.org > > Sent: Friday, February 10, 2017 12:28:53 PM > > Subject: Re: backbones filtering unsanctioned sites > > > > On 2/9/17 9:18 PM, Ken Chase wrote: > > > https://torrentfreak.com/internet-backbone-provider- > > cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > > > > > /kc > > > > > > > Funny. Someone else got back: > > > > "Abuse cannot not provide you a list of websites that may be > > encountering reduced visibility via Cogent" > > > > I almost wish I had a Cogent circuit just to bring this up with an > > account rep. Almost. > > > > I'd very much so view this as a contractual violation on Cogent's part. > > > > Cogent keeps contacting me every year wanting to sell me service. This > > will be a good one to bring up when they call me next time. > > > > -- > > Brielle Bruns > > The Summit Open Source Development Group > > http://www.sosdg.org / http://www.ahbl.org > > > > > From morrowc.lists at gmail.com Fri Feb 10 20:03:11 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Feb 2017 15:03:11 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: > Have we determined that this is intentional vs. some screw up? > > if you look at the cogent LG it's pretty clear that the announce reachability for the /20 that includes the tpb /32.. and that the /32 is particularly routed elsewhere, and that the 'elsewhere' is coming form a bgp speaker who's DNS says something along the lines of: "blackhole"... so... err, either someone fat-fingered OR intentionally entered a /32 into the config management system :( > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Brielle Bruns" > To: nanog at nanog.org > Sent: Friday, February 10, 2017 12:28:53 PM > Subject: Re: backbones filtering unsanctioned sites > > On 2/9/17 9:18 PM, Ken Chase wrote: > > https://torrentfreak.com/internet-backbone-provider- > cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > > > > /kc > > > > Funny. Someone else got back: > > "Abuse cannot not provide you a list of websites that may be > encountering reduced visibility via Cogent" > > I almost wish I had a Cogent circuit just to bring this up with an > account rep. Almost. > > I'd very much so view this as a contractual violation on Cogent's part. > > Cogent keeps contacting me every year wanting to sell me service. This > will be a good one to bring up when they call me next time. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > From math at sizone.org Fri Feb 10 20:15:18 2017 From: math at sizone.org (Ken Chase) Date: Fri, 10 Feb 2017 15:15:18 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: <20170210201517.GT16526@sizone.org> And because they're continuing to announce the /20, we run into their blackhole unless we manually filter that /20. This is going to become unworkable in short order once a bigger chunk of the internet starts doing this. /kc On Fri, Feb 10, 2017 at 03:03:11PM -0500, Christopher Morrow said: >On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: > >> Have we determined that this is intentional vs. some screw up? >> >> >if you look at the cogent LG it's pretty clear that the announce >reachability for the /20 that includes the tpb /32.. and that the /32 is >particularly routed elsewhere, and that the 'elsewhere' is coming form a >bgp speaker who's DNS says something along the lines of: "blackhole"... > >so... err, either someone fat-fingered OR intentionally entered a /32 into >the config management system :( > > >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Brielle Bruns" >> To: nanog at nanog.org >> Sent: Friday, February 10, 2017 12:28:53 PM >> Subject: Re: backbones filtering unsanctioned sites >> >> On 2/9/17 9:18 PM, Ken Chase wrote: >> > https://torrentfreak.com/internet-backbone-provider- >> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ >> > >> > /kc >> > >> >> Funny. Someone else got back: >> >> "Abuse cannot not provide you a list of websites that may be >> encountering reduced visibility via Cogent" >> >> I almost wish I had a Cogent circuit just to bring this up with an >> account rep. Almost. >> >> I'd very much so view this as a contractual violation on Cogent's part. >> >> Cogent keeps contacting me every year wanting to sell me service. This >> will be a good one to bring up when they call me next time. >> >> -- >> Brielle Bruns >> The Summit Open Source Development Group >> http://www.sosdg.org / http://www.ahbl.org >> >> -- Ken Chase - math at sizone.org Guelph/Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From morrowc.lists at gmail.com Fri Feb 10 21:07:11 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Feb 2017 16:07:11 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <20170210201517.GT16526@sizone.org> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> <20170210201517.GT16526@sizone.org> Message-ID: On Fri, Feb 10, 2017 at 3:15 PM, Ken Chase wrote: > And because they're continuing to announce the /20, we run into their > blackhole unless we manually filter that /20. This is going to become > unworkable in short order once a bigger chunk of the internet starts doing > this. > > I bet an answer from cogent here is: "you can always TE around 174" that's hard for end-users, but the direct customer can certainly do this... and yea, sucks :( > /kc > > > On Fri, Feb 10, 2017 at 03:03:11PM -0500, Christopher Morrow said: > >On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: > > > >> Have we determined that this is intentional vs. some screw up? > >> > >> > >if you look at the cogent LG it's pretty clear that the announce > >reachability for the /20 that includes the tpb /32.. and that the /32 is > >particularly routed elsewhere, and that the 'elsewhere' is coming form a > >bgp speaker who's DNS says something along the lines of: "blackhole"... > > > >so... err, either someone fat-fingered OR intentionally entered a /32 > into > >the config management system :( > > > > > >> > >> > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest-IX > >> http://www.midwest-ix.com > >> > >> ----- Original Message ----- > >> > >> From: "Brielle Bruns" > >> To: nanog at nanog.org > >> Sent: Friday, February 10, 2017 12:28:53 PM > >> Subject: Re: backbones filtering unsanctioned sites > >> > >> On 2/9/17 9:18 PM, Ken Chase wrote: > >> > https://torrentfreak.com/internet-backbone-provider- > >> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > >> > > >> > /kc > >> > > >> > >> Funny. Someone else got back: > >> > >> "Abuse cannot not provide you a list of websites that may be > >> encountering reduced visibility via Cogent" > >> > >> I almost wish I had a Cogent circuit just to bring this up with an > >> account rep. Almost. > >> > >> I'd very much so view this as a contractual violation on Cogent's > part. > >> > >> Cogent keeps contacting me every year wanting to sell me service. This > >> will be a good one to bring up when they call me next time. > >> > >> -- > >> Brielle Bruns > >> The Summit Open Source Development Group > >> http://www.sosdg.org / http://www.ahbl.org > >> > >> > > -- > Ken Chase - math at sizone.org Guelph/Toronto Canada > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > Front St. W. > From clinton.mielke at gmail.com Fri Feb 10 21:50:11 2017 From: clinton.mielke at gmail.com (clinton mielke) Date: Fri, 10 Feb 2017 13:50:11 -0800 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> Message-ID: It's hilarious they reported on his honeypots :) Kinda surprised I haven't gotten similar letters. I've gotten infected so many times. Amazon certainly noticed my cloud honeypot instances. On Feb 10, 2017 5:48 AM, "Marco Slater" wrote: > > > As an ISP, scan your customers netrange, and notify customers with known > > vulnerable devices. With regards to the current Mirai threat, theres > only a > > handful of devices that are the most critical importance. IE, biggest > > fraction of the infected host pie. > > Virgin Media in the UK do this for Mirai-infected or susceptible devices > already. > > What they send out: https://twitter.com/2sec4u/status/825337376692121601 > > Quite interesting approach. If more consumers were aware of this, they may > do something about it.. although.. people are lazy. :( From clinton.mielke at gmail.com Fri Feb 10 22:00:34 2017 From: clinton.mielke at gmail.com (clinton mielke) Date: Fri, 10 Feb 2017 14:00:34 -0800 Subject: IoT security In-Reply-To: References: <20170207102625.GA29707@gsp.org> <20170207145024.GA1224@gsp.org> <20170208151254.GA14304@gsp.org> <1486605796.15263.13.camel@ns.five-ten-sg.com> Message-ID: That being said, I think if other ISPs took virgins lead then we can start getting this population of devices reduced. The hard part is getting overseas ISPs to help with the problem. Most inbound infectious scanning traffic appears to come from China and Vietnam. I need to create some better aggregate statistics. On Feb 10, 2017 5:48 AM, "Marco Slater" wrote: > > > As an ISP, scan your customers netrange, and notify customers with known > > vulnerable devices. With regards to the current Mirai threat, theres > only a > > handful of devices that are the most critical importance. IE, biggest > > fraction of the infected host pie. > > Virgin Media in the UK do this for Mirai-infected or susceptible devices > already. > > What they send out: https://twitter.com/2sec4u/status/825337376692121601 > > Quite interesting approach. If more consumers were aware of this, they may > do something about it.. although.. people are lazy. :( From morrowc.lists at gmail.com Fri Feb 10 22:03:56 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Feb 2017 17:03:56 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <20170210190851.GN16526@sizone.org> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <20170210190851.GN16526@sizone.org> Message-ID: On Fri, Feb 10, 2017 at 2:08 PM, Ken Chase wrote: > >"Abuse cannot not provide you a list of websites that may be > encountering > >reduced visibility via Cogent" > > They could, if they kept a list of forward lookups they had done to get IPs > i think you mean passive-dns .. which is a thing, and exists. (mumble (passive total|farsight|deteque|....) mumble) > that ended up in their blacklists. But just having the IPs it's impossible > to > get the whole list of possible hostnames that point at it (reverse records > are > singular, and often missing). > > Nonetheless, it'd be nice to know how a single IP got onto the list - and > what > Cogent's doing about situations where multiple other hostnames map onto the > same ip. > > it's totally possible that the list here is really just a court-order addition, right? I can't imagine that there is a cogent employee just evily twiddling pens and adding random ips to blacklists... > I have clietns that are Cogent customers, I'd just like to get informed > before > I bring the hammer down. > > it's worth noting that fairly much every service provider has a provision like cogent's 'force majaure' clause which includes: '...any law, order, regulation...' so it seems safe to assume that there's some court order cogent reacted to :( we should fight that problem upstream. > /kc > -- > Ken Chase - math at sizone.org Guelph/Toronto Canada > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 > Front St. W. > From math at sizone.org Fri Feb 10 22:30:48 2017 From: math at sizone.org (Ken Chase) Date: Fri, 10 Feb 2017 17:30:48 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <20170210190851.GN16526@sizone.org> Message-ID: <20170210223048.GV16526@sizone.org> If its not just cogent then we have an even larger issue -- that theres asymetric application of rulings. So we should just assume that if we can't get to something via cogent then all backbones within the same jurisdiction(*) should or will also have the same sites/ips blocked soon? And that it wasnt a fat finger/typo/someone forgot to remove a block? So we're all just waiting for Level 3 to block TPB too, and we still havent seen a legal ruling/order anywhere? * for various values of 'jurisdiction', in a world where all network operators seeing a technical issue can immediately use their law degrees to guess at which jurisdiction where, when and for how long, installed the ban. (FAICT the ban on TPB @cogent is worldwide.) /kc On Fri, Feb 10, 2017 at 05:03:56PM -0500, Christopher Morrow said: >it's totally possible that the list here is really just a court-order >addition, right? I can't imagine that there is a cogent employee just evily >twiddling pens and adding random ips to blacklists... [...] >so it seems safe to assume that there's some court order cogent reacted to >:( we should fight that problem upstream. -- Ken Chase - math at sizone.org Guelph/Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From morrowc.lists at gmail.com Fri Feb 10 22:40:34 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Feb 2017 17:40:34 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <20170210223048.GV16526@sizone.org> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <20170210190851.GN16526@sizone.org> <20170210223048.GV16526@sizone.org> Message-ID: On Fri, Feb 10, 2017 at 5:30 PM, Ken Chase wrote: > If its not just cogent then we have an even larger issue -- that > theres asymetric application of rulings. So we should just assume > that if we can't get to something via cogent then all backbones > within the same jurisdiction(*) should or will also have the same sites/ips my experience (admittedly dated a bit) is that the people making the request really don't know :( they target who they think will fix their problem... sorta. good luck fellow travelers! From rsk at gsp.org Fri Feb 10 22:55:01 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 10 Feb 2017 17:55:01 -0500 Subject: IoT security In-Reply-To: References: Message-ID: <20170210225501.GB18044@gsp.org> On Tue, Feb 07, 2017 at 08:58:46AM -0500, Ray Soucy wrote: > Ideally a cloud-managed device so that the config wouldn't need > to be rebuilt in the event of a hardware swap. That opens them to a class breach: instead of one getting compromised they *all* get compromised. Better to save the configuration to cheap local media like a USB stick. Yes, it could get lost, but that doesn't break or compromise the device, and it only affects one device. ---rsk From jfmezei_nanog at vaxination.ca Sat Feb 11 02:02:18 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 10 Feb 2017 21:02:18 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <20170210190851.GN16526@sizone.org> <20170210223048.GV16526@sizone.org> Message-ID: <589E70AA.2010804@vaxination.ca> Since 104.31.19.30 is an anycast IP, is it possible that this isn't related to PirateBay but more related to Cogent having a dispute with Cloudfare ? It is counter intuitive for a transit provider to refuse business/traffic, but then again, Cogent has been involved in counter intuituve disputes in the past. I note that this has been going on since last night (at least). It hasn't been resolved, nor has Cogent issued a statement about it (or has it ?) From kraig at enguity.com Sat Feb 11 03:28:11 2017 From: kraig at enguity.com (Kraig Beahn) Date: Sat, 11 Feb 2017 03:28:11 +0000 Subject: Dev. Mfg & ISP Filtering Requirements as set forth in Florida HB337/SB0870, and under similar bills in about 30 other states... Message-ID: There's a bill being widely circulated and passing thru various chambers of at least 30 states right now, commonly being referred to as the HUMAN TRAFFICKING AND CHILD EXPLOITATION PREVENTION ACT, or in Florida's case, we're apparently calling this the "HB 337:Internet Access" bill. Jokes, moral considerations and politics aside - Does anyone have any further information on potentially related bills passing thru states beyond Florida, and has anyone seriously considered the infrastructure changes/impairments necessary to comply, in the unusual event that HB337 or any of the many other bills in various other states passes? Edited HB Brief: An act relating to Internet access; prohibiting covered businesses from manufacturing, distributing, or selling certain devices unless the device contains an active and operating filter that blocks Internet access to specified types of sexually oriented material, prostitution, assignation, lewdness, and human trafficking; providing for injunctive relief for violations; providing requirements for a consumer to have such filter deactivated; requiring a filter deactivation fee and providing for the collection and distribution thereof; prohibiting the distribution or sale of certain devices without filters to minors and adults; providing criminal penalties; providing for jurisdiction to prosecute violations; providing for continuing duties of covered businesses; requiring covered businesses to respond to reports of obscene material that has breached the filter; providing for civil penalties for violations; requiring covered businesses to unblock non obscene material; exempting certain websites from filtering; amending s. 16.56, F.S.; authorizing the Office of Statewide Prosecution to prosecute violations; providing an effective date. The Full Text can be found here: FL/HB 337 On the technical side, you'd probably find yourself chuckling through this reading exercise. However, our regulatory attorney was assured this bill for which is currently under consideration is no laughing matter and is being seriously considered in a multitude of state venues, while others have been dismissive. We've initiated several calls with aide's for Rep. Spanos, the Florida House sponsor, and from what we can tell, the bill is far from the chopping block. Considering the technical impacts not only to internet access device manufacturers, and the implied impacts on service providers like ourselves, i'm surprised it hasn't garnered more attention, nationally. >From a curiosity perspective: The source of this bill appears to be an individual by the name Mark "Chris" Sevier, the same individual whom has virtually sued most of Silicon Valley, and I'll leave it at that in hopes of being able to keep this thread on a technical/legislative tone. NANOG note: Our objective in starting this tread is not to question the intent, moral purpose or potential political agendas surrounding Florida House Bill 337 or bills of similar nature, only it's technical impact on device manufacturers, internet access providers and other alike legislatively covered businesses, assuming passage, as currently written. -- From valdis.kletnieks at vt.edu Sat Feb 11 04:10:51 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 10 Feb 2017 23:10:51 -0500 Subject: Dev. Mfg & ISP Filtering Requirements as set forth in Florida HB337/SB0870, and under similar bills in about 30 other states... In-Reply-To: References: Message-ID: <19286.1486786251@turing-police.cc.vt.edu> On Sat, 11 Feb 2017 03:28:11 +0000, Kraig Beahn said: > NANOG note: Our objective in starting this tread is not to question the > intent, moral purpose or potential political agendas surrounding Florida > House Bill 337 or bills of similar nature, only it's technical impact on > device manufacturers, internet access providers and other alike > legislatively covered businesses, assuming passage, as currently written. At least one version of this bill allows the consumer to opt-out - by appearing at the manufacturer or wholesaler (*not* retailer) *in person* (to prove they are of legal age etc) and request being opted out. There's also requirements that the manufacturers maintain an updated block list, with penalties for failure to do so. Those of you who provide CPE gear should ponder where that leaves you... Bonus points for figuring out what this effectively means for devices actually assembled in China for sale in the US... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From bryan at shout.net Sat Feb 11 15:18:58 2017 From: bryan at shout.net (Bryan Holloway) Date: Sat, 11 Feb 2017 09:18:58 -0600 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: Yup, they do indeed. And for fun, I black-listed one of our IPs, and sure enough, the next-hop shows up as 10.255.255.255, and the communities are the same aside from what appear to be regional things. -- BGP routing table entry for 66.253.214.90/32, version 638637516 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 23473 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) Origin IGP, localpref 150, valid, internal, best Community: 174:990 174:20912 174:21001 174:22013 Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 On 2/10/17 1:49 PM, Alistair Mackenzie wrote: > Cogent also have a blackhole route-server that they will provide to you to > announce /32's for blackholing. > > The address for this is 66.28.1.228 which is the originator for the > 104.31.19.30/3 2 and 104.31.18.30/32 routes. > > On 10 February 2017 at 18:46, Jason Rokeach wrote: > >> This looks pretty intentional to me. From >> http://www.cogentco.com/en/network/looking-glass: >> >> BGP routing table entry for 104.31.18.30/32, version 611495773 >> Paths: (1 available, best #1, table Default-IP-Routing-Table) >> Local >> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >> Origin IGP, metric 0, localpref 150, valid, internal, best >> Community: 174:990 174:20912 174:21001 >> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >> >> BGP routing table entry for 104.31.19.30/32, version 611495772 >> Paths: (1 available, best #1, table Default-IP-Routing-Table) >> Local >> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >> Origin IGP, metric 0, localpref 150, valid, internal, best >> Community: 174:990 174:20912 174:21001 >> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >> >> >> Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop router. >> >> On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: >> >>> Have we determined that this is intentional vs. some screw up? >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> ----- Original Message ----- >>> >>> From: "Brielle Bruns" >>> To: nanog at nanog.org >>> Sent: Friday, February 10, 2017 12:28:53 PM >>> Subject: Re: backbones filtering unsanctioned sites >>> >>> On 2/9/17 9:18 PM, Ken Chase wrote: >>>> https://torrentfreak.com/internet-backbone-provider- >>> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ >>>> >>>> /kc >>>> >>> >>> Funny. Someone else got back: >>> >>> "Abuse cannot not provide you a list of websites that may be >>> encountering reduced visibility via Cogent" >>> >>> I almost wish I had a Cogent circuit just to bring this up with an >>> account rep. Almost. >>> >>> I'd very much so view this as a contractual violation on Cogent's part. >>> >>> Cogent keeps contacting me every year wanting to sell me service. This >>> will be a good one to bring up when they call me next time. >>> >>> -- >>> Brielle Bruns >>> The Summit Open Source Development Group >>> http://www.sosdg.org / http://www.ahbl.org >>> >>> >> From magicsata at gmail.com Sat Feb 11 20:44:23 2017 From: magicsata at gmail.com (Alistair Mackenzie) Date: Sat, 11 Feb 2017 20:44:23 +0000 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: Cogent confirmed on the phone that they are the ones who put the blackhole in place. This is after they closed our ticket twice without response. Purposely didn't mention a website in the ticket yet they asked on the phone if it was regarding thepiratebay so they are very aware of this... On 11 February 2017 at 15:18, Bryan Holloway wrote: > Yup, they do indeed. And for fun, I black-listed one of our IPs, and sure > enough, the next-hop shows up as 10.255.255.255, and the communities are > the same aside from what appear to be regional things. > > -- > > BGP routing table entry for 66.253.214.90/32, version 638637516 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Flag: 0x820 > 23473 > 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) > Origin IGP, localpref 150, valid, internal, best > Community: 174:990 174:20912 174:21001 174:22013 > Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 > > > > On 2/10/17 1:49 PM, Alistair Mackenzie wrote: > >> Cogent also have a blackhole route-server that they will provide to you to >> announce /32's for blackholing. >> >> The address for this is 66.28.1.228 which is the originator for the >> 104.31.19.30/3 2 and 104.31.18.30/32 routes. >> >> >> On 10 February 2017 at 18:46, Jason Rokeach wrote: >> >> This looks pretty intentional to me. From >>> http://www.cogentco.com/en/network/looking-glass: >>> >>> BGP routing table entry for 104.31.18.30/32, version 611495773 >>> Paths: (1 available, best #1, table Default-IP-Routing-Table) >>> Local >>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >>> Origin IGP, metric 0, localpref 150, valid, internal, best >>> Community: 174:990 174:20912 174:21001 >>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >>> >>> BGP routing table entry for 104.31.19.30/32, version 611495772 >>> Paths: (1 available, best #1, table Default-IP-Routing-Table) >>> Local >>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >>> Origin IGP, metric 0, localpref 150, valid, internal, best >>> Community: 174:990 174:20912 174:21001 >>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >>> >>> >>> Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop router. >>> >>> On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett wrote: >>> >>> Have we determined that this is intentional vs. some screw up? >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> Midwest-IX >>>> http://www.midwest-ix.com >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Brielle Bruns" >>>> To: nanog at nanog.org >>>> Sent: Friday, February 10, 2017 12:28:53 PM >>>> Subject: Re: backbones filtering unsanctioned sites >>>> >>>> On 2/9/17 9:18 PM, Ken Chase wrote: >>>> >>>>> https://torrentfreak.com/internet-backbone-provider- >>>>> >>>> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ >>>> >>>>> >>>>> /kc >>>>> >>>>> >>>> Funny. Someone else got back: >>>> >>>> "Abuse cannot not provide you a list of websites that may be >>>> encountering reduced visibility via Cogent" >>>> >>>> I almost wish I had a Cogent circuit just to bring this up with an >>>> account rep. Almost. >>>> >>>> I'd very much so view this as a contractual violation on Cogent's part. >>>> >>>> Cogent keeps contacting me every year wanting to sell me service. This >>>> will be a good one to bring up when they call me next time. >>>> >>>> -- >>>> Brielle Bruns >>>> The Summit Open Source Development Group >>>> http://www.sosdg.org / http://www.ahbl.org >>>> >>>> >>>> >>> From admin at marcoteixeira.com Sat Feb 11 22:11:20 2017 From: admin at marcoteixeira.com (Marco Teixeira) Date: Sat, 11 Feb 2017 22:11:20 +0000 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: So... i doubt CloudFlare allocates one ip per domain served... which means Cogent customers will be unable to access other CloudFlare proxied site, served by this same IP, for a particular geographic zone? --- Marco On Sat, Feb 11, 2017 at 8:44 PM, Alistair Mackenzie wrote: > Cogent confirmed on the phone that they are the ones who put the blackhole > in place. This is after they closed our ticket twice without response. > > Purposely didn't mention a website in the ticket yet they asked on the > phone if it was regarding thepiratebay so they are very aware of this... > > On 11 February 2017 at 15:18, Bryan Holloway wrote: > > > Yup, they do indeed. And for fun, I black-listed one of our IPs, and sure > > enough, the next-hop shows up as 10.255.255.255, and the communities are > > the same aside from what appear to be regional things. > > > > -- > > > > BGP routing table entry for 66.253.214.90/32, version 638637516 > > Paths: (1 available, best #1, table Default-IP-Routing-Table) > > Flag: 0x820 > > 23473 > > 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) > > Origin IGP, localpref 150, valid, internal, best > > Community: 174:990 174:20912 174:21001 174:22013 > > Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 > > > > > > > > On 2/10/17 1:49 PM, Alistair Mackenzie wrote: > > > >> Cogent also have a blackhole route-server that they will provide to you > to > >> announce /32's for blackholing. > >> > >> The address for this is 66.28.1.228 which is the originator for the > >> 104.31.19.30/3 2 and 104.31.18.30/32 routes. > >> > >> > >> On 10 February 2017 at 18:46, Jason Rokeach wrote: > >> > >> This looks pretty intentional to me. From > >>> http://www.cogentco.com/en/network/looking-glass: > >>> > >>> BGP routing table entry for 104.31.18.30/32, version 611495773 > >>> Paths: (1 available, best #1, table Default-IP-Routing-Table) > >>> Local > >>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) > >>> Origin IGP, metric 0, localpref 150, valid, internal, best > >>> Community: 174:990 174:20912 174:21001 > >>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 > >>> > >>> BGP routing table entry for 104.31.19.30/32, version 611495772 > >>> Paths: (1 available, best #1, table Default-IP-Routing-Table) > >>> Local > >>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) > >>> Origin IGP, metric 0, localpref 150, valid, internal, best > >>> Community: 174:990 174:20912 174:21001 > >>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 > >>> > >>> > >>> Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop > router. > >>> > >>> On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett > wrote: > >>> > >>> Have we determined that this is intentional vs. some screw up? > >>>> > >>>> > >>>> > >>>> > >>>> ----- > >>>> Mike Hammett > >>>> Intelligent Computing Solutions > >>>> http://www.ics-il.com > >>>> > >>>> Midwest-IX > >>>> http://www.midwest-ix.com > >>>> > >>>> ----- Original Message ----- > >>>> > >>>> From: "Brielle Bruns" > >>>> To: nanog at nanog.org > >>>> Sent: Friday, February 10, 2017 12:28:53 PM > >>>> Subject: Re: backbones filtering unsanctioned sites > >>>> > >>>> On 2/9/17 9:18 PM, Ken Chase wrote: > >>>> > >>>>> https://torrentfreak.com/internet-backbone-provider- > >>>>> > >>>> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ > >>>> > >>>>> > >>>>> /kc > >>>>> > >>>>> > >>>> Funny. Someone else got back: > >>>> > >>>> "Abuse cannot not provide you a list of websites that may be > >>>> encountering reduced visibility via Cogent" > >>>> > >>>> I almost wish I had a Cogent circuit just to bring this up with an > >>>> account rep. Almost. > >>>> > >>>> I'd very much so view this as a contractual violation on Cogent's > part. > >>>> > >>>> Cogent keeps contacting me every year wanting to sell me service. This > >>>> will be a good one to bring up when they call me next time. > >>>> > >>>> -- > >>>> Brielle Bruns > >>>> The Summit Open Source Development Group > >>>> http://www.sosdg.org / http://www.ahbl.org > >>>> > >>>> > >>>> > >>> > From jason at unlimitednet.us Sat Feb 11 22:40:37 2017 From: jason at unlimitednet.us (Jason Canady) Date: Sat, 11 Feb 2017 17:40:37 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> Message-ID: <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> Cogent's best friend to the rescue: http://bgp.he.net/ip/104.31.18.30#_dns Looks like mostly proxy/torrent sites on that IP address. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure On 2/11/17 5:11 PM, Marco Teixeira wrote: > So... i doubt CloudFlare allocates one ip per domain served... which means > Cogent customers will be unable to access other CloudFlare proxied site, > served by this same IP, for a particular geographic zone? > > > --- > Marco > > > > On Sat, Feb 11, 2017 at 8:44 PM, Alistair Mackenzie > wrote: > >> Cogent confirmed on the phone that they are the ones who put the blackhole >> in place. This is after they closed our ticket twice without response. >> >> Purposely didn't mention a website in the ticket yet they asked on the >> phone if it was regarding thepiratebay so they are very aware of this... >> >> On 11 February 2017 at 15:18, Bryan Holloway wrote: >> >>> Yup, they do indeed. And for fun, I black-listed one of our IPs, and sure >>> enough, the next-hop shows up as 10.255.255.255, and the communities are >>> the same aside from what appear to be regional things. >>> >>> -- >>> >>> BGP routing table entry for 66.253.214.90/32, version 638637516 >>> Paths: (1 available, best #1, table Default-IP-Routing-Table) >>> Flag: 0x820 >>> 23473 >>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >>> Origin IGP, localpref 150, valid, internal, best >>> Community: 174:990 174:20912 174:21001 174:22013 >>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >>> >>> >>> >>> On 2/10/17 1:49 PM, Alistair Mackenzie wrote: >>> >>>> Cogent also have a blackhole route-server that they will provide to you >> to >>>> announce /32's for blackholing. >>>> >>>> The address for this is 66.28.1.228 which is the originator for the >>>> 104.31.19.30/3 2 and 104.31.18.30/32 routes. >>>> >>>> >>>> On 10 February 2017 at 18:46, Jason Rokeach wrote: >>>> >>>> This looks pretty intentional to me. From >>>>> http://www.cogentco.com/en/network/looking-glass: >>>>> >>>>> BGP routing table entry for 104.31.18.30/32, version 611495773 >>>>> Paths: (1 available, best #1, table Default-IP-Routing-Table) >>>>> Local >>>>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >>>>> Origin IGP, metric 0, localpref 150, valid, internal, best >>>>> Community: 174:990 174:20912 174:21001 >>>>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >>>>> >>>>> BGP routing table entry for 104.31.19.30/32, version 611495772 >>>>> Paths: (1 available, best #1, table Default-IP-Routing-Table) >>>>> Local >>>>> 10.255.255.255 (metric 10177050) from 154.54.66.21 (154.54.66.21) >>>>> Origin IGP, metric 0, localpref 150, valid, internal, best >>>>> Community: 174:990 174:20912 174:21001 >>>>> Originator: 66.28.1.228, Cluster list: 154.54.66.21, 66.28.1.9 >>>>> >>>>> >>>>> Call it a "hunch" but I doubt 10.255.255.255 is a valid next-hop >> router. >>>>> On Fri, Feb 10, 2017 at 1:39 PM, Mike Hammett >> wrote: >>>>> Have we determined that this is intentional vs. some screw up? >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Mike Hammett >>>>>> Intelligent Computing Solutions >>>>>> http://www.ics-il.com >>>>>> >>>>>> Midwest-IX >>>>>> http://www.midwest-ix.com >>>>>> >>>>>> ----- Original Message ----- >>>>>> >>>>>> From: "Brielle Bruns" >>>>>> To: nanog at nanog.org >>>>>> Sent: Friday, February 10, 2017 12:28:53 PM >>>>>> Subject: Re: backbones filtering unsanctioned sites >>>>>> >>>>>> On 2/9/17 9:18 PM, Ken Chase wrote: >>>>>> >>>>>>> https://torrentfreak.com/internet-backbone-provider- >>>>>>> >>>>>> cogent-blocks-pirate-bay-and-other-pirate-sites-170209/ >>>>>> >>>>>>> /kc >>>>>>> >>>>>>> >>>>>> Funny. Someone else got back: >>>>>> >>>>>> "Abuse cannot not provide you a list of websites that may be >>>>>> encountering reduced visibility via Cogent" >>>>>> >>>>>> I almost wish I had a Cogent circuit just to bring this up with an >>>>>> account rep. Almost. >>>>>> >>>>>> I'd very much so view this as a contractual violation on Cogent's >> part. >>>>>> Cogent keeps contacting me every year wanting to sell me service. This >>>>>> will be a good one to bring up when they call me next time. >>>>>> >>>>>> -- >>>>>> Brielle Bruns >>>>>> The Summit Open Source Development Group >>>>>> http://www.sosdg.org / http://www.ahbl.org >>>>>> >>>>>> >>>>>> From wwaites at tardis.ed.ac.uk Sat Feb 11 23:05:50 2017 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Sat, 11 Feb 2017 23:05:50 +0000 Subject: backbones filtering unsanctioned sites In-Reply-To: <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> Message-ID: > Looks like mostly proxy/torrent sites on that IP address. That may be so. Maybe it isn?t particularly objectionable for Cogent to not to carry traffic to some particular destination that they don?t like. As you point out they already only offer a partial view of the Internet. What is very problematic is that they announce that this destination is reachable via them, and then drop traffic. This is a problem for the same reason that hijacking by announcing more specifics is a problem. The bgp tables become no longer a source of truth about reachability. If this kind of behaviour from transit networks becomes the norm, we are in big trouble. William Waites LFCS, School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From nanog at ics-il.net Sat Feb 11 23:17:49 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 11 Feb 2017 17:17:49 -0600 (CST) Subject: Hulu Message-ID: <1594195810.5081.1486855065051.JavaMail.mhammett@ThunderFuck> 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 From mel at beckman.org Mon Feb 13 00:30:16 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Feb 2017 00:30:16 +0000 Subject: YouTube streaming failures Message-ID: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> We are getting many customer reports of YouTube streaming failures. The content directory and search work, but attempts to view videos results in "something went wrong, click to try again" error messages. We've reproduced the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are also seeing it on cellular data connections, which tends to rule out geo-IP errors. Is anyone else seeing this? -mel beckman From lists at silverlakeinternet.com Mon Feb 13 01:08:39 2017 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Sun, 12 Feb 2017 18:08:39 -0700 Subject: YouTube streaming failures In-Reply-To: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> References: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> Message-ID: I'm seeing this as well, but only on Apple and Linux products. Seems to be working fine on Windows. Thank you, Brett A Mansfield > On Feb 12, 2017, at 5:30 PM, Mel Beckman wrote: > > We are getting many customer reports of YouTube streaming failures. The content directory and search work, but attempts to view videos results in "something went wrong, click to try again" error messages. We've reproduced the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are also seeing it on cellular data connections, which tends to rule out geo-IP errors. Is anyone else seeing this? > > -mel beckman From patrick at ianai.net Mon Feb 13 01:53:29 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 12 Feb 2017 20:53:29 -0500 Subject: YouTube streaming failures In-Reply-To: References: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> Message-ID: <1229CF74-110A-4B12-BB82-9A772E1797B6@ianai.net> I cannot stream on AppleTV or iPhone. Works on my laptop. Comcast, Massachusetts. -- TTFN, patrick > On Feb 12, 2017, at 8:08 PM, Brett A Mansfield wrote: > > I'm seeing this as well, but only on Apple and Linux products. Seems to be working fine on Windows. > > Thank you, > Brett A Mansfield > >> On Feb 12, 2017, at 5:30 PM, Mel Beckman wrote: >> >> We are getting many customer reports of YouTube streaming failures. The content directory and search work, but attempts to view videos results in "something went wrong, click to try again" error messages. We've reproduced the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are also seeing it on cellular data connections, which tends to rule out geo-IP errors. Is anyone else seeing this? >> >> -mel beckman From morrowc.lists at gmail.com Mon Feb 13 02:06:43 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 12 Feb 2017 21:06:43 -0500 Subject: YouTube streaming failures In-Reply-To: <1229CF74-110A-4B12-BB82-9A772E1797B6@ianai.net> References: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> <1229CF74-110A-4B12-BB82-9A772E1797B6@ianai.net> Message-ID: verizon wired, comcast (on a mobile device) both work in IAD's area. On Sun, Feb 12, 2017 at 8:53 PM, Patrick W. Gilmore wrote: > I cannot stream on AppleTV or iPhone. Works on my laptop. > > Comcast, Massachusetts. > > -- > TTFN, > patrick > > > On Feb 12, 2017, at 8:08 PM, Brett A Mansfield < > lists at silverlakeinternet.com> wrote: > > > > I'm seeing this as well, but only on Apple and Linux products. Seems to > be working fine on Windows. > > > > Thank you, > > Brett A Mansfield > > > >> On Feb 12, 2017, at 5:30 PM, Mel Beckman wrote: > >> > >> We are getting many customer reports of YouTube streaming failures. The > content directory and search work, but attempts to view videos results in > "something went wrong, click to try again" error messages. We've reproduced > the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are also > seeing it on cellular data connections, which tends to rule out geo-IP > errors. Is anyone else seeing this? > >> > >> -mel beckman > > From jayfar at jayfar.com Mon Feb 13 02:32:40 2017 From: jayfar at jayfar.com (Jay Farrell) Date: Sun, 12 Feb 2017 21:32:40 -0500 Subject: YouTube streaming failures In-Reply-To: References: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> <1229CF74-110A-4B12-BB82-9A772E1797B6@ianai.net> Message-ID: Downdetector shows a big spike in reports for youtube in the past several hours. http://downdetector.com/status/youtube On Sun, Feb 12, 2017 at 9:06 PM, Christopher Morrow wrote: > verizon wired, comcast (on a mobile device) both work in IAD's area. > > On Sun, Feb 12, 2017 at 8:53 PM, Patrick W. Gilmore > wrote: > > > I cannot stream on AppleTV or iPhone. Works on my laptop. > > > > Comcast, Massachusetts. > > > > -- > > TTFN, > > patrick > > > > > On Feb 12, 2017, at 8:08 PM, Brett A Mansfield < > > lists at silverlakeinternet.com> wrote: > > > > > > I'm seeing this as well, but only on Apple and Linux products. Seems to > > be working fine on Windows. > > > > > > Thank you, > > > Brett A Mansfield > > > > > >> On Feb 12, 2017, at 5:30 PM, Mel Beckman wrote: > > >> > > >> We are getting many customer reports of YouTube streaming failures. > The > > content directory and search work, but attempts to view videos results in > > "something went wrong, click to try again" error messages. We've > reproduced > > the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are > also > > seeing it on cellular data connections, which tends to rule out geo-IP > > errors. Is anyone else seeing this? > > >> > > >> -mel beckman > > > > > From jayfar at jayfar.com Mon Feb 13 02:42:48 2017 From: jayfar at jayfar.com (Jay Farrell) Date: Sun, 12 Feb 2017 21:42:48 -0500 Subject: YouTube streaming failures In-Reply-To: References: <900DD419-CF4A-4B15-9590-0E72291DB575@beckman.org> <1229CF74-110A-4B12-BB82-9A772E1797B6@ianai.net> Message-ID: Youtube is aware, according to a boilerplate message in their support forum: Hi there, welcome to the YouTube Help Forum! "YouTube is aware of the issue. Please stay tuned to YouTube's social media and the forums for any announcement of a fix. Thanks for reporting!" On Sun, Feb 12, 2017 at 9:32 PM, Jay Farrell wrote: > Downdetector shows a big spike in reports for youtube in the past several > hours. > > http://downdetector.com/status/youtube > > On Sun, Feb 12, 2017 at 9:06 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> verizon wired, comcast (on a mobile device) both work in IAD's area. >> >> On Sun, Feb 12, 2017 at 8:53 PM, Patrick W. Gilmore >> wrote: >> >> > I cannot stream on AppleTV or iPhone. Works on my laptop. >> > >> > Comcast, Massachusetts. >> > >> > -- >> > TTFN, >> > patrick >> > >> > > On Feb 12, 2017, at 8:08 PM, Brett A Mansfield < >> > lists at silverlakeinternet.com> wrote: >> > > >> > > I'm seeing this as well, but only on Apple and Linux products. Seems >> to >> > be working fine on Windows. >> > > >> > > Thank you, >> > > Brett A Mansfield >> > > >> > >> On Feb 12, 2017, at 5:30 PM, Mel Beckman wrote: >> > >> >> > >> We are getting many customer reports of YouTube streaming failures. >> The >> > content directory and search work, but attempts to view videos results >> in >> > "something went wrong, click to try again" error messages. We've >> reproduced >> > the problem on AT&T, Level3, Frontier, Cox and Comast networks. We are >> also >> > seeing it on cellular data connections, which tends to rule out geo-IP >> > errors. Is anyone else seeing this? >> > >> >> > >> -mel beckman >> > >> > >> > > From mfidelman at meetinghouse.net Mon Feb 13 03:12:13 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 12 Feb 2017 20:12:13 -0700 Subject: is something weird going on with cox, level3, and/or cogent Message-ID: <3ebb9b37-b8ef-10fb-17c6-1fe64da35aa4@meetinghouse.net> Hi Folks, I'm visiting AZ, and seeing some really really poor performance accessing some of our servers via Cox broadband. The folks at Cox technical support are useless - all they say is "well you're on a DOCSIS 2 modem." Meanwhile, everything I'm seeing is several hops upstream of the local segment - and all that Cox level2 tech support will say is "if there was a backbone problem, our backbone people would have dealt with it." I'm having problems reaching both our own server, and sites like google, facebook, windows update. Traceroutes to and from our server are illustrative - note that for most of the past week, the average ping time was 85msec. Now we're seeing this: From 98.177.135.186 - the public IP address on Cox's local broadband service. To 107.154.13.58 (ntcorp.server - one of our servers, sitting in a Tierpoint data center, near Boston) traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets 1 10.128.128.1 (10.128.128.1) 199.893 ms 75.319 ms 27.295 ms 2 100.127.69.178 (100.127.69.178) 38.710 ms 40.075 ms 43.598 ms 3 72.215.229.22 (72.215.229.22) 39.674 ms 201.368 ms * 4 lag-157.bear2.phoenix1.level3.net (4.28.82.53) 686.499 ms 1837.141 ms 16.273 ms 5 ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 35.498 ms 964.377 ms * 6 ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 551.760 ms 525.014 ms ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 2061.191 ms 7 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 847.778 ms 87.601 ms 71.504 ms 8 be2965.ccr22.lax01.atlas.cogentco.com (154.54.45.1) 79.060 ms 225.647 ms be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 60.306 ms 9 * be2931.ccr21.phx02.atlas.cogentco.com (154.54.44.85) 2264.071 ms 185.180 ms 10 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 61.208 ms be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 386.149 ms 1278.868 ms 11 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 384.136 ms be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 2339.833 ms 615.415 ms 12 be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 233.061 ms be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 87.902 ms be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 861.159 ms 13 be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 998.858 ms be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 249.930 ms * 14 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 768.461 ms be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.772 ms be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 288.225 ms 15 be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 271.736 ms 166.224 ms be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 565.015 ms 16 te0-4-1-7.agr22.bos01.atlas.cogentco.com (154.54.80.34) 1944.479 ms te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 149.803 ms te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 897.115 ms 17 te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 107.207 ms te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 295.881 ms 185.453 ms 18 38.122.127.18 (38.122.127.18) 115.652 ms 461.168 ms 615.526 ms 19 207.154.0.57 (207.154.0.57) 1871.023 ms 1987.832 ms 2165.248 ms 20 server1.ntcorp.com (207.154.13.58) 587.560 ms 263.328 ms 333.542 ms Traceroute in the reverse direction: 1 207.154.13.47 (207.154.13.47) 0.000 ms 0.000 ms 0.000 ms 2 * * * 3 h130.207.190.173.static.ip.windstream.net (173.190.207.130) 0.000 ms 0.000 ms 0.000 ms 4 xe1-2-0-0.cr01.cley01-oh.us.windstream.net (40.128.250.166) 12.000 ms 12.000 ms 12.000 ms 5 et11-0-0-0.cr01.chcg01-il.us.windstream.net (40.128.248.71) 20.000 ms 20.000 ms 20.000 ms 6 10gigabitethernet4-1.core1.chi1.he.NET (206.223.119.37) 72.001 ms 20.000 ms 16.000 ms 7 chgobbrj01pos010100.r2.ch.cox.net (68.105.30.193) 20.000 ms 20.000 ms 20.000 ms 8 chnddsrj01-ae1.0.rd.ph.cox.net (68.1.5.211) 72.001 ms 72.001 ms 72.001 ms 9 * * * 10 * * * 11 * * * 30 * * * Two things jump out at me: 1. The rather large number of hops from cox to ntcorp - with high delays from several nodes in both the level3 and cogent networks. 2. That there's a rather more direct path from the datacenter to cox, that shows up in the reverse direction. Some kind of routing or peering issue, perhaps? (And I also note the earlier string of messages regarding youtube streaming problems - that also seemed to involve cox and level3. Thanks for any insight (and better, for any fixes!). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mel at beckman.org Mon Feb 13 03:45:36 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Feb 2017 03:45:36 +0000 Subject: is something weird going on with cox, level3, and/or cogent In-Reply-To: <3ebb9b37-b8ef-10fb-17c6-1fe64da35aa4@meetinghouse.net> References: <3ebb9b37-b8ef-10fb-17c6-1fe64da35aa4@meetinghouse.net> Message-ID: It looks like one or more circuits are down, so you're seeing asymmetrical routing over congested paths in one direction. -mel via cell > On Feb 12, 2017, at 7:14 PM, Miles Fidelman wrote: > > Hi Folks, > > I'm visiting AZ, and seeing some really really poor performance accessing some of our servers via Cox broadband. The folks at Cox technical support are useless - all they say is "well you're on a DOCSIS 2 modem." Meanwhile, everything I'm seeing is several hops upstream of the local segment - and all that Cox level2 tech support will say is "if there was a backbone problem, our backbone people would have dealt with it." > > I'm having problems reaching both our own server, and sites like google, facebook, windows update. > > Traceroutes to and from our server are illustrative - note that for most of the past week, the average ping time was 85msec. Now we're seeing this: > > From 98.177.135.186 - the public IP address on Cox's local broadband service. > To 107.154.13.58 (ntcorp.server - one of our servers, sitting in a Tierpoint data center, near Boston) > traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets > 1 10.128.128.1 (10.128.128.1) 199.893 ms 75.319 ms 27.295 ms > 2 100.127.69.178 (100.127.69.178) 38.710 ms 40.075 ms 43.598 ms > 3 72.215.229.22 (72.215.229.22) 39.674 ms 201.368 ms * > 4 lag-157.bear2.phoenix1.level3.net (4.28.82.53) 686.499 ms 1837.141 ms 16.273 ms > 5 ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 35.498 ms 964.377 ms * > 6 ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 551.760 ms 525.014 ms > ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 2061.191 ms > 7 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 847.778 ms 87.601 ms 71.504 ms > 8 be2965.ccr22.lax01.atlas.cogentco.com (154.54.45.1) 79.060 ms 225.647 ms > be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 60.306 ms > 9 * be2931.ccr21.phx02.atlas.cogentco.com (154.54.44.85) 2264.071 ms 185.180 ms > 10 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 61.208 ms > be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 386.149 ms 1278.868 ms > 11 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 384.136 ms > be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 2339.833 ms 615.415 ms > 12 be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 233.061 ms > be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 87.902 ms > be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 861.159 ms > 13 be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 998.858 ms > be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 249.930 ms * > 14 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 768.461 ms > be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.772 ms > be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 288.225 ms > 15 be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 271.736 ms 166.224 ms > be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 565.015 ms > 16 te0-4-1-7.agr22.bos01.atlas.cogentco.com (154.54.80.34) 1944.479 ms > te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 149.803 ms > te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 897.115 ms > 17 te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 107.207 ms > te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 295.881 ms 185.453 ms > 18 38.122.127.18 (38.122.127.18) 115.652 ms 461.168 ms 615.526 ms > 19 207.154.0.57 (207.154.0.57) 1871.023 ms 1987.832 ms 2165.248 ms > 20 server1.ntcorp.com (207.154.13.58) 587.560 ms 263.328 ms 333.542 ms > > > Traceroute in the reverse direction: > 1 207.154.13.47 (207.154.13.47) 0.000 ms 0.000 ms 0.000 ms > 2 * * * > 3 h130.207.190.173.static.ip.windstream.net (173.190.207.130) 0.000 ms 0.000 ms 0.000 ms > 4 xe1-2-0-0.cr01.cley01-oh.us.windstream.net (40.128.250.166) 12.000 ms 12.000 ms 12.000 ms > 5 et11-0-0-0.cr01.chcg01-il.us.windstream.net (40.128.248.71) 20.000 ms 20.000 ms 20.000 ms > 6 10gigabitethernet4-1.core1.chi1.he.NET (206.223.119.37) 72.001 ms 20.000 ms 16.000 ms > 7 chgobbrj01pos010100.r2.ch.cox.net (68.105.30.193) 20.000 ms 20.000 ms 20.000 ms > 8 chnddsrj01-ae1.0.rd.ph.cox.net (68.1.5.211) 72.001 ms 72.001 ms 72.001 ms > 9 * * * > 10 * * * > 11 * * * > > 30 * * * > > > Two things jump out at me: > 1. The rather large number of hops from cox to ntcorp - with high delays from several nodes in both the level3 and cogent networks. > 2. That there's a rather more direct path from the datacenter to cox, that shows up in the reverse direction. > > Some kind of routing or peering issue, perhaps? (And I also note the earlier string of messages regarding youtube streaming problems - that also seemed to involve cox and level3. > > Thanks for any insight (and better, for any fixes!). > > Miles Fidelman > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > From mel at beckman.org Mon Feb 13 03:57:22 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Feb 2017 03:57:22 +0000 Subject: is something weird going on with cox, level3, and/or cogent In-Reply-To: References: <3ebb9b37-b8ef-10fb-17c6-1fe64da35aa4@meetinghouse.net>, Message-ID: <330160BA-7F4B-4402-ACBE-789FAA451F54@beckman.org> Miles, Have you tried trace routing through cellular data connections? The results you're seeing could be explained by congestion at the point of your modem, which I think is with the cox techs are implying. -mel via cell > On Feb 12, 2017, at 7:46 PM, Mel Beckman wrote: > > It looks like one or more circuits are down, so you're seeing asymmetrical routing over congested paths in one direction. > > -mel via cell > >> On Feb 12, 2017, at 7:14 PM, Miles Fidelman wrote: >> >> Hi Folks, >> >> I'm visiting AZ, and seeing some really really poor performance accessing some of our servers via Cox broadband. The folks at Cox technical support are useless - all they say is "well you're on a DOCSIS 2 modem." Meanwhile, everything I'm seeing is several hops upstream of the local segment - and all that Cox level2 tech support will say is "if there was a backbone problem, our backbone people would have dealt with it." >> >> I'm having problems reaching both our own server, and sites like google, facebook, windows update. >> >> Traceroutes to and from our server are illustrative - note that for most of the past week, the average ping time was 85msec. Now we're seeing this: >> >> From 98.177.135.186 - the public IP address on Cox's local broadband service. >> To 107.154.13.58 (ntcorp.server - one of our servers, sitting in a Tierpoint data center, near Boston) >> traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets >> 1 10.128.128.1 (10.128.128.1) 199.893 ms 75.319 ms 27.295 ms >> 2 100.127.69.178 (100.127.69.178) 38.710 ms 40.075 ms 43.598 ms >> 3 72.215.229.22 (72.215.229.22) 39.674 ms 201.368 ms * >> 4 lag-157.bear2.phoenix1.level3.net (4.28.82.53) 686.499 ms 1837.141 ms 16.273 ms >> 5 ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 35.498 ms 964.377 ms * >> 6 ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 551.760 ms 525.014 ms >> ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 2061.191 ms >> 7 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 847.778 ms 87.601 ms 71.504 ms >> 8 be2965.ccr22.lax01.atlas.cogentco.com (154.54.45.1) 79.060 ms 225.647 ms >> be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 60.306 ms >> 9 * be2931.ccr21.phx02.atlas.cogentco.com (154.54.44.85) 2264.071 ms 185.180 ms >> 10 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 61.208 ms >> be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 386.149 ms 1278.868 ms >> 11 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 384.136 ms >> be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 2339.833 ms 615.415 ms >> 12 be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 233.061 ms >> be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 87.902 ms >> be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 861.159 ms >> 13 be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 998.858 ms >> be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 249.930 ms * >> 14 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 768.461 ms >> be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.772 ms >> be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 288.225 ms >> 15 be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 271.736 ms 166.224 ms >> be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 565.015 ms >> 16 te0-4-1-7.agr22.bos01.atlas.cogentco.com (154.54.80.34) 1944.479 ms >> te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 149.803 ms >> te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 897.115 ms >> 17 te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 107.207 ms >> te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 295.881 ms 185.453 ms >> 18 38.122.127.18 (38.122.127.18) 115.652 ms 461.168 ms 615.526 ms >> 19 207.154.0.57 (207.154.0.57) 1871.023 ms 1987.832 ms 2165.248 ms >> 20 server1.ntcorp.com (207.154.13.58) 587.560 ms 263.328 ms 333.542 ms >> >> >> Traceroute in the reverse direction: >> 1 207.154.13.47 (207.154.13.47) 0.000 ms 0.000 ms 0.000 ms >> 2 * * * >> 3 h130.207.190.173.static.ip.windstream.net (173.190.207.130) 0.000 ms 0.000 ms 0.000 ms >> 4 xe1-2-0-0.cr01.cley01-oh.us.windstream.net (40.128.250.166) 12.000 ms 12.000 ms 12.000 ms >> 5 et11-0-0-0.cr01.chcg01-il.us.windstream.net (40.128.248.71) 20.000 ms 20.000 ms 20.000 ms >> 6 10gigabitethernet4-1.core1.chi1.he.NET (206.223.119.37) 72.001 ms 20.000 ms 16.000 ms >> 7 chgobbrj01pos010100.r2.ch.cox.net (68.105.30.193) 20.000 ms 20.000 ms 20.000 ms >> 8 chnddsrj01-ae1.0.rd.ph.cox.net (68.1.5.211) 72.001 ms 72.001 ms 72.001 ms >> 9 * * * >> 10 * * * >> 11 * * * >> >> 30 * * * >> >> >> Two things jump out at me: >> 1. The rather large number of hops from cox to ntcorp - with high delays from several nodes in both the level3 and cogent networks. >> 2. That there's a rather more direct path from the datacenter to cox, that shows up in the reverse direction. >> >> Some kind of routing or peering issue, perhaps? (And I also note the earlier string of messages regarding youtube streaming problems - that also seemed to involve cox and level3. >> >> Thanks for any insight (and better, for any fixes!). >> >> Miles Fidelman >> >> >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> From mfidelman at meetinghouse.net Mon Feb 13 04:27:02 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 12 Feb 2017 21:27:02 -0700 Subject: is something weird going on with cox, level3, and/or cogent In-Reply-To: <330160BA-7F4B-4402-ACBE-789FAA451F54@beckman.org> References: <3ebb9b37-b8ef-10fb-17c6-1fe64da35aa4@meetinghouse.net> <330160BA-7F4B-4402-ACBE-789FAA451F54@beckman.org> Message-ID: Now isn't that interesting. 1. Verizon mobile seems to also route through level3 and cogent. 2. But.. the performance seems to be a lot better. 3. That's really odd. 1 192.168.43.1 (192.168.43.1) 2.063 ms 2.382 ms 1.913 ms 2 7.sub-66-174-33.myvzw.com (66.174.33.7) 50.676 ms 36.720 ms 41.142 ms 3 164.sub-69-83-172.myvzw.com (69.83.172.164) 39.831 ms 40.240 ms 40.190 ms 4 178.sub-69-83-173.myvzw.com (69.83.173.178) 39.851 ms 48.650 ms 30.921 ms 5 194.sub-69-83-173.myvzw.com (69.83.173.194) 49.134 ms 31.131 ms 39.946 ms 6 8.sub-69-83-162.myvzw.com (69.83.162.8) 42.841 ms 39.532 ms 40.024 ms 7 73.sub-66-174-29.myvzw.com (66.174.29.73) 44.074 ms 31.248 ms 42.199 ms 8 5-1-1.bear1.phoenix1.level3.net (4.16.142.89) 38.474 ms 39.555 ms 57.860 ms 9 ae-2-70.edge1.losangeles6.level3.net (4.69.144.80) 86.101 ms 78.856 ms ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 70.001 ms 10 ae-4-90.edge1.losangeles6.level3.net (4.69.144.208) 48.840 ms ae-2-70.edge1.losangeles6.level3.net (4.69.144.80) 71.847 ms ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 81.841 ms 11 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 70.538 ms 39.175 ms 45.213 ms 12 be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 89.463 ms 78.656 ms 72.936 ms 13 be2932.ccr22.phx02.atlas.cogentco.com (154.54.45.161) 106.896 ms 82.389 ms 87.310 ms 14 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 72.782 ms 76.034 ms 114.967 ms 15 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 87.883 ms 100.641 ms be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 117.904 ms 16 be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 144.881 ms be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 135.465 ms 110.129 ms 17 be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 93.713 ms be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 128.171 ms be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 109.207 ms 18 be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.620 ms be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 113.346 ms be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 118.301 ms 19 be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 148.778 ms 166.763 ms be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 153.433 ms 20 te0-4-1-7.agr21.bos01.atlas.cogentco.com (154.54.47.254) 143.449 ms te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 242.964 ms te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 198.678 ms 21 te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 139.454 ms te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 132.726 ms 107.254 ms 22 38.122.127.18 (38.122.127.18) 157.142 ms 158.882 ms 152.458 ms 23 207.154.0.57 (207.154.0.57) 144.913 ms 112.629 ms 112.519 ms 24 server1.ntcorp.com (207.154.13.58) 116.986 ms 120.276 ms 128.333 ms Miles On 2/12/17 8:57 PM, Mel Beckman wrote: > Miles, > > Have you tried trace routing through cellular data connections? The results you're seeing could be explained by congestion at the point of your modem, which I think is with the cox techs are implying. > > -mel via cell > >> On Feb 12, 2017, at 7:46 PM, Mel Beckman wrote: >> >> It looks like one or more circuits are down, so you're seeing asymmetrical routing over congested paths in one direction. >> >> -mel via cell >> >>> On Feb 12, 2017, at 7:14 PM, Miles Fidelman wrote: >>> >>> Hi Folks, >>> >>> I'm visiting AZ, and seeing some really really poor performance accessing some of our servers via Cox broadband. The folks at Cox technical support are useless - all they say is "well you're on a DOCSIS 2 modem." Meanwhile, everything I'm seeing is several hops upstream of the local segment - and all that Cox level2 tech support will say is "if there was a backbone problem, our backbone people would have dealt with it." >>> >>> I'm having problems reaching both our own server, and sites like google, facebook, windows update. >>> >>> Traceroutes to and from our server are illustrative - note that for most of the past week, the average ping time was 85msec. Now we're seeing this: >>> >>> From 98.177.135.186 - the public IP address on Cox's local broadband service. >>> To 107.154.13.58 (ntcorp.server - one of our servers, sitting in a Tierpoint data center, near Boston) >>> traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets >>> 1 10.128.128.1 (10.128.128.1) 199.893 ms 75.319 ms 27.295 ms >>> 2 100.127.69.178 (100.127.69.178) 38.710 ms 40.075 ms 43.598 ms >>> 3 72.215.229.22 (72.215.229.22) 39.674 ms 201.368 ms * >>> 4 lag-157.bear2.phoenix1.level3.net (4.28.82.53) 686.499 ms 1837.141 ms 16.273 ms >>> 5 ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 35.498 ms 964.377 ms * >>> 6 ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 551.760 ms 525.014 ms >>> ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 2061.191 ms >>> 7 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 847.778 ms 87.601 ms 71.504 ms >>> 8 be2965.ccr22.lax01.atlas.cogentco.com (154.54.45.1) 79.060 ms 225.647 ms >>> be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 60.306 ms >>> 9 * be2931.ccr21.phx02.atlas.cogentco.com (154.54.44.85) 2264.071 ms 185.180 ms >>> 10 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 61.208 ms >>> be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 386.149 ms 1278.868 ms >>> 11 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 384.136 ms >>> be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 2339.833 ms 615.415 ms >>> 12 be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 233.061 ms >>> be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 87.902 ms >>> be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 861.159 ms >>> 13 be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 998.858 ms >>> be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 249.930 ms * >>> 14 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 768.461 ms >>> be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.772 ms >>> be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 288.225 ms >>> 15 be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 271.736 ms 166.224 ms >>> be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 565.015 ms >>> 16 te0-4-1-7.agr22.bos01.atlas.cogentco.com (154.54.80.34) 1944.479 ms >>> te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 149.803 ms >>> te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 897.115 ms >>> 17 te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 107.207 ms >>> te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 295.881 ms 185.453 ms >>> 18 38.122.127.18 (38.122.127.18) 115.652 ms 461.168 ms 615.526 ms >>> 19 207.154.0.57 (207.154.0.57) 1871.023 ms 1987.832 ms 2165.248 ms >>> 20 server1.ntcorp.com (207.154.13.58) 587.560 ms 263.328 ms 333.542 ms >>> >>> >>> Traceroute in the reverse direction: >>> 1 207.154.13.47 (207.154.13.47) 0.000 ms 0.000 ms 0.000 ms >>> 2 * * * >>> 3 h130.207.190.173.static.ip.windstream.net (173.190.207.130) 0.000 ms 0.000 ms 0.000 ms >>> 4 xe1-2-0-0.cr01.cley01-oh.us.windstream.net (40.128.250.166) 12.000 ms 12.000 ms 12.000 ms >>> 5 et11-0-0-0.cr01.chcg01-il.us.windstream.net (40.128.248.71) 20.000 ms 20.000 ms 20.000 ms >>> 6 10gigabitethernet4-1.core1.chi1.he.NET (206.223.119.37) 72.001 ms 20.000 ms 16.000 ms >>> 7 chgobbrj01pos010100.r2.ch.cox.net (68.105.30.193) 20.000 ms 20.000 ms 20.000 ms >>> 8 chnddsrj01-ae1.0.rd.ph.cox.net (68.1.5.211) 72.001 ms 72.001 ms 72.001 ms >>> 9 * * * >>> 10 * * * >>> 11 * * * >>> >>> 30 * * * >>> >>> >>> Two things jump out at me: >>> 1. The rather large number of hops from cox to ntcorp - with high delays from several nodes in both the level3 and cogent networks. >>> 2. That there's a rather more direct path from the datacenter to cox, that shows up in the reverse direction. >>> >>> Some kind of routing or peering issue, perhaps? (And I also note the earlier string of messages regarding youtube streaming problems - that also seemed to involve cox and level3. >>> >>> Thanks for any insight (and better, for any fixes!). >>> >>> Miles Fidelman >>> >>> >>> >>> >>> -- >>> In theory, there is no difference between theory and practice. >>> In practice, there is. .... Yogi Berra >>> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From ramy.ihashish at gmail.com Mon Feb 13 04:53:48 2017 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 13 Feb 2017 06:53:48 +0200 Subject: Small-mid scale vDPI Message-ID: Good day community, Any experience based recommendations about cost effective vDPIs in small-mid scale? Thanks, Ramy From mel at beckman.org Mon Feb 13 06:36:40 2017 From: mel at beckman.org (Mel Beckman) Date: Mon, 13 Feb 2017 06:36:40 +0000 Subject: is something weird going on with cox, level3, and/or cogent In-Reply-To: References: <3ebb9b37-b8ef-10fb-17c6-1fe64da35aa4@meetinghouse.net> <330160BA-7F4B-4402-ACBE-789FAA451F54@beckman.org> Message-ID: <18DC053A-CB12-4AC9-8EB4-F3C9ED4C992C@beckman.org> It helps to follow some general guidelines to traceroute interpretation: 1. Intermediate hop time is not necessarily a measure of performance, as traceroute TTL expiration processing has low priority. 2. Time measurements areround-trip, not latency, and the bulk of the time may be incurred on the return trip. The only way to know for sure is bidirectional traceroutes. 3. Seeing reported latency in the first few hops indicates a probable issue on the local network level. In your original traceroute, latency jumps from 40ms to 200ms at 72.215.229.22, which is a Cox address. Since this is so close to you (third hop), I would apply guideline #3. All the hops after that have high latencies too, but if most of that is being injected in hop 3 then that means the problem started there. Verify that you don?t have high traffic volume on your individual Cox circuit (e.g. a backup running or something). If that?s not the case, then you?re likely seeing a Cox problem with their own internal traffic engineering. If Cox is doing weekend maintenance, some circuits may be out of service for a while. Cox is not good about passing that info down to residential customers, so you may never know what happened. A DIA business customer can usually ask about global tickets, but Cox is loathe to give that information out even then. -mel On Feb 12, 2017, at 8:27 PM, Miles Fidelman > wrote: Now isn't that interesting. 1. Verizon mobile seems to also route through level3 and cogent. 2. But.. the performance seems to be a lot better. 3. That's really odd. 1 192.168.43.1 (192.168.43.1) 2.063 ms 2.382 ms 1.913 ms 2 7.sub-66-174-33.myvzw.com (66.174.33.7) 50.676 ms 36.720 ms 41.142 ms 3 164.sub-69-83-172.myvzw.com (69.83.172.164) 39.831 ms 40.240 ms 40.190 ms 4 178.sub-69-83-173.myvzw.com (69.83.173.178) 39.851 ms 48.650 ms 30.921 ms 5 194.sub-69-83-173.myvzw.com (69.83.173.194) 49.134 ms 31.131 ms 39.946 ms 6 8.sub-69-83-162.myvzw.com (69.83.162.8) 42.841 ms 39.532 ms 40.024 ms 7 73.sub-66-174-29.myvzw.com (66.174.29.73) 44.074 ms 31.248 ms 42.199 ms 8 5-1-1.bear1.phoenix1.level3.net (4.16.142.89) 38.474 ms 39.555 ms 57.860 ms 9 ae-2-70.edge1.losangeles6.level3.net (4.69.144.80) 86.101 ms 78.856 ms ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 70.001 ms 10 ae-4-90.edge1.losangeles6.level3.net (4.69.144.208) 48.840 ms ae-2-70.edge1.losangeles6.level3.net (4.69.144.80) 71.847 ms ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 81.841 ms 11 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 70.538 ms 39.175 ms 45.213 ms 12 be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 89.463 ms 78.656 ms 72.936 ms 13 be2932.ccr22.phx02.atlas.cogentco.com (154.54.45.161) 106.896 ms 82.389 ms 87.310 ms 14 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 72.782 ms 76.034 ms 114.967 ms 15 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 87.883 ms 100.641 ms be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 117.904 ms 16 be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 144.881 ms be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 135.465 ms 110.129 ms 17 be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 93.713 ms be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 128.171 ms be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 109.207 ms 18 be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.620 ms be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 113.346 ms be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 118.301 ms 19 be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 148.778 ms 166.763 ms be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 153.433 ms 20 te0-4-1-7.agr21.bos01.atlas.cogentco.com (154.54.47.254) 143.449 ms te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 242.964 ms te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 198.678 ms 21 te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 139.454 ms te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 132.726 ms 107.254 ms 22 38.122.127.18 (38.122.127.18) 157.142 ms 158.882 ms 152.458 ms 23 207.154.0.57 (207.154.0.57) 144.913 ms 112.629 ms 112.519 ms 24 server1.ntcorp.com (207.154.13.58) 116.986 ms 120.276 ms 128.333 ms Miles On 2/12/17 8:57 PM, Mel Beckman wrote: Miles, Have you tried trace routing through cellular data connections? The results you're seeing could be explained by congestion at the point of your modem, which I think is with the cox techs are implying. -mel via cell On Feb 12, 2017, at 7:46 PM, Mel Beckman wrote: It looks like one or more circuits are down, so you're seeing asymmetrical routing over congested paths in one direction. -mel via cell On Feb 12, 2017, at 7:14 PM, Miles Fidelman wrote: Hi Folks, I'm visiting AZ, and seeing some really really poor performance accessing some of our servers via Cox broadband. The folks at Cox technical support are useless - all they say is "well you're on a DOCSIS 2 modem." Meanwhile, everything I'm seeing is several hops upstream of the local segment - and all that Cox level2 tech support will say is "if there was a backbone problem, our backbone people would have dealt with it." I'm having problems reaching both our own server, and sites like google, facebook, windows update. Traceroutes to and from our server are illustrative - note that for most of the past week, the average ping time was 85msec. Now we're seeing this: >From 98.177.135.186 - the public IP address on Cox's local broadband service. To 107.154.13.58 (ntcorp.server - one of our servers, sitting in a Tierpoint data center, near Boston) traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets 1 10.128.128.1 (10.128.128.1) 199.893 ms 75.319 ms 27.295 ms 2 100.127.69.178 (100.127.69.178) 38.710 ms 40.075 ms 43.598 ms 3 72.215.229.22 (72.215.229.22) 39.674 ms 201.368 ms * 4 lag-157.bear2.phoenix1.level3.net (4.28.82.53) 686.499 ms 1837.141 ms 16.273 ms 5 ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 35.498 ms 964.377 ms * 6 ae-3-80.edge1.losangeles6.level3.net (4.69.144.144) 551.760 ms 525.014 ms ae-1-60.edge1.losangeles6.level3.net (4.69.144.16) 2061.191 ms 7 be3036.ccr41.lax04.atlas.cogentco.com (154.54.14.129) 847.778 ms 87.601 ms 71.504 ms 8 be2965.ccr22.lax01.atlas.cogentco.com (154.54.45.1) 79.060 ms 225.647 ms be2964.ccr21.lax01.atlas.cogentco.com (154.54.44.77) 60.306 ms 9 * be2931.ccr21.phx02.atlas.cogentco.com (154.54.44.85) 2264.071 ms 185.180 ms 10 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) 61.208 ms be2930.ccr21.elp01.atlas.cogentco.com (154.54.42.78) 386.149 ms 1278.868 ms 11 be2928.ccr22.iah01.atlas.cogentco.com (154.54.30.161) 384.136 ms be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) 2339.833 ms 615.415 ms 12 be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 233.061 ms be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) 87.902 ms be2690.ccr42.atl01.atlas.cogentco.com (154.54.28.129) 861.159 ms 13 be2113.ccr42.dca01.atlas.cogentco.com (154.54.24.221) 998.858 ms be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) 249.930 ms * 14 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 768.461 ms be2806.ccr41.jfk02.atlas.cogentco.com (154.54.40.105) 136.772 ms be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) 288.225 ms 15 be2094.ccr21.bos01.atlas.cogentco.com (154.54.30.14) 271.736 ms 166.224 ms be2096.ccr22.bos01.atlas.cogentco.com (154.54.30.42) 565.015 ms 16 te0-4-1-7.agr22.bos01.atlas.cogentco.com (154.54.80.34) 1944.479 ms te0-4-1-6.agr22.bos01.atlas.cogentco.com (154.54.80.10) 149.803 ms te0-4-1-6.agr21.bos01.atlas.cogentco.com (154.54.47.230) 897.115 ms 17 te0-0-2-0.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.82) 107.207 ms te0-0-2-1.nr11.b000254-0.bos01.atlas.cogentco.com (154.24.9.78) 295.881 ms 185.453 ms 18 38.122.127.18 (38.122.127.18) 115.652 ms 461.168 ms 615.526 ms 19 207.154.0.57 (207.154.0.57) 1871.023 ms 1987.832 ms 2165.248 ms 20 server1.ntcorp.com (207.154.13.58) 587.560 ms 263.328 ms 333.542 ms Traceroute in the reverse direction: 1 207.154.13.47 (207.154.13.47) 0.000 ms 0.000 ms 0.000 ms 2 * * * 3 h130.207.190.173.static.ip.windstream.net (173.190.207.130) 0.000 ms 0.000 ms 0.000 ms 4 xe1-2-0-0.cr01.cley01-oh.us.windstream.net (40.128.250.166) 12.000 ms 12.000 ms 12.000 ms 5 et11-0-0-0.cr01.chcg01-il.us.windstream.net (40.128.248.71) 20.000 ms 20.000 ms 20.000 ms 6 10gigabitethernet4-1.core1.chi1.he.NET (206.223.119.37) 72.001 ms 20.000 ms 16.000 ms 7 chgobbrj01pos010100.r2.ch.cox.net (68.105.30.193) 20.000 ms 20.000 ms 20.000 ms 8 chnddsrj01-ae1.0.rd.ph.cox.net (68.1.5.211) 72.001 ms 72.001 ms 72.001 ms 9 * * * 10 * * * 11 * * * 30 * * * Two things jump out at me: 1. The rather large number of hops from cox to ntcorp - with high delays from several nodes in both the level3 and cogent networks. 2. That there's a rather more direct path from the datacenter to cox, that shows up in the reverse direction. Some kind of routing or peering issue, perhaps? (And I also note the earlier string of messages regarding youtube streaming problems - that also seemed to involve cox and level3. Thanks for any insight (and better, for any fixes!). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From dave at temk.in Mon Feb 13 19:51:27 2017 From: dave at temk.in (Dave Temkin) Date: Mon, 13 Feb 2017 14:51:27 -0500 Subject: [NANOG-announce] 2017 Program Committee appointments Message-ID: Greetings NANOG Colleagues, The Board has completed the Program Committee selection process. This year, 27 members submitted their candidacies for 9 available positions. We want to thank each and every one of them for considering this important service to our community and encourage them to try for the next selection cycle. We are pleased to announce the two-year term appointment of the following to the Program Committee: L Sean Kennedy, Dani Roisman, Allison Feese-Strickland, Krassimir Tzvetanov, Ryan Woolley, Christina Chu, Brad Raymo, Greg Hankins, and Adam Davenport We also want to thank and recognize the contribution of Philippe Couture, Paul Ebersman, and John Van Oppen for their service on the Program Committee. The Board of Directors also created an Ad-Hoc Committee for NANOG On The Road meetings. We are pleased to announce the two-year term appointment of the following to the Ad-Hoc NANOG On The Road Committee: Chair: Steve Feldman Additional Members: Mohit Lad, Jeff Ringwelski, and Ryan Landry In the coming weeks, the new Program Committee will hold its first meeting and select a Chair and a Vice-Chair. Sincerely, Dave Temkin Chair, NANOG Board of Directors -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jfmezei_nanog at vaxination.ca Mon Feb 13 21:53:53 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 13 Feb 2017 16:53:53 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> Message-ID: <58A22AF1.6030409@vaxination.ca> Cogent seems to have been very very silent on the issue. Could this be because they got some police/NSA/FBI letter requiring confindentiality and requiring Cogent to snoop on all traffic to 104.31.19.30 , and along with agreeing to comply, blocked all the requested traffic which means that their cooperation yield logs of what IP has made a SYN to 104.31.18.30 but since that SYN went nowhere, contains no other information, so the agency gets its logs as requested, but with no actionable information in them ? That would explain the block AND Cogent being coy/silent on issue. This could be a "protect users" move even though on the surface Cogent appears to be the bad guy. The other question is whether other major backbone providers got the same order and complied without telling ayone nor taking any action to block. In my case, the ISP I used has local peering with Cloudfare, so not affected. Not sure what percentage of users have local transit-free connections. From morrowc.lists at gmail.com Mon Feb 13 22:24:25 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 13 Feb 2017 17:24:25 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <58A22AF1.6030409@vaxination.ca> References: <20170210041824.GB16526@sizone.org> <5877693e-38fd-8307-81c8-63412bcaa352@2mbit.com> <1913971261.3711.1486751984247.JavaMail.mhammett@ThunderFuck> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> Message-ID: On Mon, Feb 13, 2017 at 4:53 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > > > Cogent seems to have been very very silent on the issue. > > why would they say anything at all? it's blatantly clear what's happened, right? "lea order to block access" no explanation necessary. > Could this be because they got some police/NSA/FBI letter requiring > confindentiality and requiring Cogent to snoop on all traffic to > unclear why you think snooping is happening? packets dont' return, nothing to sniff... this is just a blackhole. > 104.31.19.30 , and along with agreeing to comply, blocked all the > requested traffic which means that their cooperation yield logs of what > IP has made a SYN to 104.31.18.30 but since that SYN went nowhere, > my guess is that: "all of the internet" is syn'ing to that IP, because "all of the internet" syns to all of my ips... scanning is always happening. > contains no other information, so the agency gets its logs as requested, > but with no actionable information in them ? > > you are pushing for a conspiracy where none must exist. > That would explain the block AND Cogent being coy/silent on issue. > > they are not coy, the data is available. > This could be a "protect users" move even though on the surface Cogent > appears to be the bad guy. > > The other question is whether other major backbone providers got the > same order and complied without telling ayone nor taking any action to > block. > > In my case, the ISP I used has local peering with Cloudfare, so not > affected. Not sure what percentage of users have local transit-free > connections. > > > From swanjonson at gmail.com Tue Feb 14 02:56:39 2017 From: swanjonson at gmail.com (Jon Swanson) Date: Mon, 13 Feb 2017 21:56:39 -0500 Subject: Comcast issue in Massachusetts Message-ID: Does anyone have insight to the issue Comcast is having in Eastern Massachusetts? I am being told residents are experience Internet and TV outages. But cannot find anything on what the issue is. thank you in advance. email directly if appropriate. Thank you, -Jon From brad at shub-internet.org Fri Feb 10 20:34:35 2017 From: brad at shub-internet.org (Brad Knowles) Date: Fri, 10 Feb 2017 14:34:35 -0600 Subject: Gmail or GAFYD SREs on the list? Message-ID: Folks, Do we have any SREs from the Gmail or Google Apps For Your Domain teams on the list? I?m helping to support some domains related to the Network Time Foundation and NTP.org, and we?re having some problems with IPv6 connectivity to them. Thanks! -- Brad Knowles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP using GPGMail URL: From astephens at ptera.com Mon Feb 13 18:49:02 2017 From: astephens at ptera.com (Art Stephens) Date: Mon, 13 Feb 2017 10:49:02 -0800 Subject: Web/Streaming issues Message-ID: Been getting complaints from customers about web services such Netflix, Youtube, Facebook and Snapchat either slow to load or not loading at all and yet speed tests seem to be ok. We keep checking our network equipment for issues and not able to identify any as of yet We have two 10gig connections to Wolfe and Zayo. Are others seeing similar issues? -- Arthur Stephens Senior Networking Technician Ptera Inc. PO Box 135 24001 E Mission Suite 50 Liberty Lake, WA 99019 509-927-7837 ptera.com | facebook.com/PteraInc | twitter.com/Ptera ----------------------------------------------------------------------------- "This message may contain confidential and/or propriety information, and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company." From patrickboyle at protonmail.com Mon Feb 13 22:19:25 2017 From: patrickboyle at protonmail.com (Patrick Boyle) Date: Mon, 13 Feb 2017 17:19:25 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <58A22AF1.6030409@vaxination.ca> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> Message-ID: Even more concerning, on the surface it looks like there could be some cooperation by Cloudflare. If you look at the list of domains that contain an A record for that IP, it's almost all torrent sites and mirrors. Could they have placed all these domains behind that IP for a purpose like this? http://bgp.he.net/ip/104.31.18.30#_dns -------- Original Message -------- Subject: Re: backbones filtering unsanctioned sites Local Time: February 13, 2017 2:53 PM UTC Time: February 13, 2017 9:53 PM From: jfmezei_nanog at vaxination.ca To: nanog at nanog.org Cogent seems to have been very very silent on the issue. Could this be because they got some police/NSA/FBI letter requiring confindentiality and requiring Cogent to snoop on all traffic to 104.31.19.30 , and along with agreeing to comply, blocked all the requested traffic which means that their cooperation yield logs of what IP has made a SYN to 104.31.18.30 but since that SYN went nowhere, contains no other information, so the agency gets its logs as requested, but with no actionable information in them ? That would explain the block AND Cogent being coy/silent on issue. This could be a "protect users" move even though on the surface Cogent appears to be the bad guy. The other question is whether other major backbone providers got the same order and complied without telling ayone nor taking any action to block. In my case, the ISP I used has local peering with Cloudfare, so not affected. Not sure what percentage of users have local transit-free connections. From niels=nanog at bakker.net Tue Feb 14 13:25:07 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 14 Feb 2017 14:25:07 +0100 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> Message-ID: <20170214132507.GB86663@excession.tpb.net> * nanog at nanog.org (Patrick Boyle via NANOG) [Tue 14 Feb 2017, 14:16 CET]: >Even more concerning, on the surface it looks like there could be >some cooperation by Cloudflare. If you look at the list of domains >that contain an A record for that IP, it's almost all torrent sites >and mirrors. Could they have placed all these domains behind that IP >for a purpose like this? Why wouldn't they try to limit collateral damage by censorious governments? Are you suggesting they instead hold their other customers hostage? -- Niels. From jared at puck.nether.net Tue Feb 14 13:27:25 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Feb 2017 08:27:25 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> Message-ID: <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> So risk avoidance on the part of the 100k other sites hosted by CF is now a conspiracy? I'm surprised it took this many years for something like this to happen. Wonder which LE in which country... Either way seems nothing too suspicious is going on here. Jared Mauch > On Feb 13, 2017, at 5:19 PM, Patrick Boyle via NANOG wrote: > > Even more concerning, on the surface it looks like there could be some cooperation by Cloudflare. If you look at the list of domains that contain an A record for that IP, it's almost all torrent sites and mirrors. Could they have placed all these domains behind that IP for a purpose like this? From morrowc.lists at gmail.com Tue Feb 14 14:50:04 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 14 Feb 2017 09:50:04 -0500 Subject: Web/Streaming issues In-Reply-To: References: Message-ID: On Mon, Feb 13, 2017 at 1:49 PM, Art Stephens wrote: > Been getting complaints from customers about web services such Netflix, > Youtube, Facebook and Snapchat either slow to load or not loading at all > and yet speed tests seem to be ok. > > speed tests aren't necessarily related at all with (at least) youtube and netflix... you may have constrained pipes to the endpoints those services expose to your users, which are different from the endpoints used/exposed to them via speedtest(s). From jfmezei_nanog at vaxination.ca Tue Feb 14 18:10:59 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 14 Feb 2017 13:10:59 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> Message-ID: <58A34833.6060404@vaxination.ca> On 2017-02-14 08:27, Jared Mauch wrote: > So risk avoidance on the part of the 100k other sites hosted by CF is now a conspiracy? Cogent is a backbone network that is international in scope. When China tells a network to block the BBC that block happens only in China. If the USA wants to be like China and start blocking web sites it doesn't like, then it should only affect traffic in the USA. Google is a content company. Removing a company from its search results is a content issue, not a telecom issue. Cogent blocking an IP is a telecom issue and at least in canada should this be brought up at CRTC, would raise a Section 36 violation. And if transit providers start to block content, especially if they do not warn their ISP customers (so thei can warn their retail customers), then this is really not correct. In Canada, the supreme court has ruled, from different slants all reaching tghe conclusion that a neutral carrier is not responsible for the content that travels through its pipes. The second that carrier starts to exert control over content, it loses that immunity. Cogent blocking content affects traffic outside of the USA. From morrowc.lists at gmail.com Tue Feb 14 18:19:41 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 14 Feb 2017 13:19:41 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <58A34833.6060404@vaxination.ca> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <58A34833.6060404@vaxination.ca> Message-ID: On Tue, Feb 14, 2017 at 1:10 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 2017-02-14 08:27, Jared Mauch wrote: > > So risk avoidance on the part of the 100k other sites hosted by CF is > now a conspiracy? > > > Cogent is a backbone network that is international in scope. When China > tells a network to block the BBC that block happens only in China. > > 'when possible' (also, PRC is a special case...) you might make the analogy here to the singaporian 'block these 100 objectionable sites' law (since repealed I believe) though. > If the USA wants to be like China and start blocking web sites it > doesn't like, then it should only affect traffic in the USA. > > yes, because of course the networks in question here are built around national borders... and of course also on internal (to the nation) boundaries.. and of course even more granularly on the internal, internal national boundaries (country -> state -> county -. city -> burrough -> apt-building -> floor - door -> room -> person -> device clearly cogent did this as well) > Google is a content company. Removing a company from its search results > is a content issue, not a telecom issue. > > Cogent blocking an IP is a telecom issue and at least in canada should > this be brought up at CRTC, would raise a Section 36 violation. > > excellent, goodluck fellow traveler. > And if transit providers start to block content, especially if they do > not warn their ISP customers (so thei can warn their retail customers), > then this is really not correct. > > sure, but... what about dhs/ice revocation of domains in com/net/org/etc? :) > > In Canada, the supreme court has ruled, from different slants all > reaching tghe conclusion that a neutral carrier is not responsible for > the content that travels through its pipes. The second that carrier > starts to exert control over content, it loses that immunity. > > good thing cogent isn't a canadian company I suppose? > Cogent blocking content affects traffic outside of the USA. > it sure does, you might have luck bringing this up with your equivalent to the US State Department, no? From math at sizone.org Tue Feb 14 18:45:38 2017 From: math at sizone.org (Ken Chase) Date: Tue, 14 Feb 2017 13:45:38 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: References: <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <58A34833.6060404@vaxination.ca> Message-ID: <20170214184538.GU11223@sizone.org> They exist: http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=26878307 http://canadabizdb.com/company/3264874/cogent-canada-inc http://www.contracts-contrats.hc-sc.gc.ca/cfob/mssid/contractdisc.nsf/WEBbypurpose/A35BA8F8DB21C5E98525787E0066931A?OpenDocument&lang=eng& http://listings.ftb-companies-ca.com/l/112540553/Cogent-Canada-Inc-in-Toronto-ON My cogent invoice: Cogent Canada, Inc. P.O.Box 46067 Postal Station A Toronto, Ontario M5W 4K9 [ Dont visit the Cogent Canada facebook page. Not quite the same industry. Or the @CogentCanada twitter feed. (Something about semen vouchers.) ] Anyway, they exist as a Canadian entity (and have even made submissions to the CRTC bitching about rulings favouring Bell), so they're certainly operating in Canada. Anyone wanna file a complaint to the CCTS in Canada? https://www.ccts-cprst.ca/ /kc On Tue, Feb 14, 2017 at 01:19:41PM -0500, Christopher Morrow said: >On Tue, Feb 14, 2017 at 1:10 PM, Jean-Francois Mezei < >jfmezei_nanog at vaxination.ca> wrote: > >> On 2017-02-14 08:27, Jared Mauch wrote: >> > So risk avoidance on the part of the 100k other sites hosted by CF is >> now a conspiracy? >> >> >> Cogent is a backbone network that is international in scope. When China >> tells a network to block the BBC that block happens only in China. >> >> >'when possible' (also, PRC is a special case...) > >you might make the analogy here to the singaporian 'block these 100 >objectionable sites' law (since repealed I believe) though. > > >> If the USA wants to be like China and start blocking web sites it >> doesn't like, then it should only affect traffic in the USA. >> >> >yes, because of course the networks in question here are built around >national borders... and of course also on internal (to the nation) >boundaries.. and of course even more granularly on the internal, internal >national boundaries (country -> state -> county -. city -> burrough -> >apt-building -> floor - door -> room -> person -> device clearly cogent did >this as well) > > >> Google is a content company. Removing a company from its search results >> is a content issue, not a telecom issue. >> >> Cogent blocking an IP is a telecom issue and at least in canada should >> this be brought up at CRTC, would raise a Section 36 violation. >> >> >excellent, goodluck fellow traveler. > > >> And if transit providers start to block content, especially if they do >> not warn their ISP customers (so thei can warn their retail customers), >> then this is really not correct. >> >> >sure, but... > >what about dhs/ice revocation of domains in com/net/org/etc? :) > > >> >> In Canada, the supreme court has ruled, from different slants all >> reaching tghe conclusion that a neutral carrier is not responsible for >> the content that travels through its pipes. The second that carrier >> starts to exert control over content, it loses that immunity. >> >> >good thing cogent isn't a canadian company I suppose? > > >> Cogent blocking content affects traffic outside of the USA. >> > > >it sure does, you might have luck bringing this up with your equivalent to >the US State Department, no? Ken Chase - math at sizone.org Guelph/Toronto Canada From alejandroacostaalamo at gmail.com Tue Feb 14 18:56:51 2017 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Tue, 14 Feb 2017 15:56:51 -0300 Subject: Looking for AS 263686 contact Message-ID: <749afd06-41da-e529-da0c-ecc982da0921@gmail.com> Hello, If anybody from AS 263686 please contact me off-list. Thanks, Alejandro, From John_Brzozowski at comcast.com Wed Feb 15 00:57:58 2017 From: John_Brzozowski at comcast.com (Brzozowski, John) Date: Wed, 15 Feb 2017 00:57:58 +0000 Subject: SMC D3G CCR IPv6 support for Comcast BCI customers Message-ID: <5F1DD580-DEB6-4BE6-9382-C35D19F9A7BD@cable.comcast.com> Folks, I meant to send this sooner, hopefully better late than never. We found a bug in the SMC D3G CCR that was specific to IPv6. We tried for many months (practically years to get it fixed properly) with no success. As such we have to roll back IPv6 support for the same. See the link below: http://forums.businesshelp.comcast.com/t5/IPV6/IPv6-Firmware-Rollback-on-SMCD3GCCR/m-p/31280#U31280 If you have an SMC D3G CCR and require IPv6 support please send me unicast email at work (this address). Use the forum messenger or contact me directly regarding a device swap for a model that continues to supports IPv6. Feel free to ask questions on list that you feel others will benefit from, I will answer them. Otherwise please use the forum link above. John +1-484-962-0060 From 7riw77 at gmail.com Wed Feb 15 03:35:19 2017 From: 7riw77 at gmail.com (Russ White) Date: Tue, 14 Feb 2017 22:35:19 -0500 Subject: gmail contact? Message-ID: <000201d2873c$88793cc0$996bb640$@gmail.com> Y'all -- Who would I talk to about a gmail server that's apparently on one of the various sorbs lists? Ping me on my personal email -- russ at riw.us. :-) Russ From kyle at neocities.org Thu Feb 16 08:02:57 2017 From: kyle at neocities.org (Kyle Drake) Date: Thu, 16 Feb 2017 08:02:57 +0000 Subject: backbones filtering unsanctioned sites In-Reply-To: <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> Message-ID: <0101015a45f21333-f2fb04a4-9764-4a3b-ac71-2b180a99cc47-000000@us-west-2.amazonses.com> If it's been decided that BGP communities will now be used for purposes other than internet traffic control, then perhaps Cloudflare would also be willing to put the hundreds of DDoS-attack-for-hire services they protect on a single IP so we can blackhole those as well? At least then we can use BGP communities to fight against internet censorship instead of engaging in it. https://www.google.com/search?q=ddos+booter On Tue, Feb 14, 2017 at 5:27 AM, Jared Mauch wrote: > So risk avoidance on the part of the 100k other sites hosted by CF is now > a conspiracy? > > I'm surprised it took this many years for something like this to happen. > Wonder which LE in which country... > > Either way seems nothing too suspicious is going on here. > > Jared Mauch > > > On Feb 13, 2017, at 5:19 PM, Patrick Boyle via NANOG > wrote: > > > > Even more concerning, on the surface it looks like there could be some > cooperation by Cloudflare. If you look at the list of domains that contain > an A record for that IP, it's almost all torrent sites and mirrors. Could > they have placed all these domains behind that IP for a purpose like this? > > From andrew at paolucci.ca Tue Feb 14 18:35:42 2017 From: andrew at paolucci.ca (Andrew Paolucci) Date: Tue, 14 Feb 2017 13:35:42 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <58A34833.6060404@vaxination.ca> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <58A34833.6060404@vaxination.ca> Message-ID: Can anyone with a Cogent connection in Canada verify that they are impacted as well? Regards, Andrew Paolucci -------- Original Message -------- Subject: Re: backbones filtering unsanctioned sites Local Time: February 14, 2017 6:10 PM UTC Time: February 14, 2017 6:10 PM From: jfmezei_nanog at vaxination.ca To: nanog at nanog.org On 2017-02-14 08:27, Jared Mauch wrote: > So risk avoidance on the part of the 100k other sites hosted by CF is now a conspiracy? Cogent is a backbone network that is international in scope. When China tells a network to block the BBC that block happens only in China. If the USA wants to be like China and start blocking web sites it doesn't like, then it should only affect traffic in the USA. Google is a content company. Removing a company from its search results is a content issue, not a telecom issue. Cogent blocking an IP is a telecom issue and at least in canada should this be brought up at CRTC, would raise a Section 36 violation. And if transit providers start to block content, especially if they do not warn their ISP customers (so thei can warn their retail customers), then this is really not correct. In Canada, the supreme court has ruled, from different slants all reaching tghe conclusion that a neutral carrier is not responsible for the content that travels through its pipes. The second that carrier starts to exert control over content, it loses that immunity. Cogent blocking content affects traffic outside of the USA. From lists at sadiqs.com Thu Feb 16 19:59:54 2017 From: lists at sadiqs.com (Sadiq Saif) Date: Thu, 16 Feb 2017 14:59:54 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> Message-ID: <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> On 2017-02-14 08:27, Jared Mauch wrote: > So risk avoidance on the part of the 100k other sites hosted by CF is now a conspiracy? > > I'm surprised it took this many years for something like this to happen. Wonder which LE in which country... > > Either way seems nothing too suspicious is going on here. > > Jared Mauch Looks like it was a court order issued recently in Spain. "Cogent CEO Dave Schaeffer yesterday confirmed to Ars that the company is complying with a court order issued recently in Spain." TPB was not actually the target, it was collateral. "But The Pirate Bay was not the subject of the court order, Schaeffer also confirmed." >From - https://arstechnica.com/tech-policy/2017/02/a-court-order-blocked-pirate-sites-that-werent-supposed-to-be-blocked/ -- Sadiq Saif https://sadiqsaif.ca From jfmezei_nanog at vaxination.ca Thu Feb 16 20:52:54 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 16 Feb 2017 15:52:54 -0500 Subject: backbones filtering unsanctioned sites In-Reply-To: <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> Message-ID: <58A61126.6000209@vaxination.ca> On 2017-02-16 14:59, Sadiq Saif wrote: > From - > https://arstechnica.com/tech-policy/2017/02/a-court-order-blocked-pirate-sites-that-werent-supposed-to-be-blocked/ Many thanks. pardon my ignorance here, but question: For an outfit such as Cogent which acts not only as a transit provider, but also edge provider to large end users, can it easily implement such a court order to block only edge interfaces and not to its transit infrastructure? (aka: propagate null routes for 104.31.19.30 only to interfaces that lead to end users, but leave core/GBP aspects without the block.) Or is BGP and any internal routing protocols so intermingled that it becomes hard to manage such blocks ? The difficulty for network to block traffic becomes an important argument when trying to convince governments that blocking should not be done. (ex: Qu?bec government wanting to block access to gambling sites except its own). From baldur.norddahl at gmail.com Fri Feb 17 00:06:52 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 17 Feb 2017 01:06:52 +0100 Subject: backbones filtering unsanctioned sites In-Reply-To: <58A61126.6000209@vaxination.ca> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> <58A61126.6000209@vaxination.ca> Message-ID: <77dda135-b451-9f52-18be-8b5b713090e8@gmail.com> For transit maybe Cogent should have dropped the route, so they did not advertize a route to peers that included null routed parts. Den 16/02/2017 kl. 21.52 skrev Jean-Francois Mezei: > On 2017-02-16 14:59, Sadiq Saif wrote: > >> From - >> https://arstechnica.com/tech-policy/2017/02/a-court-order-blocked-pirate-sites-that-werent-supposed-to-be-blocked/ > > Many thanks. > > pardon my ignorance here, but question: > > For an outfit such as Cogent which acts not only as a transit provider, > but also edge provider to large end users, can it easily implement such > a court order to block only edge interfaces and not to its transit > infrastructure? > > (aka: propagate null routes for 104.31.19.30 only to interfaces that > lead to end users, but leave core/GBP aspects without the block.) > > Or is BGP and any internal routing protocols so intermingled that it > becomes hard to manage such blocks ? > > The difficulty for network to block traffic becomes an important > argument when trying to convince governments that blocking should not be > done. (ex: Qu?bec government wanting to block access to gambling sites > except its own). > From todd.crane at n5tech.com Fri Feb 17 04:04:24 2017 From: todd.crane at n5tech.com (Todd Crane) Date: Thu, 16 Feb 2017 21:04:24 -0700 Subject: backbones filtering unsanctioned sites In-Reply-To: <77dda135-b451-9f52-18be-8b5b713090e8@gmail.com> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> <58A61126.6000209@vaxination.ca> <77dda135-b451-9f52-18be-8b5b713090e8@gmail.com> Message-ID: <153FC54F-1180-40C1-A7C0-7D1C9F870D90@n5tech.com> I am not familiar with Cogent?s architecture but why couldn?t they just null route the IP address at their edge routers from within Spain? I am not a lawyer but from what I understand, since the Spanish government has zero say on what goes on outside of their borders, a court order that may or may not have been issued is not a legal defense for blocking access around the world. Furthermore, I think that this should be viewed as a malicious act and not as unfortunate consequence or a breach of contract. As far as letting them off the hook because they only offer a partial view of the route table, our contract never anything about partial views. Force majeure only applies to thing they have no control over. For that to apply, the court order, if that?s what it was, would have to apply to every jurisdiction in which they operate. I am also skeptical of this court order, seeing as Ars was unable to independently verify. Disclaimer: We used to have Cogent transit and it was the single worst experience I have been through in my professional life. Every time I had to deal with them, it felt more like what I would dealing with the mobs that control much of Russia. Therefore, I am very hesitant to assume even the slightest bit of good faith towards them. > On Feb 16, 2017, at 5:06 PM, Baldur Norddahl wrote: > > For transit maybe Cogent should have dropped the route, so they did not advertize a route to peers that included null routed parts. > > Den 16/02/2017 kl. 21.52 skrev Jean-Francois Mezei: >> On 2017-02-16 14:59, Sadiq Saif wrote: >> >>> From - >>> https://arstechnica.com/tech-policy/2017/02/a-court-order-blocked-pirate-sites-that-werent-supposed-to-be-blocked/ >> >> Many thanks. >> >> pardon my ignorance here, but question: >> >> For an outfit such as Cogent which acts not only as a transit provider, >> but also edge provider to large end users, can it easily implement such >> a court order to block only edge interfaces and not to its transit >> infrastructure? >> >> (aka: propagate null routes for 104.31.19.30 only to interfaces that >> lead to end users, but leave core/GBP aspects without the block.) >> >> Or is BGP and any internal routing protocols so intermingled that it >> becomes hard to manage such blocks ? >> >> The difficulty for network to block traffic becomes an important >> argument when trying to convince governments that blocking should not be >> done. (ex: Qu?bec government wanting to block access to gambling sites >> except its own). >> > From fw at deneb.enyo.de Fri Feb 17 08:19:32 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 17 Feb 2017 09:19:32 +0100 Subject: backbones filtering unsanctioned sites In-Reply-To: (Andrew Paolucci's message of "Tue, 14 Feb 2017 13:35:42 -0500") References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <58A34833.6060404@vaxination.ca> Message-ID: <87bmu1kz57.fsf@mid.deneb.enyo.de> * Andrew Paolucci: > Can anyone with a Cogent connection in Canada verify that they are > impacted as well? I think it's global. I tried sites in Canada and Germany, and the traces look like deliberate blocking of /32s. I don't have a BGP view for these sites, though. Why wouldn't it be global? If someone forces their hands, ISPs aren't shipping companies and can pick and choose where they comply. From fw at deneb.enyo.de Fri Feb 17 08:21:51 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 17 Feb 2017 09:21:51 +0100 Subject: backbones filtering unsanctioned sites In-Reply-To: <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> (Jared Mauch's message of "Tue, 14 Feb 2017 08:27:25 -0500") References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> Message-ID: <877f4pkz1c.fsf@mid.deneb.enyo.de> * Jared Mauch: > So risk avoidance on the part of the 100k other sites hosted by CF is > now a conspiracy? Conspiracy is perhaps a bit too strong, but I would be annoyed if someone took my business, but then deliberately undermined the service they provide. Of course, if it's all part of the agreement, it's fine, but if it is not, it certainly looks like a crass net neutrality violation. From fw at deneb.enyo.de Fri Feb 17 08:29:04 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 17 Feb 2017 09:29:04 +0100 Subject: backbones filtering unsanctioned sites In-Reply-To: <153FC54F-1180-40C1-A7C0-7D1C9F870D90@n5tech.com> (Todd Crane's message of "Thu, 16 Feb 2017 21:04:24 -0700") References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> <58A61126.6000209@vaxination.ca> <77dda135-b451-9f52-18be-8b5b713090e8@gmail.com> <153FC54F-1180-40C1-A7C0-7D1C9F870D90@n5tech.com> Message-ID: <8737fdkypb.fsf@mid.deneb.enyo.de> * Todd Crane: > I am not familiar with Cogent?s architecture but why couldn?t they > just null route the IP address at their edge routers from within > Spain? I am not a lawyer but from what I understand, since the Spanish > government has zero say on what goes on outside of their borders, Of course they do, see the arrest of Augusto Pinochet. Due to the nature of mass copyright violation, it is likely that these sites violate the rights of Spanish copyright holders, and if such a violated party obtains a court order against an ISP, I see no reason why the violations should go on everywhere except Spain. From tim at pelican.org Fri Feb 17 09:56:13 2017 From: tim at pelican.org (tim at pelican.org) Date: Fri, 17 Feb 2017 09:56:13 -0000 (GMT) Subject: backbones filtering unsanctioned sites In-Reply-To: <8737fdkypb.fsf@mid.deneb.enyo.de> References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> <58A61126.6000209@vaxination.ca> <77dda135-b451-9f52-18be-8b5b713090e8@gmail.com> <153FC54F-1180-40C1-A7C0-7D1C9F870D90@n5tech.com> <8737fdkypb.fsf@mid.deneb.enyo.de> Message-ID: <1487325373.2195920@apps.rackspace.com> On Friday, 17 February, 2017 08:29, "Florian Weimer" said: > Of course they do, see the arrest of Augusto Pinochet. Universal Jurisdiction is supposed to cover the likes of war crimes, torture, extrajudicial executions and genocide, that are generally agreed to be crimes against humanity as a whole, regardless of where they take place. Much as the copyright cartel would like to put any (perceived) loss of revenue into the same bracket, are you *really* advocating that copyright infringement belongs in that list? > Due to the nature of mass copyright violation, it is likely that these > sites violate the rights of Spanish copyright holders, and if such a > violated party obtains a court order against an ISP, I see no reason > why the violations should go on everywhere except Spain. The action isn't against the people infringing copyright, the sites (arguably) aiding them in infringing copyright, or even the company providing hosting services to those sites. It is, if the situation is being reported correctly, forcing a connectivity provider to block access to some elements of the hosting services *worldwide* based on the fact that it operates in one country. In my view, both far too many steps removed from the offence, and, more importantly, overly-broad in impact. Do you think the Chinese government should be able to force any voice provider operating in China to block any of their customers, anywhere in the world, from talking about Taiwan as an independent country? Do you think the Iranian government should be able to force any mobile phone company operating in Iran to implement a worldwide ban of Pokemon Go? If the answer to either of those questions is "no", can you explain why the jurisdiction should be limited in these cases, but not for Spanish copyright holders? (Note that I'm not talking about the "right" or "wrong" of those decisions within their respective jurisdiction, that's not relevant to where their jurisdiction extends.) Regards, Tim. From fw at deneb.enyo.de Fri Feb 17 13:50:47 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 17 Feb 2017 14:50:47 +0100 Subject: backbones filtering unsanctioned sites In-Reply-To: <1487325373.2195920@apps.rackspace.com> (tim@pelican.org's message of "Fri, 17 Feb 2017 09:56:13 -0000 (GMT)") References: <20170210041824.GB16526@sizone.org> <5d2fca20-8025-ce52-ec7d-0870ff3172b6@unlimitednet.us> <58A22AF1.6030409@vaxination.ca> <3DA078BE-34CF-4E67-A72F-B5FEE33C557A@puck.nether.net> <51fb8d0c-acc3-bc6d-9beb-21dbda95f2da@sadiqs.com> <58A61126.6000209@vaxination.ca> <77dda135-b451-9f52-18be-8b5b713090e8@gmail.com> <153FC54F-1180-40C1-A7C0-7D1C9F870D90@n5tech.com> <8737fdkypb.fsf@mid.deneb.enyo.de> <1487325373.2195920@apps.rackspace.com> Message-ID: <87zihlhqo8.fsf@mid.deneb.enyo.de> * > On Friday, 17 February, 2017 08:29, "Florian Weimer" said: > >> Of course they do, see the arrest of Augusto Pinochet. > > Universal Jurisdiction is supposed to cover the likes of war crimes, > torture, extrajudicial executions and genocide, that are generally > agreed to be crimes against humanity as a whole, regardless of where > they take place. Much as the copyright cartel would like to put any > (perceived) loss of revenue into the same bracket, are you *really* > advocating that copyright infringement belongs in that list? I think the Spanish prosecutor claimed at the time that crimes were committed against Spaniards, too. So it's not quite a case of absolute universal jurisdiction. Assuming that Spanish copyright holders sought the court order, the situation isn't too different. >> Due to the nature of mass copyright violation, it is likely that these >> sites violate the rights of Spanish copyright holders, and if such a >> violated party obtains a court order against an ISP, I see no reason >> why the violations should go on everywhere except Spain. > > The action isn't against the people infringing copyright, the sites > (arguably) aiding them in infringing copyright, or even the company > providing hosting services to those sites. It is, if the situation is > being reported correctly, forcing a connectivity provider to block > access to some elements of the hosting services *worldwide* based on > the fact that it operates in one country. In my view, both far too > many steps removed from the offence, and, more importantly, > overly-broad in impact. There can be some debate whether a transit ISP should be subject to such an injunction, rather than a party closer to the source. But I don't see why if a Spanish court determines that Spanish law requires compliance by the ISP, the blocking order should be restricted to Spain. The rights are violated everywhere, after all. Sometimes, global compliance is just a cost of doing business locally. > Do you think the Chinese government should be able to force any voice > provider operating in China to block any of their customers, anywhere > in the world, from talking about Taiwan as an independent country? > > Do you think the Iranian government should be able to force any mobile > phone company operating in Iran to implement a worldwide ban of > Pokemon Go? > > If the answer to either of those questions is "no", can you explain > why the jurisdiction should be limited in these cases, but not for > Spanish copyright holders? Iranian law appears to require permission for running nation-wide games, not games around the globe. Similarly, I doubt that Chinese law has a legal basis for demanding filtering of voice calls, but it's difficult to find confirmation for that. (I believe that a lot of service bans in China are enacted by the government upon encouragement from would-be competitors, but that does not make such bans legal according to Chinese law.) So the difference is that your hypothetical scenarios violate local laws. From math at sizone.org Fri Feb 17 15:56:23 2017 From: math at sizone.org (Ken Chase) Date: Fri, 17 Feb 2017 10:56:23 -0500 Subject: gagging *IX directors re snoop/block orders Message-ID: <20170217155623.GU15415@sizone.org> And when you go to figure out why that IP wont ping through Cogent on your exchange, and start troubleshooting but can't get any answers as to why things are bust... [ Clearly now an operational issue for NANOG. ] Purposely breaking routing and not being able to talk about why is going to set many orgs at odds with their basic operational charters. I expect that a paid service will work when it's provided, including help debugging their end. This is slightly different from a service provider, ostensibly you can go elsewhere to get service - but when you are a member of a nonprofit *IX (as we are with TorIX), things get a lot more complex. I imagine contract lawyers are going to be all over this. https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/ (their typo in the url) /kc -- Ken Chase - math at sizone.org Guelph/Toronto Canada From nanog at ics-il.net Fri Feb 17 16:03:00 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 17 Feb 2017 10:03:00 -0600 (CST) Subject: gagging *IX directors re snoop/block orders In-Reply-To: <20170217155623.GU15415@sizone.org> References: <20170217155623.GU15415@sizone.org> Message-ID: <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> I'm not sure Cogent is on any IXes? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ken Chase" To: nanog at nanog.org Sent: Friday, February 17, 2017 9:56:23 AM Subject: gagging *IX directors re snoop/block orders And when you go to figure out why that IP wont ping through Cogent on your exchange, and start troubleshooting but can't get any answers as to why things are bust... [ Clearly now an operational issue for NANOG. ] Purposely breaking routing and not being able to talk about why is going to set many orgs at odds with their basic operational charters. I expect that a paid service will work when it's provided, including help debugging their end. This is slightly different from a service provider, ostensibly you can go elsewhere to get service - but when you are a member of a nonprofit *IX (as we are with TorIX), things get a lot more complex. I imagine contract lawyers are going to be all over this. https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/ (their typo in the url) /kc -- Ken Chase - math at sizone.org Guelph/Toronto Canada From math at sizone.org Fri Feb 17 16:07:11 2017 From: math at sizone.org (Ken Chase) Date: Fri, 17 Feb 2017 11:07:11 -0500 Subject: gagging *IX directors re snoop/block orders In-Reply-To: <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> References: <20170217155623.GU15415@sizone.org> <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> Message-ID: <20170217160711.GX15415@sizone.org> Just meant it as a parallel operational example. Both situations, while legally distinct, present the same operational issues. Purposely breaking things - and then being required to keep the breakage secret - is going to mess up a whole lot of things. (How does Chinese operators handle this?) Additionally the snooping is an issue, though I can't imagine anyone depends on an IX for maintaining secrecy at a contract level :/ Today's realities. /kc On Fri, Feb 17, 2017 at 10:03:00AM -0600, Mike Hammett said: >I'm not sure Cogent is on any IXes? > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com > >----- Original Message ----- > >From: "Ken Chase" >To: nanog at nanog.org >Sent: Friday, February 17, 2017 9:56:23 AM >Subject: gagging *IX directors re snoop/block orders > >And when you go to figure out why that IP wont ping through Cogent on >your exchange, and start troubleshooting but can't get any answers >as to why things are bust... > >[ Clearly now an operational issue for NANOG. ] > >Purposely breaking routing and not being able to talk about why is going to >set many orgs at odds with their basic operational charters. I expect that >a paid service will work when it's provided, including help debugging their end. > >This is slightly different from a service provider, ostensibly you can >go elsewhere to get service - but when you are a member of a nonprofit *IX >(as we are with TorIX), things get a lot more complex. > >I imagine contract lawyers are going to be all over this. > >https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/ > >(their typo in the url) > /kc -- Ken Chase - math at sizone.org Guelph/Toronto Canada From patrick at ianai.net Fri Feb 17 16:46:59 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 17 Feb 2017 11:46:59 -0500 Subject: gagging *IX directors re snoop/block orders In-Reply-To: <20170217160711.GX15415@sizone.org> References: <20170217155623.GU15415@sizone.org> <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> <20170217160711.GX15415@sizone.org> Message-ID: There is one problem: The article is factually incorrect on multiple points. So comparing A to B when B is a fairy tale does not make much sense. The proposed constitutional changes are in the public domain. -- TTFN, patrick P.S. Full disclosure, I am a LINX director. So maybe I?m saying this to protect myself. If only you could read the proposed changes and decide for yourself. Oh, wait?. > On Feb 17, 2017, at 11:07 AM, Ken Chase wrote: > > Just meant it as a parallel operational example. Both situations, while legally > distinct, present the same operational issues. > > Purposely breaking things - and then being required to keep the breakage secret - > is going to mess up a whole lot of things. (How does Chinese operators handle this?) > > Additionally the snooping is an issue, though I can't imagine anyone depends on > an IX for maintaining secrecy at a contract level :/ Today's realities. > > /kc > > > On Fri, Feb 17, 2017 at 10:03:00AM -0600, Mike Hammett said: >> I'm not sure Cogent is on any IXes? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> ----- Original Message ----- >> >> From: "Ken Chase" >> To: nanog at nanog.org >> Sent: Friday, February 17, 2017 9:56:23 AM >> Subject: gagging *IX directors re snoop/block orders >> >> And when you go to figure out why that IP wont ping through Cogent on >> your exchange, and start troubleshooting but can't get any answers >> as to why things are bust... >> >> [ Clearly now an operational issue for NANOG. ] >> >> Purposely breaking routing and not being able to talk about why is going to >> set many orgs at odds with their basic operational charters. I expect that >> a paid service will work when it's provided, including help debugging their end. >> >> This is slightly different from a service provider, ostensibly you can >> go elsewhere to get service - but when you are a member of a nonprofit *IX >> (as we are with TorIX), things get a lot more complex. >> >> I imagine contract lawyers are going to be all over this. >> >> https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/ >> >> (their typo in the url) >> > > /kc > -- > Ken Chase - math at sizone.org Guelph/Toronto Canada From wwaites at tardis.ed.ac.uk Fri Feb 17 17:19:32 2017 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Fri, 17 Feb 2017 17:19:32 +0000 Subject: gagging *IX directors re snoop/block orders In-Reply-To: References: <20170217155623.GU15415@sizone.org> <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> <20170217160711.GX15415@sizone.org> Message-ID: > On Feb 17, 2017, at 16:46, Patrick W. Gilmore wrote: > > There is one problem: The article is factually incorrect on multiple points. It would be interesting to know what points those are, it reads mostly accurately to me. > The proposed constitutional changes are in the public domain. The main problem, though this point may have gotten lost in the very long discussion on the LINX members list, is that the reasoning and motivation for the changes was not made clear. Even when explanatory materials were belatedly provided, they weren?t especially clear. So instead of saying, "we have this new spying law in the UK and we need to rejigg the decision-making at LINX so we will be ready in case we are required to do something that must be kept secret" what was proposed to the membership was, "we have embarked on this long governance journey and this is what we have come up with as the best way to run LINX". Those are two very different propositions, especially for busy people who don?t have time to read in detail and understand all the implications. All that I suggested is that the members be properly informed so that they can make this choice with their eyes open. It is important to have this discussion in the open, and explicitly mark the transition where Internet Exchange Points re-organise themselves to accommodate spying laws and gag orders. William Waites Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh Informatics Forum 5.38, 10 Crichton St. Edinburgh, EH8 9AB, Scotland The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From brandon at rd.bbc.co.uk Fri Feb 17 17:38:25 2017 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 17 Feb 2017 17:38:25 +0000 Subject: gagging *IX directors re snoop/block orders In-Reply-To: References: <20170217155623.GU15415@sizone.org> <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> <20170217160711.GX15415@sizone.org> Message-ID: <20170217173825.GA5534@sunf10.rd.bbc.co.uk> On Fri Feb 17, 2017 at 05:19:32PM +0000, William Waites wrote: > So instead of saying, "we have this new spying law in the UK and we need > to rejigg the decision-making at LINX so we will be ready in case we are > required to do something that must be kept secret" Yes but "hey government, swivel on this" isn't going to be an effective secret weapon, they'll neutralise it before you use it > what was proposed to > the membership was, "we have embarked on this long governance journey > and this is what we have come up with as the best way to run LINX". Those > are two very different propositions A big winking eye emoji was needed brandon From cscora at apnic.net Fri Feb 17 18:02:30 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Feb 2017 04:02:30 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170217180230.6AAA7C44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 18 Feb, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 635871 Prefixes after maximum aggregation (per Origin AS): 247826 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 306367 Total ASes present in the Internet Routing Table: 56267 Prefixes per ASN: 11.30 Origin-only ASes present in the Internet Routing Table: 48704 Origin ASes announcing only one prefix: 21704 Transit ASes present in the Internet Routing Table: 7563 Transit-only ASes present in the Internet Routing Table: 208 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 71 Numnber of instances of unregistered ASNs: 72 Number of 32-bit ASNs allocated by the RIRs: 17355 Number of 32-bit ASNs visible in the Routing Table: 13507 Prefixes from 32-bit ASNs in the Routing Table: 54157 Number of bogon 32-bit ASNs visible in the Routing Table: 47 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 416 Number of addresses announced to Internet: 2833030564 Equivalent to 168 /8s, 220 /16s and 157 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 212477 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 173711 Total APNIC prefixes after maximum aggregation: 49697 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 173034 Unique aggregates announced from the APNIC address blocks: 71428 APNIC Region origin ASes present in the Internet Routing Table: 7873 APNIC Prefixes per ASN: 21.98 APNIC Region origin ASes announcing only one prefix: 2196 APNIC Region transit ASes present in the Internet Routing Table: 1127 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2702 Number of APNIC addresses announced to Internet: 760465540 Equivalent to 45 /8s, 83 /16s and 200 /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-137529 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: 193535 Total ARIN prefixes after maximum aggregation: 92922 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 195954 Unique aggregates announced from the ARIN address blocks: 89899 ARIN Region origin ASes present in the Internet Routing Table: 17786 ARIN Prefixes per ASN: 11.02 ARIN Region origin ASes announcing only one prefix: 6632 ARIN Region transit ASes present in the Internet Routing Table: 1762 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1774 Number of ARIN addresses announced to Internet: 1104178336 Equivalent to 65 /8s, 208 /16s and 108 /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-397212 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: 170001 Total RIPE prefixes after maximum aggregation: 83919 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 165322 Unique aggregates announced from the RIPE address blocks: 99924 RIPE Region origin ASes present in the Internet Routing Table: 23702 RIPE Prefixes per ASN: 6.98 RIPE Region origin ASes announcing only one prefix: 10974 RIPE Region transit ASes present in the Internet Routing Table: 3356 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5566 Number of RIPE addresses announced to Internet: 709624448 Equivalent to 42 /8s, 76 /16s and 2 /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-207259 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: 82075 Total LACNIC prefixes after maximum aggregation: 17546 LACNIC Deaggregation factor: 4.68 Prefixes being announced from the LACNIC address blocks: 83205 Unique aggregates announced from the LACNIC address blocks: 37958 LACNIC Region origin ASes present in the Internet Routing Table: 5653 LACNIC Prefixes per ASN: 14.72 LACNIC Region origin ASes announcing only one prefix: 1575 LACNIC Region transit ASes present in the Internet Routing Table: 1042 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3173 Number of LACNIC addresses announced to Internet: 170727680 Equivalent to 10 /8s, 45 /16s and 25 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16444 Total AfriNIC prefixes after maximum aggregation: 3685 AfriNIC Deaggregation factor: 4.46 Prefixes being announced from the AfriNIC address blocks: 17940 Unique aggregates announced from the AfriNIC address blocks: 6794 AfriNIC Region origin ASes present in the Internet Routing Table: 1020 AfriNIC Prefixes per ASN: 17.59 AfriNIC Region origin ASes announcing only one prefix: 327 AfriNIC Region transit ASes present in the Internet Routing Table: 193 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 292 Number of AfriNIC addresses announced to Internet: 87572736 Equivalent to 5 /8s, 56 /16s and 65 /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 5546 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3731 391 257 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2985 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2734 11133 745 KIXS-AS-KR Korea Telecom, KR 9829 2699 1499 541 BSNL-NIB National Internet Backbone, IN 9808 2282 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2053 420 217 TATACOMM-AS TATA Communications formerl 45899 1857 1299 103 VNPT-AS-VN VNPT Corp, VN 4808 1636 1785 447 CHINA169-BJ China Unicom Beijing Provin 24560 1566 577 258 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd 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 22773 3633 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3284 1333 83 SHAW - Shaw Communications Inc., CA 18566 2190 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2063 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1969 2035 400 CHARTER-NET-HKY-NC - Charter Communicat 209 1726 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1690 317 455 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16509 1688 3065 546 AMAZON-02 - Amazon.com, Inc., US 6983 1680 852 227 ITCDELTA - Earthlink, Inc., US 701 1587 10604 656 UUNET - MCI Communications Services, In 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 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3036 1137 2142 AKAMAI-ASN1 , US 9121 2624 1691 18 TTNET , TR 34984 1985 327 387 TELLCOM-AS , TR 13188 1617 99 62 TRIOLAN , UA 8551 1603 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1490 1033 50 UNI2-AS , ES 9198 1311 352 24 KAZTELECOM-AS , KZ 6849 1304 355 22 UKRTELNET , UA 12389 1265 1212 487 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3531 543 188 Telmex Colombia S.A., CO 26615 3046 2330 44 Tim Celular S.A., BR 8151 2490 3374 550 Uninet S.A. de C.V., MX 11830 1803 368 66 Instituto Costarricense de Electricidad 6503 1567 437 54 Axtel, S.A.B. de C.V., MX 7303 1428 876 254 Telecom Argentina S.A., AR 6147 1358 377 27 Telefonica del Peru S.A.A., PE 28573 1063 2282 180 CLARO S.A., BR 3816 1003 480 182 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 979 280 36 Techtel LMDS Comunicaciones Interactiva 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 1297 398 41 LINKdotNET-AS, EG 36903 718 361 122 MT-MPLS, MA 37611 691 67 6 Afrihost, ZA 36992 587 1373 25 ETISALAT-MISR, EG 24835 489 658 16 RAYA-AS, EG 8452 447 1474 16 TE-AS TE-AS, EG 37492 392 316 74 ORANGE-TN, TN 29571 366 36 10 CITelecom-AS, CI 15399 327 35 6 WANANCHI-KE, KE 2018 273 327 74 TENET-1, ZA 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 4538 5546 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3731 391 257 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3633 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3531 543 188 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3284 1333 83 SHAW - Shaw Communications Inc., CA 26615 3046 2330 44 Tim Celular S.A., BR 20940 3036 1137 2142 AKAMAI-ASN1 , US 17974 2985 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2734 11133 745 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3633 3482 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3731 3474 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3531 3343 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3284 3201 SHAW - Shaw Communications Inc., CA 26615 3046 3002 Tim Celular S.A., BR 17974 2985 2914 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2624 2606 TTNET , TR 9808 2282 2249 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2699 2158 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 41.73.21.0/24 37004 Suburban-Broadband-AS, NG 41.73.22.0/24 37004 Suburban-Broadband-AS, NG 41.73.23.0/24 37004 Suburban-Broadband-AS, NG 41.76.232.0/21 203496 AB-TELECOM , RU 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:16 /9:13 /10:36 /11:103 /12:276 /13:535 /14:1047 /15:1801 /16:13165 /17:7765 /18:13085 /19:24959 /20:38121 /21:40928 /22:74244 /23:62948 /24:355462 /25:561 /26:414 /27:294 /28:35 /29:18 /30:18 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3080 3284 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2828 3633 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2562 3046 Tim Celular S.A., BR 18566 2083 2190 MEGAPATH5-US - MegaPath Corporation, US 9121 1835 2624 TTNET , TR 30036 1501 1690 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1456 3531 Telmex Colombia S.A., CO 6389 1372 2063 BELLSOUTH-NET-BLK - BellSouth.net Inc., US 13188 1360 1617 TRIOLAN , UA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1594 2:832 4:25 5:2452 6:34 8:1052 12:1811 13:78 14:1777 15:22 16:2 17:100 18:128 19:1 20:53 23:2012 24:1850 25:2 27:2387 31:1862 32:89 33:4 34:1 35:3 36:359 37:2541 38:1312 39:43 40:99 41:2846 42:455 43:1930 44:63 45:2358 46:2581 47:109 49:1211 50:946 51:18 52:743 54:357 55:7 56:4 57:41 58:1626 59:986 60:387 61:1901 62:1504 63:1927 64:4563 65:2171 66:4437 67:2225 68:1169 69:3320 70:1300 71:571 72:2121 74:2605 75:402 76:407 77:1429 78:1675 79:1280 80:1358 81:1407 82:983 83:726 84:861 85:1732 86:484 87:1134 88:829 89:2035 90:209 91:6120 92:982 93:2376 94:2362 95:2827 96:568 97:357 98:938 99:88 100:153 101:1239 103:13702 104:2742 105:156 106:485 107:1551 108:795 109:2575 110:1287 111:1657 112:1149 113:1236 114:1043 115:1732 116:1762 117:1654 118:2055 119:1564 120:956 121:1096 122:2313 123:2016 124:1538 125:1814 128:731 129:619 130:412 131:1367 132:518 133:191 134:527 135:210 136:505 137:412 138:1840 139:500 140:369 141:520 142:729 143:887 144:758 145:167 146:1020 147:654 148:1271 149:570 150:692 151:941 152:723 153:319 154:755 155:970 156:552 157:595 158:447 159:1396 160:568 161:726 162:2479 163:529 164:782 165:1150 166:376 167:1257 168:2531 169:743 170:2772 171:274 172:936 173:1832 174:805 175:720 176:1775 177:4195 178:2473 179:1623 180:2085 181:2036 182:2209 183:1041 184:830 185:8759 186:3174 187:2680 188:2354 189:1808 190:8152 191:1914 192:9300 193:5770 194:4624 195:3859 196:1946 197:1257 198:5567 199:5842 200:7394 201:4121 202:10124 203:9877 204:4438 205:2763 206:2985 207:3134 208:3993 209:3927 210:3917 211:2098 212:2793 213:2480 214:857 215:64 216:5822 217:1993 218:834 219:611 220:1688 221:898 222:738 223:1147 End of report From cdel at firsthand.net Fri Feb 17 18:12:44 2017 From: cdel at firsthand.net (Christian de Larrinaga) Date: Fri, 17 Feb 2017 18:12:44 +0000 Subject: gagging *IX directors re snoop/block orders In-Reply-To: <20170217173825.GA5534@sunf10.rd.bbc.co.uk> References: <20170217155623.GU15415@sizone.org> <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> <20170217160711.GX15415@sizone.org> <20170217173825.GA5534@sunf10.rd.bbc.co.uk> Message-ID: <58A73D1C.8090204@firsthand.net> It's a pretty shocking development. It's one thing to nobble a single network under the IP Act to interfere with equipment but to use a neutral exchange to nobble shared infrastructure used across US and UK and ... is a completely different can of worms. I don't exercise a vote anymore at LINX but I do hope members will pause and consider this very carefully indeed. Christian > Brandon Butterworth > 17 February 2017 at 17:38 > On Fri Feb 17, 2017 at 05:19:32PM +0000, William Waites wrote: >> So instead of saying, "we have this new spying law in the UK and we need >> to rejigg the decision-making at LINX so we will be ready in case we are >> required to do something that must be kept secret" > > Yes but "hey government, swivel on this" isn't going to be an > effective secret weapon, they'll neutralise it before you use it > >> what was proposed to >> the membership was, "we have embarked on this long governance journey >> and this is what we have come up with as the best way to run LINX". Those >> are two very different propositions > > A big winking eye emoji was needed > > brandon > William Waites > 17 February 2017 at 17:19 >> On Feb 17, 2017, at 16:46, Patrick W. Gilmore wrote: >> >> There is one problem: The article is factually incorrect on multiple points. > > It would be interesting to know what points those are, it reads mostly accurately > to me. > >> The proposed constitutional changes are in the public domain. > > The main problem, though this point may have gotten lost in the very long > discussion on the LINX members list, is that the reasoning and motivation for > the changes was not made clear. Even when explanatory materials were > belatedly provided, they weren?t especially clear. > > So instead of saying, "we have this new spying law in the UK and we need > to rejigg the decision-making at LINX so we will be ready in case we are > required to do something that must be kept secret" what was proposed to > the membership was, "we have embarked on this long governance journey > and this is what we have come up with as the best way to run LINX". Those > are two very different propositions, especially for busy people who don?t have > time to read in detail and understand all the implications. > > All that I suggested is that the members be properly informed so that they > can make this choice with their eyes open. It is important to have this > discussion in the open, and explicitly mark the transition where Internet > Exchange Points re-organise themselves to accommodate spying laws and > gag orders. > > William Waites > Laboratory for Foundations of Computer Science > School of Informatics, University of Edinburgh > Informatics Forum 5.38, 10 Crichton St. > Edinburgh, EH8 9AB, Scotland > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > -- Christian de Larrinaga FBCS, CITP, ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel at firsthand.net ------------------------- From edugas at unknowndevice.ca Fri Feb 17 20:19:55 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Fri, 17 Feb 2017 15:19:55 -0500 Subject: Engineering contact at RocketFiber Message-ID: Anyone from RocketFiber's engineering group on this list? Contact me off-list please! Eric From ghankins at mindspring.com Sat Feb 18 18:59:49 2017 From: ghankins at mindspring.com (Greg Hankins) Date: Sat, 18 Feb 2017 13:59:49 -0500 Subject: RFC 8092 on BGP Large Communities Attribute Message-ID: <20170218185949.GA3136@mindspring.com> Hey NANOG, As a followup to our NANOG 68 presentation in Dallas on BGP Large Communites (https://www.nanog.org/meetings/abstract?id=2990), RFC 8092 as just published on Thursday. BGP Large Communities solve a big issue for network operators, by providing a simple way to signal meta-information between networks using 16-bit or 32-bit ASNs. Publication as an RFC was accomplished in a remarkably short time, due to the close cooperation and strong consensus between the IETF IDR Working Group and network operators. The idea progressed rapidly from its inception in March 2016, to the first Internet-Draft in September 2016, to its final IESG approval stages in December 2016, and finally to publication as an RFC in barely seven months. In addition the the final standard, a number of implementations and tools were developed along the way, so that network operators can test and deploy the new technology now. The latest list of software that support BGP Large Communities is here: http://largebgpcommunities.net/implementations/ . While the final milestone to RFC publication has been reached, this is by no means the end of the story! Work on the "Usage of BGP Large Communities" I-D (https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage) continues, to provide examples and inspiration for network operators on how to use BGP Large Communities. It?s time to celebrate, as 32-bit ASNs are first class citizens now too! More information can be found here: http://largebgpcommunities.net/ . RFC 8092 can be found here: https://tools.ietf.org/html/rfc8092 . Kind regards, Greg -- Greg Hankins ----- Forwarded message from rfc-editor at rfc-editor.org ----- Date: Thu, 16 Feb 2017 10:23:49 -0800 (PST) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org Cc: drafts-update-ref at iana.org, idr at ietf.org, rfc-editor at rfc-editor.org Subject: [Idr] RFC 8092 on BGP Large Communities Attribute A new Request for Comments is now available in online RFC libraries. RFC 8092 Title: BGP Large Communities Attribute Author: J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard Status: Standards Track Stream: IETF Date: February 2017 Mailbox: jheitz at cisco.com, job at ntt.net, keyur at arrcus.com, ibagdona.ietf at gmail.com, nick at inex.ie Pages: 8 Characters: 15979 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-large-community-12.txt URL: https://www.rfc-editor.org/info/rfc8092 DOI: 10.17487/RFC8092 This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs. This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr ----- End forwarded message ----- From nagarjun.govindraj at imaginea.com Mon Feb 20 05:52:17 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Mon, 20 Feb 2017 05:52:17 +0000 Subject: RPKI coverage statistics Message-ID: Hi All, where can I found the current coverage of IP prefixes under RPKI system. Stats like total prefixes issued collectively by all the organisations like RIR's/IANA/ISP's. stats like prefixes coverd under RPKI system. The goal is to detect the BGP IP prefix hijacking using RPKI system. I would like to know the coverage before adopting RPKI system. I would like to know the suggestions from the community on using this system. Regards, Nagarjun From alexb at ripe.net Mon Feb 20 10:01:43 2017 From: alexb at ripe.net (Alex Band) Date: Mon, 20 Feb 2017 11:01:43 +0100 Subject: RPKI coverage statistics In-Reply-To: References: Message-ID: <7A0C045A-3FC3-4EE0-AB90-FFF2B87BD373@ripe.net> Hi Nagarjun, You can find some statistics on adoption, coverage and quality here: http://certification-stats.ripe.net https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html http://rpki.surfnet.nl All the best, Alex Band > On 20 Feb 2017, at 06:52, Nagarjun Govindraj via NANOG wrote: > > Hi All, > > where can I found the current coverage of IP prefixes under RPKI system. > Stats like total prefixes issued collectively by all the organisations like > RIR's/IANA/ISP's. > stats like prefixes coverd under RPKI system. > > The goal is to detect the BGP IP prefix hijacking using RPKI system. > I would like to know the coverage before adopting RPKI system. > > I would like to know the suggestions from the community on using this > system. > > Regards, > Nagarjun > From ing.fabianmejia at gmail.com Sat Feb 11 18:26:23 2017 From: ing.fabianmejia at gmail.com (=?UTF-8?B?RmFiacOhbiBNZWrDrWE=?=) Date: Sat, 11 Feb 2017 13:26:23 -0500 Subject: Call for presentations - FIR 2017 Message-ID: <989181e9-fd74-13bc-866a-64a5a4210c0c@gmail.com> *********************************************************************** CALL FOR PRESENTATIONS *********************************************************************** REGIONAL INTERCONNECTION FORUM 2017 May 22-26, 2017 ? Foz do Iguazu, Brasil More information: http://interconexion.lacnic.net LACNIC (http://www.lacnic.net) is an international organization based in Montevideo, Uruguay, responsible for administrating IP address space, Reverse Resolution, Autonomous System Numbers and other resources for the region of Latin America and the Caribbean on behalf of the Internet community. The Regional Interconnection Forum (formerly known as NAPLA), is a discussion forum that includes an annual meeting held within the framework of LACNIC's main annual event. The LACNIC 27 event (http://www.lacnic.net/web/eventos/lacnic27) will be held in Foz do Iguazu (Brasil) on 22-26 May, 2017, so we are calling the Internet community to submit proposals for presentations that could be included on the 2017 Regional Interconnection Forum's program. The topics of interest for the event include, but are not limited to, the following: * Internet Exchange Points (IXPs): current status, future projects, new services, public policies, multimedia peering,. * Regional Connectivity: the role of governments, submarine and terrestrial cables, traffic measurements, current and future needs. * Content Delivery Networks (CDNs): strategies of deployment and presence within the region, peering policies, impact on local and regional traffic, * Cloud services: impact on local and regional traffic, availability, growth, future projects in the LAC region. * Other critical infrastructure: DNS root servers, ccTLDs and gTLDs. * Technical topics: best BGP routing practices, analysis of faults and attacks having major impacts on traffic. * Current issues: impact on local or regional traffic of high-interest events (e.g., availability / unavailability of services, natural disasters, sports events of high interest, etc). GUIDELINES FOR THE SUBMISSION OF PROPOSALS: Those interested in presenting a proposal should send an email to comite.fir@ lacnic.net containing the following information in the text of the message: * Presentation title. * General summary. * An attachment with a draft of the slides or an extended abstract of the article / work submitted. This text should not exceed one thousand (1000) words. * Estimated time of the presentation. * Authors' details (full name, email address and company/organization they represent) * Specify whether at least one of the authors can guarantee their attendance at the event, or whether this depends on the possibility of obtaining financial assistance from the event's organizers (see "Speaker Benefits"). In addition, the following considerations should be taken into account: * Proposals may be submitted in English, Portuguese or Spanish. * Proposals must be submitted in Portable Document Format (PDF). * Scanned documents will not be accepted. * Presentations may not be longer than 20 minutes. The time allocated may be different than requested. * The Evaluation Committee may, at its sole discretion, request additional information, which must be sent promptly. PROPOSAL EVALUATION: The Evaluation Committee created for this purpose shall evaluate proposals based on the following basic criteria: * Originality * Value of sharing the experience * Technical quality * Relevance * Possibility of generalized application * Presentation * Applicability * Importance of the development THE EVALUATION COMMITTEE IS MADE UP AS FOLLOWS: * Roque Gagliano (UY) * Milton Kashiwakura (BR) * Hernan Arcidiacono (AR) * Mauricio Oviedo (CR) * Gabriel Adonaylo (AR) * Christian O'Flaherty (AR) * Carlos Mart?nez (UY) * Fabi?n Mej?a (EC) SPEAKER BENEFITS: The registration fee will be waived for those authors whose proposals are accepted and included in the program. However, speaker travel and accommodation expenses will not be covered. Those requiring financial assistance to attend the event may apply for such assistance when LACNIC opens the corresponding application period. Please note that acceptance of a proposal does NOT imply that the author(s) will be granted financial assistance, although the submission of a proposal may be considered a plus during the recipient selection process. For more information, please check out the Financial Assistance section on the event's website: (http://www.lacnic.net/web/eventos/lacnic27) or check with LACNIC staff at becas at lacnic.net IMPORTANT DATES: * Deadline for proposal reception: Sunday, 12 March 2017 * Notification of acceptance: Week of March 13, 2017 * Deadline for submitting the final version of the presentation: Friday, 12 May, 2017 Kind regards, Fabian Mejia Chair Regional Interconnection Forum From paolo.difrancesco at level7.it Fri Feb 17 16:08:53 2017 From: paolo.difrancesco at level7.it (Paolo Di Francesco) Date: Fri, 17 Feb 2017 17:08:53 +0100 Subject: gagging *IX directors re snoop/block orders In-Reply-To: <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> References: <20170217155623.GU15415@sizone.org> <789372024.1725.1487347378980.JavaMail.mhammett@ThunderFuck> Message-ID: <42dc029d-ac9b-2c5f-bcba-660d08ef4544@level7.it> They are present in IXes but not really exchanging traffic, AFAIK they usually join in order to be able to sell to providers Regards Paolo > I'm not sure Cogent is on any IXes? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Ken Chase" > To: nanog at nanog.org > Sent: Friday, February 17, 2017 9:56:23 AM > Subject: gagging *IX directors re snoop/block orders > > And when you go to figure out why that IP wont ping through Cogent on > your exchange, and start troubleshooting but can't get any answers > as to why things are bust... > > [ Clearly now an operational issue for NANOG. ] > > Purposely breaking routing and not being able to talk about why is going to > set many orgs at odds with their basic operational charters. I expect that > a paid service will work when it's provided, including help debugging their end. > > This is slightly different from a service provider, ostensibly you can > go elsewhere to get service - but when you are a member of a nonprofit *IX > (as we are with TorIX), things get a lot more complex. > > I imagine contract lawyers are going to be all over this. > > https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/ > > (their typo in the url) > > /kc -- Ing. Paolo Di Francesco Level7 s.r.l. unipersonale Sede operativa: Largo Montalto, 5 - 90144 Palermo C.F. e P.IVA 05940050825 Fax : +39-091-8772072 assistenza: (+39) 091-8776432 web: http://www.level7.it From tspprmng at feec.vutbr.cz Fri Feb 17 22:57:03 2017 From: tspprmng at feec.vutbr.cz (TSP 2017) Date: Fri, 17 Feb 2017 23:57:03 +0100 Subject: Deadline: February 20th - Call for Organizers of IEEE R8 Technically Co-Sponsored Special Sessions and Workshops | Barcelona | 40th Int. Conf. on Telecommunications and Signal Processing Message-ID: <3c1ed511-a0a9-4fdb-7823-ffd131478b66@feec.vutbr.cz> ****Call for Special Sessions and Workshops***Deadline:February 20, 2017*** * 2017 40th International Conference on Telecommunications and Signal Processing (TSP) July 5-7, 2017, Barcelona, Spain Web: http://tsp.vutbr.cz/ ************************************************************************************ Technically co-sponsored by IEEE Region 8 , EEE Spain Section , IEEE Czechoslovakia Section , IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter , and IEEE Croatia Section Communications Chapter . The TSP 2017 Proceedings, containing presented papers at the Conference, will be sent for indexing in the IEEE Xplore? Digital Library registered under _IEEE Conference Record #41294 _, SCOPUS , Conference Proceedings Citation Index (CPCI) of Thomson Reuters , DBLP , and Google Scholar databases. Authors of the best rated and presented papers will be invited for publishing in special issues of international journals. ************************************************************************************ Dear Colleague, Within the framework of the *2017 40th International Conference on Telecommunications and Signal Processing (TSP - http://tsp.vutbr.cz )* held during *July 5-7, 2017, Barcelona, Spain*, prospective Organizers are invited to submit proposals for Special Sessions and Workshops at TSP 2017 Conference. Proposals are due through the form below by February 20, 2017. For a Special Session and Workshops proposal to be considered for acceptance at TSP 2017 Conference, the proposed topic needs to be an emerging area in telecommunications or signal processing. The topic should be timely and significantly important to the technical audience, and the speakers need to convey compelling information about the topic. The proposals will be evaluated by the ability to introduce the area to large telecommunications and signal processing community, further develop the area, and help establishing a larger research community beyond the area. Each Special Session and Workshop will be approx. 90 minutes long and will usually consist of 5 oral presentations, however, in case of larger interest the Special Session or Workshop will be divided to more parts. Other formats may be possible, including panel discussions, demos, or poster presentations. The Organizer?s role is to invite the speakers, help with reviews, and chair the session itself. Each speaker invited to a Special Session and Workshop will be required to submit a paper, under the regular submission requirements, by the regular submission deadline. These papers will enter the same system as regular papers, and be subject to reviews. The Organizer will be asked to help with selection of reviewers and in consultation with the program committee will make accept/reject decisions. It is possible that some invited papers may be rejected. However, this is expected to be a rare case since the Organizer should recruit only the high-quality papers to the Special Session or Workshop. The invited speakers as well as the Organizer will be required to register for the conference. Registration fees will not be waived and there will be no honoraria available through TSP. Formore information please visit the /Call for Special Sessions and Workshops/ at website http://tsp.vutbr.cz/. We are also ready to answer your questions emailed to tsp at feec.vutbr.cz . Looking forward to meeting you in Barcelona, Spain. With best regards, Norbert Herencsar and Marcos Faundez-Zanuy TSP 2017 General Co-Chairs Web: http://tsp.vutbr.cz/ E-mail: tsp at feec.vutbr.cz Follow us on: - Facebook https://www.facebook.com/tspconf - Twitter https://twitter.com/tspconf =============================================================== doc. Ing. Norbert Herencsar, Ph.D., IEEE Senior Member - IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter Chair Department of Telecommunications Brno University of Technology Brno, Czech Republic & Prof. Dr. Marcos Faundez-Zanuy - Dean Escola Universitaria Politecnica de Mataro, Tecnocampus Mataro, Spain ************************************************************************************ TSP Organizers reserve the right to exclude a paper from distribution after the Conference (e.g., non-indexing in IEEE Xplore? and other databases) if the paper is not presented at the Conference. However, this paper will be distributed as part of the Conference proceedings issued on an USB drive. ************************************************************************************ From tspprmng at feec.vutbr.cz Sat Feb 18 01:40:39 2017 From: tspprmng at feec.vutbr.cz (TSP 2017) Date: Sat, 18 Feb 2017 02:40:39 +0100 Subject: [TSP 2017] Call for Reviewers - IEEE R8 Technically Co-Sponsored 40th Int. Conf. on Telecommunications and Signal Processing, Barcelona, Spain, July 5-7, 2017 Message-ID: <2f9d7c8e-9442-7e36-401a-025c824ccda7@feec.vutbr.cz> Dear Colleague, The Organizing Committee of the 2017 40th International Conference on Telecommunications and Signal Processing (TSP - /http://tsp.vutbr.cz//) seeks for acknowledged specialists to participate in the review process and support the TSP community with the evaluation of 2 or 3 manuscripts. To appreciate this effort, we are glad to offer to reviewers an authorization for reduced conference registration fee. The TSP 2017 Conference will be held during July 5-7, 2017, in Barcelona, Spain and it is organized in cooperation with the IEEE Region 8 (Europe, Middle East and Africa), IEEE Spain Section, IEEE Czechoslovakia Section, IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter, and IEEE Croatia Section Communications Chapter by sixteen universities from Czech Republic, Hungary, Turkey, Taiwan, Japan, Slovak Republic, Spain, Bulgaria, France, Slovenia, Croatia, and Poland for academics, researchers, and developers and it serves as a premier annual international forum to promote the exchange of the latest advances in telecommunication technology and signal processing. To register yourself, please visit the http://tsp.vutbr.cz/tsp2017/openconf/openconf.php website and enter the "*tsp17rev*" password into the "*Sign Up ? Keycode:*" field and click on "*Enter*" button. In addition to *selection of maximum 3 Topic Areas*, please *enter to "Keywords"*field *at least 7 semi comma (;) separated specific keywords *from the field of your expertise in order to ensure proper manuscript assignment. The manuscript assignment process will be launched in the second half of March 2017 and you will be informed by automatic email notification. Thank you in advance for your collaboration. With best regards, Norbert Herencsar and Marcos Faundez-Zanuy TSP 2017 General Co-Chairs Web: http://tsp.vutbr.cz/ E-mail: tsp at feec.vutbr.cz Follow us on: - Facebook https://www.facebook.com/tspconf - Twitter https://twitter.com/tspconf =============================================================== doc. Ing. Norbert Herencsar, Ph.D., IEEE Senior Member - IEEE Czechoslovakia Section SP/CAS/COM Joint Chapter Chair Department of Telecommunications Brno University of Technology Brno, Czech Republic & Prof. Dr. Marcos Faundez-Zanuy - Dean Escola Universitaria Politecnica de Mataro, Tecnocampus Mataro, Spain --------------------End of Message-------------------- From liste at freeheberg.com Sat Feb 18 10:28:21 2017 From: liste at freeheberg.com (Jeremy) Date: Sat, 18 Feb 2017 11:28:21 +0100 Subject: OADM spliting Message-ID: <7ca9218d-4514-5c45-3af9-f8660fdc0728@freeheberg.com> Hello the nanog list, I'm searching for a OADM CWDM splitting module which can be placed in a BEP outdoor box (this OADM module must have a EAST input and a WEST output, with the capacity to active the split for each waves or not) with the 2 mux/demux rack 19". Classics CWDM waves needs (1470-1610 nm with 8 channels). If you know a good BPE which can accept 10 x 1.5 fibers opticals cables I/O and with SC connectors, we like it if you can add it in your quote. Are there someone here who can send a quote for this hardware and who can send this hardware very quickly to France ? Thanks, From editor at ijritcc.org Mon Feb 20 14:00:12 2017 From: editor at ijritcc.org (Editor IJRITCC) Date: Mon, 20 Feb 2017 14:00:12 +0000 Subject: Deadline Approaching IJRITCC Journal Call for Papers (Celebrating 50th publication issue) Message-ID: <0100015a5bd29694-01d4d5a9-667a-46cd-aa5f-c0dca1fc2930-000000@email.amazonses.com> Welcome to this very special issue, marking?IJRITCC's?50th publication issue - a special time for celebration and reflection. Impact Factor 5.837 Citation in Thomson Reuters Google Scholar Academia Scribd ?Slideshare etc. International Journal on Recent and Innovation Trends in Computing and Communication (IJRITCC) ISSN: 2321-8169 https://www.ijritcc.org CALL FOR PAPERS - February- 2017 (Paper Submission Deadline 28 - February-2017) Volume 5 Issue 2 (Volume Number 5 Issue Number 50) IJRITCC is the one of the renowned, fully OPEN ACCESS, International Engineering Journal with more than 200000 monthly content viewers. IJRITCC is trusted by more than 37000 satisfied authors worldwide & growing rapidly. We are happy to invite you to submit your next article of your research/review/study in any engineering research area for publication upcoming issue of IJRITCC. Author Benefits: Fast & Transparent paper publishing process? Paper will publish online Free Individual Soft Copy of "Certificate of Publication" to each author of paper.? Open Access Journal Database for High visibility and promotion of your research work. Inclusion in all Major Indexing Databases like , Thomson Reuter Researchs ID, Academia, Scribd, Google Scholar. Prestigious academic journal reviewers around the world. Publication Fee?(Maximum 6 Authors)? Indian Authors: INR 2000 Overseas: USD 100 Paper Submission Last Date of Submission : February 28, 2017 Acceptance Notification : within 1-2 days after submission ?(Faster review via Online Peer Review System) Publication of Article : within 1-2 days after registration Submit manuscript by mailing us to editor at ijritcc.org / ijritcc at gmail.com or submit online by the link below: Paper Submission Link: http://www.ijritcc.org/submit-your-paper IJRITCC Manuscript Template: http://www.ijritcc.org/download/1477466677.docx Kindly forward this e-mail to your group of Friends / Students/ Colleagues / Associates / Fellow Researchers ,who may be benefited out of this. Thanking You, Editor IJRITCC www.ijritcc.org --------------------------------------------------------------------------------------------------------------------------- Unsubscibe using below link,? Unsubscribe here If Unsubscribe link is not working kindly reply us unsubscribe. We will never send you email again. From nagarjun.govindraj at imaginea.com Tue Feb 21 06:22:41 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Tue, 21 Feb 2017 06:22:41 +0000 Subject: RPKI coverage statistics In-Reply-To: <7A0C045A-3FC3-4EE0-AB90-FFF2B87BD373@ripe.net> References: <7A0C045A-3FC3-4EE0-AB90-FFF2B87BD373@ripe.net> Message-ID: I am trying to solve the problem of BGP IP prefix hijack detection for the AS we own using RPKI system. But IP addresses covered under RPKI system is very less under 10%. How is community dealing with UNKNOWN state for the prefixes when queried against RPKI system. Reply from the community members shows that majority are using RPKI system. Is community using anyother methods on top of RPKI ? Regards, Nagarjun On Mon, Feb 20, 2017 at 3:31 PM Alex Band wrote: > Hi Nagarjun, > > You can find some statistics on adoption, coverage and quality here: > > http://certification-stats.ripe.net > > https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html > http://rpki.surfnet.nl > > All the best, > > Alex Band > > > On 20 Feb 2017, at 06:52, Nagarjun Govindraj via NANOG > wrote: > > > > Hi All, > > > > where can I found the current coverage of IP prefixes under RPKI system. > > Stats like total prefixes issued collectively by all the organisations > like > > RIR's/IANA/ISP's. > > stats like prefixes coverd under RPKI system. > > > > The goal is to detect the BGP IP prefix hijacking using RPKI system. > > I would like to know the coverage before adopting RPKI system. > > > > I would like to know the suggestions from the community on using this > > system. > > > > Regards, > > Nagarjun > > > > From hank at efes.iucc.ac.il Tue Feb 21 07:25:41 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 21 Feb 2017 09:25:41 +0200 Subject: RPKI coverage statistics In-Reply-To: References: <7A0C045A-3FC3-4EE0-AB90-FFF2B87BD373@ripe.net> Message-ID: <93363184-0e65-ced3-089d-eafe620b60ff@efes.iucc.ac.il> On 21/02/2017 08:22, Nagarjun Govindraj via NANOG wrote: > I am trying to solve the problem of BGP IP prefix hijack detection for the > AS we own using RPKI system. > But IP addresses covered under RPKI system is very less under 10%. > How is community dealing with UNKNOWN state for the prefixes when queried > against RPKI system. Suggest reading: https://www.nanog.org/sites/default/files/3_Gilad_Are_We_There_v1.pdf from NANOG 69 earlier this month. Regards, Hank > Reply from the community members shows that majority are using RPKI system. > Is community using anyother methods on top of RPKI ? > > Regards, > Nagarjun > > > On Mon, Feb 20, 2017 at 3:31 PM Alex Band wrote: > >> Hi Nagarjun, >> >> You can find some statistics on adoption, coverage and quality here: >> >> http://certification-stats.ripe.net >> >> https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html >> http://rpki.surfnet.nl >> >> All the best, >> >> Alex Band >> >>> On 20 Feb 2017, at 06:52, Nagarjun Govindraj via NANOG >> wrote: >>> Hi All, >>> >>> where can I found the current coverage of IP prefixes under RPKI system. >>> Stats like total prefixes issued collectively by all the organisations >> like >>> RIR's/IANA/ISP's. >>> stats like prefixes coverd under RPKI system. >>> >>> The goal is to detect the BGP IP prefix hijacking using RPKI system. >>> I would like to know the coverage before adopting RPKI system. >>> >>> I would like to know the suggestions from the community on using this >>> system. >>> >>> Regards, >>> Nagarjun >>> >> From jcurran at arin.net Tue Feb 21 14:06:31 2017 From: jcurran at arin.net (John Curran) Date: Tue, 21 Feb 2017 14:06:31 +0000 Subject: Deadline To Volunteer for the 2017 ARIN Nomination Committee Has Been Extended to 24 February 2017 Message-ID: <2F1B989B-B83A-4626-AC72-1AFB53A1D9D2@arin.net> NANOGers - The deadline to volunteer for the 2017 ARIN Nomination Committee (NomCom) has been extended to 12:00 PM EST, Friday, 24 February 2017. For more information on the ARIN NomCom, its role and how to volunteer, please reference the following announcement: (& attached below) Thanks! /John John Curran President and CEO ARIN === DEADLINE TO VOLUNTEER FOR THE 2017 NOMINATION COMMITTEE HAS BEEN EXTENDED Posted: Friday, 17 February 2017 Give back to your community and volunteer for the 2017 Nomination Committee (NomCom) today! The deadline to volunteer for this key committee has been extended to 12:00 PM EST, Friday, 24 February. Each year the NomCom plays an instrumental part in ARIN's Elections by identifying, recruiting, and certifying a slate of Board of Trustees and Advisory Council (AC) candidates to the ARIN Membership for election, in accordance with ARIN bylaws and procedures. For more information on the role and responsibilities of the committee, please review the NomCom Charter at: https://www.arin.net/about_us/committeecharters.html#nomcom The NomCom is composed of seven representatives that include two members from the ARIN Board of Trustees, one serving as Chair, who then appoint five individual representatives from a General Membership pool of volunteers. Up to two of these representatives can be currently-serving AC members. Volunteers must represent an ARIN Member organization that is in good standing. Candidates for this year's Board of Trustees and AC elections are ineligible to sit on the NomCom. To be considered for the 2017 NomCom, please email your first and last name, email address, phone number, and the name of the ARIN Member Organization you represent, including the Org ID, to members at arin.net no later than 12:00 PM EST on Friday, 24 February. Selected representatives will be contacted directly by ARIN and will be asked to sign and return a Non-Disclosure Agreement (NDA) within three business days of being notified of their selection. To review the NDA, please visit: https://www.arin.net/participate/elections/nomcom_nda.pdf For more information on the NomCom, please visit the following link: https://www.arin.net/participate/elections/nomcom_faqs.html Regards, Wendy Leedy Member Engagement Coordinator American Registry for Internet Numbers (ARIN) From jcurran at arin.net Tue Feb 21 14:25:31 2017 From: jcurran at arin.net (John Curran) Date: Tue, 21 Feb 2017 14:25:31 +0000 Subject: Deadline To Volunteer for the 2017 ARIN Nomination Committee Has Been Extended to 24 February 2017 Message-ID: NANOGers - The deadline to volunteer for the 2017 ARIN Nomination Committee (NomCom) has been extended to 12:00 PM EST, Friday, 24 February 2017. For more information on the ARIN NomCom, its role and how to volunteer, please reference the following announcement: (& attached below) Thanks! /John John Curran President and CEO ARIN === DEADLINE TO VOLUNTEER FOR THE 2017 NOMINATION COMMITTEE HAS BEEN EXTENDED Posted: Friday, 17 February 2017 Give back to your community and volunteer for the 2017 Nomination Committee (NomCom) today! The deadline to volunteer for this key committee has been extended to 12:00 PM EST, Friday, 24 February. Each year the NomCom plays an instrumental part in ARIN's Elections by identifying, recruiting, and certifying a slate of Board of Trustees and Advisory Council (AC) candidates to the ARIN Membership for election, in accordance with ARIN bylaws and procedures. For more information on the role and responsibilities of the committee, please review the NomCom Charter at: https://www.arin.net/about_us/committeecharters.html#nomcom The NomCom is composed of seven representatives that include two members from the ARIN Board of Trustees, one serving as Chair, who then appoint five individual representatives from a General Membership pool of volunteers. Up to two of these representatives can be currently-serving AC members. Volunteers must represent an ARIN Member organization that is in good standing. Candidates for this year's Board of Trustees and AC elections are ineligible to sit on the NomCom. To be considered for the 2017 NomCom, please email your first and last name, email address, phone number, and the name of the ARIN Member Organization you represent, including the Org ID, to members at arin.net no later than 12:00 PM EST on Friday, 24 February. Selected representatives will be contacted directly by ARIN and will be asked to sign and return a Non-Disclosure Agreement (NDA) within three business days of being notified of their selection. To review the NDA, please visit: https://www.arin.net/participate/elections/nomcom_nda.pdf For more information on the NomCom, please visit the following link: https://www.arin.net/participate/elections/nomcom_faqs.html Regards, Wendy Leedy Member Engagement Coordinator American Registry for Internet Numbers (ARIN) From bicknell at ufp.org Tue Feb 21 15:26:20 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 21 Feb 2017 07:26:20 -0800 Subject: Juniper Advertise MED on EBGP session. Message-ID: <20170221152620.GA69839@ussenterprise.ufp.org> I tried to pull an old trick out of my playbook this morning and failed. I'd like to advertise BGP Metrics on an EBGP session, specifically the existing internal metrics. I know how to do this on a Cisco, but I tried on a Juniper and it seems to be impossible. I can set a metric in a policy, or put a default metric on the session as a whole, or even set it to IGP. But none of those are what I want. I want the existing metrics advertised as-is, just like would be done over an IBGP session. After an hour of reading documentation and trying a few things, I'm starting to think it may be impossible on JunOS. Anyone have a tip or trick? -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From ruairi.carroll at gmail.com Tue Feb 21 16:06:18 2017 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Tue, 21 Feb 2017 17:06:18 +0100 Subject: Juniper Advertise MED on EBGP session. In-Reply-To: <20170221152620.GA69839@ussenterprise.ufp.org> References: <20170221152620.GA69839@ussenterprise.ufp.org> Message-ID: Unless I'm going insane, I think you're trying to use the IGP metric as MED? If so, then : https://www.juniper.net/documentation/en_US/junos12.3/topics/topic-map/bgp-med.html#jd0e3487 /Ruairi On 21 February 2017 at 16:26, Leo Bicknell wrote: > > I tried to pull an old trick out of my playbook this morning and > failed. I'd like to advertise BGP Metrics on an EBGP session, > specifically the existing internal metrics. I know how to do this > on a Cisco, but I tried on a Juniper and it seems to be impossible. > > I can set a metric in a policy, or put a default metric on the > session as a whole, or even set it to IGP. But none of those are > what I want. I want the existing metrics advertised as-is, just > like would be done over an IBGP session. After an hour of reading > documentation and trying a few things, I'm starting to think it > may be impossible on JunOS. > > Anyone have a tip or trick? > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > From sean at donelan.com Tue Feb 21 16:21:09 2017 From: sean at donelan.com (Sean Donelan) Date: Tue, 21 Feb 2017 11:21:09 -0500 (EST) Subject: WWV Broadcast Outages Message-ID: If any network operators still use WWV for time synchronization. Due to an electrical up-grade, Radio Station WWV will be off the air on all frequencies on February 21 and 22, 2017. The outages will occur between 7:00 AM and 5:00 PM Mountain Standard Time, and will not exceed 8 hours in duration each day. https://www.nist.gov/pml/time-and-frequency-division/time-services/wwv-broadcast-outages From olivier.benghozi at wifirst.fr Tue Feb 21 16:38:12 2017 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Tue, 21 Feb 2017 17:38:12 +0100 Subject: Juniper Advertise MED on EBGP session. In-Reply-To: <20170221152620.GA69839@ussenterprise.ufp.org> References: <20170221152620.GA69839@ussenterprise.ufp.org> Message-ID: What metric do you intend to advertise to an eBGP peer? iBGP MED to eBGP MED ? MED being a non-transitive attribute, I guess it's not expected to work if you don't explicitly set a MED in the export policy (you might rely on setting and matching communities for that) or on the peer group. It's not be expected to work on Cisco without explicitly setting the MED, either. IGP metric to MED ? It seems to just work as is here, at least for RIP and OSPF (as long as you don't do anything to the MED in your export policy): RIP metric and OSPF metric are exported spontaneously as MED (when using OSPF E2 routes, beware of the static aspect of their metric). Olivier > On 21 feb. 2017 at 16:26, Leo Bicknell wrote: > > I tried to pull an old trick out of my playbook this morning and > failed. I'd like to advertise BGP Metrics on an EBGP session, > specifically the existing internal metrics. I know how to do this > on a Cisco, but I tried on a Juniper and it seems to be impossible. > > I can set a metric in a policy, or put a default metric on the > session as a whole, or even set it to IGP. But none of those are > what I want. I want the existing metrics advertised as-is, just > like would be done over an IBGP session. After an hour of reading > documentation and trying a few things, I'm starting to think it > may be impossible on JunOS. From msa at latt.net Tue Feb 21 16:45:04 2017 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 21 Feb 2017 11:45:04 -0500 Subject: WWV Broadcast Outages In-Reply-To: References: Message-ID: <20170221164504.GA15928@puck.nether.net> On Tue, Feb 21, 2017 at 11:21:09AM -0500, Sean Donelan wrote: > If any network operators still use WWV for time synchronization. I wouldn't expect this to cause any serious synchonization problem; anyone using HF for time has to have the ability to hold over for a miniumum of several hours anyway due to the vagaries of normal shortwave propagation. (Even 24-48 hour disruptions aren't uncommon after a large solar event.) That said, I and many others "still use" WWV -- there aren't exactly a surplus of suitable backup methods to GPS these days. But if anyone needs it, consider using the fine HF time service provided by our friendly neighbors to the north: http://www.nrc-cnrc.gc.ca/eng/services/time/short_wave.html --msa From ktims at stargate.ca Tue Feb 21 19:10:35 2017 From: ktims at stargate.ca (Keenan Tims) Date: Tue, 21 Feb 2017 11:10:35 -0800 Subject: Juniper Advertise MED on EBGP session. In-Reply-To: <20170221152620.GA69839@ussenterprise.ufp.org> References: <20170221152620.GA69839@ussenterprise.ufp.org> Message-ID: I also spent a significant amount of time trying to figure out a way to do this, and was using communities for a while before I found a solution. It turns out that the expression knob lets you use the existing metric as an input, and this works to export the iBGP MED, at least on my 12.3X48 SRX: then { metric { expression { metric multiplier 1; } } } Keenan On 2017-02-21 07:26, Leo Bicknell wrote: > I tried to pull an old trick out of my playbook this morning and > failed. I'd like to advertise BGP Metrics on an EBGP session, > specifically the existing internal metrics. I know how to do this > on a Cisco, but I tried on a Juniper and it seems to be impossible. > > I can set a metric in a policy, or put a default metric on the > session as a whole, or even set it to IGP. But none of those are > what I want. I want the existing metrics advertised as-is, just > like would be done over an IBGP session. After an hour of reading > documentation and trying a few things, I'm starting to think it > may be impossible on JunOS. > > Anyone have a tip or trick? > From richard.hesse at weebly.com Wed Feb 22 00:27:21 2017 From: richard.hesse at weebly.com (Richard Hesse) Date: Wed, 22 Feb 2017 00:27:21 +0000 Subject: Updating Geolocation of /24 within corporate /16 In-Reply-To: References: Message-ID: If you have a peering session with Google or one of their cache boxes, you can set a GeoIP publishing endpoint using their online portal at isp.google.com. That's only for Google though. -richard On Fri, Feb 10, 2017 at 3:19 AM, David Sotnick wrote: > Hi Tyler, > > I have not yet tried this, but am doing so now, thanks! > > -Dave > > On Thu, Feb 9, 2017 at 6:27 PM, Tyler Conrad wrote: > > > Have you tried submitting a correction to some geolocation services > > directly yet? Maxmind is pretty heavily used. > > > > https://support.maxmind.com/correction-faq/submit-a- > > correction/how-do-i-submit-a-correction-to-geoip-data/ > > > > > > On Thursday, February 9, 2017, David Sotnick > > wrote: > > > >> Hi NANOG, > >> > >> You have given good advice on updating IP Geolocation data in the past, > >> including visiting 'www.google.com' from a mobile device and selecting > >> "use > >> exact location [from GPS]". This worked out well for us a few years ago > >> for > >> a single IP which we were NATting out of in a new geographic location. > >> > >> Now we are in a position where we have been assigned site-local /24 (out > >> of > >> the corporation's larger /20 space) networks for a couple of locations > and > >> I'm wondering how I go about updating IP Geolocation data to note that > two > >> /24 networks are no longer at the Corporate HQ location. > >> > >> I understand that when users first start using these site-specific /24 > >> networks, they will be lumped in with the larger /20 space as far as > their > >> geolocation goes, but besides the Google/GPS method, is there a > >> cleaner/better way to do this? Do Geolocation services use SWIP data? > >> Should I have the /24s have separate SWIP data noting the geo location? > >> I'd > >> love a place to be able to say: "This /24 is at this geoloc; this /24 is > >> at > >> this geoloc; and the corporate /20 remains where it always has been." > >> > >> Many thanks for your insights in this matter, > >> > >> -Dave > >> > > > From me at nek0.net Wed Feb 22 09:33:48 2017 From: me at nek0.net (Stanislaw) Date: Wed, 22 Feb 2017 11:33:48 +0200 Subject: Juniper QFX port VLAN statistics via SNMP - is it possible? Message-ID: <823cfee6309a9b57c4ca5e8f27c6df62@nek0.net> Hi everybody, Is it possible to obtain switched traffic statistics in a port+vlan aspect via SNMP on Juniper QFX switches? For example, Extreme switches have a 'vlan monitor' feature: configure ports all monitor vlan then its counters are available by OID .1.3.6.1.4.1.1916.1.2.8.2.1.8 and .1.3.6.1.4.1.1916.1.2.8.2.1.7 Does anyone know if Juniper has a similar feature? From Jeroen.Wunnink at gtt.net Wed Feb 22 14:34:01 2017 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Wed, 22 Feb 2017 14:34:01 +0000 Subject: Juniper QFX port VLAN statistics via SNMP - is it possible? In-Reply-To: <823cfee6309a9b57c4ca5e8f27c6df62@nek0.net> References: <823cfee6309a9b57c4ca5e8f27c6df62@nek0.net> Message-ID: <292A22DB-360B-4599-81E1-03410A3A8DE7@gtt.net> On a different vendor (Brocade) we used to work around that by putting a rate-limiter onto a vlan and polling the rate-limit counter, not sure if that?d work on a QFX as well though. Jeroen Wunnink IP Engineering manager office: +31.208.200.622 ext. 1011 Amsterdam Office www.gtt.net On 22/02/2017, 10:33, "NANOG on behalf of Stanislaw" wrote: Hi everybody, Is it possible to obtain switched traffic statistics in a port+vlan aspect via SNMP on Juniper QFX switches? For example, Extreme switches have a 'vlan monitor' feature: configure ports all monitor vlan then its counters are available by OID .1.3.6.1.4.1.1916.1.2.8.2.1.8 and .1.3.6.1.4.1.1916.1.2.8.2.1.7 Does anyone know if Juniper has a similar feature? From bicknell at ufp.org Wed Feb 22 16:48:02 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Feb 2017 08:48:02 -0800 Subject: Juniper Advertise MED on EBGP session. In-Reply-To: References: <20170221152620.GA69839@ussenterprise.ufp.org> Message-ID: <20170222164802.GA12541@ussenterprise.ufp.org> In a message written on Tue, Feb 21, 2017 at 11:10:35AM -0800, Keenan Tims wrote: > I also spent a significant amount of time trying to figure out a way to > do this, and was using communities for a while before I found a > solution. It turns out that the expression knob lets you use the > existing metric as an input, and this works to export the iBGP MED, at > least on my 12.3X48 SRX: > > then { > metric { > expression { > metric multiplier 1; > } > } > } This is exactly what I needed. It works perfectly. Many, many thanks. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From manager at monmouth.com Wed Feb 22 17:30:29 2017 From: manager at monmouth.com (Mark Stevens) Date: Wed, 22 Feb 2017 12:30:29 -0500 Subject: Verizon Wireless Back-haul Transport Message-ID: Good afternoon all, If there is a Verizon wireless back-haul transport engineer on the list that can reach out to me offline, it would be great. Topic: bad trunks in the New Brunswick NJ Tandem office. Thanks Mark From dave at temk.in Wed Feb 22 22:21:47 2017 From: dave at temk.in (Dave Temkin) Date: Wed, 22 Feb 2017 14:21:47 -0800 Subject: test, please disregard Message-ID: From bob at FiberInternetCenter.com Wed Feb 22 23:40:08 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 22 Feb 2017 15:40:08 -0800 Subject: Any Github Experts online ? Message-ID: Hello NANOGers, I have one customer that claims that 2 out of 17 downloads using the git command on github's service are slow and poor on our network when compared to others. However, when not using the git command , but using a simple web page link to a large zipped file from github, its always nice and fast. Using the git command 8% of the time being slow is unacceptable. Github just doesnt responds lethargically at best. BTW, have you seen how many hex digits a github ticket number is ? Of course Github says try a different ISP...Customer tries to tell me comcast is better ! What ! I dont believe it. No help from Github NOC - we have asked and asked... And we peer with Github and for some reason they do not transmit the Prefixes of the IP range that the customer uses for the git command. github.com resolve IPv4 is not in the prefix list. So the exit is transits. I need more clues. Is it the resources the git command uses when checking files for dates etc ? Thank You Bob Evans CTO From aaron at heyaaron.com Wed Feb 22 23:47:26 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 22 Feb 2017 15:47:26 -0800 Subject: Any Github Experts online ? In-Reply-To: References: Message-ID: If they are using 'git pull', or 'git push' for example, they may be accessing the data via HTTPS or SSH. Can your user do a 'git remote -v' and see if they are connecting via HTTPS or SSH to assist you with troubleshooting? Then see if it's something specific to one or the other and if it's specific to github or all sites. -A On Wed, Feb 22, 2017 at 3:40 PM, Bob Evans wrote: > Hello NANOGers, > > I have one customer that claims that 2 out of 17 downloads using the git > command on github's service are slow and poor on our network when compared > to others. > > However, when not using the git command , but using a simple web page link > to a large zipped file from github, its always nice and fast. Using the > git command 8% of the time being slow is unacceptable. Github just doesnt > responds lethargically at best. BTW, have you seen how many hex digits a > github ticket number is ? > > Of course Github says try a different ISP...Customer tries to tell me > comcast is better ! What ! I dont believe it. No help from Github NOC - we > have asked and asked... And we peer with Github and for some reason they > do not transmit the Prefixes of the IP range that the customer uses for > the git command. github.com resolve IPv4 is not in the prefix list. So > the exit is transits. > > I need more clues. Is it the resources the git command uses when checking > files for dates etc ? > > Thank You > Bob Evans > CTO > > > > > > From sunyucong at gmail.com Wed Feb 22 23:48:20 2017 From: sunyucong at gmail.com (Yucong Sun) Date: Thu, 23 Feb 2017 07:48:20 +0800 Subject: Any Github Experts online ? In-Reply-To: References: Message-ID: use GIT_CURL_VERBOSE=1 GIT_TRACE=1 git will print out full trace. you can also try other environment variables from https://git-scm.com/book/tr/v2/Git-Internals-Environment-Variables In my experiences, this is usually caused by MTU discovery issue. On Thu, Feb 23, 2017 at 7:40 AM, Bob Evans wrote: > Hello NANOGers, > > I have one customer that claims that 2 out of 17 downloads using the git > command on github's service are slow and poor on our network when compared > to others. > > However, when not using the git command , but using a simple web page link > to a large zipped file from github, its always nice and fast. Using the > git command 8% of the time being slow is unacceptable. Github just doesnt > responds lethargically at best. BTW, have you seen how many hex digits a > github ticket number is ? > > Of course Github says try a different ISP...Customer tries to tell me > comcast is better ! What ! I dont believe it. No help from Github NOC - we > have asked and asked... And we peer with Github and for some reason they > do not transmit the Prefixes of the IP range that the customer uses for > the git command. github.com resolve IPv4 is not in the prefix list. So > the exit is transits. > > I need more clues. Is it the resources the git command uses when checking > files for dates etc ? > > Thank You > Bob Evans > CTO > > > > > > From hhoffman at ip-solutions.net Wed Feb 22 23:59:58 2017 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 22 Feb 2017 18:59:58 -0500 Subject: Comcast IPv6 PD Centos In-Reply-To: References: Message-ID: Hi Folks, I'm wondering if anyone has successfully configured prefix delegation on Comcast's service using CentOS 7 as a router/firewall. I'm trying to help troubleshoot a configuration and I can't find anything current via Google. Cheers, Harry From jared at puck.nether.net Thu Feb 23 00:55:01 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 22 Feb 2017 19:55:01 -0500 Subject: Comcast IPv6 PD Centos In-Reply-To: References: Message-ID: <848B016C-BC6C-482A-B58C-07F5CEA90AE6@puck.nether.net> It may be helpful to look at the forums at UBNT. They have details of how to make it work on their edge router platform which is a Linux box underneath. Jared Mauch > On Feb 22, 2017, at 6:59 PM, Harry Hoffman wrote: > > Hi Folks, > > I'm wondering if anyone has successfully configured prefix delegation on > Comcast's service using CentOS 7 as a router/firewall. > > I'm trying to help troubleshoot a configuration and I can't find anything > current via Google. > > Cheers, > Harry From bryan at shout.net Thu Feb 23 05:41:52 2017 From: bryan at shout.net (Bryan Holloway) Date: Wed, 22 Feb 2017 23:41:52 -0600 Subject: Comcast IPv6 PD Centos In-Reply-To: <848B016C-BC6C-482A-B58C-07F5CEA90AE6@puck.nether.net> References: <848B016C-BC6C-482A-B58C-07F5CEA90AE6@puck.nether.net> Message-ID: <70c91774-a721-2cbd-ac23-d37eb207a257@shout.net> What endpoint do you have? Some of Comcast's devices -- notably the SMCD3G-CCR -- have a broken IPv6 PD implementation. On 2/22/17 6:55 PM, Jared Mauch wrote: > It may be helpful to look at the forums at UBNT. They have details of how to make it work on their edge router platform which is a Linux box underneath. > > Jared Mauch > >> On Feb 22, 2017, at 6:59 PM, Harry Hoffman wrote: >> >> Hi Folks, >> >> I'm wondering if anyone has successfully configured prefix delegation on >> Comcast's service using CentOS 7 as a router/firewall. >> >> I'm trying to help troubleshoot a configuration and I can't find anything >> current via Google. >> >> Cheers, >> Harry > From ikiris at gmail.com Thu Feb 23 06:02:39 2017 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 22 Feb 2017 22:02:39 -0800 Subject: Comcast IPv6 PD Centos In-Reply-To: <70c91774-a721-2cbd-ac23-d37eb207a257@shout.net> References: <848B016C-BC6C-482A-B58C-07F5CEA90AE6@puck.nether.net> <70c91774-a721-2cbd-ac23-d37eb207a257@shout.net> Message-ID: I've tried to get it to work in the past, and finally just switched to a different platform for my "firewall". It's just really really broken in RHEL6/7 derivatives to try to get dhcp-pd to work properly without a lot of jank and external script hooks that are fragile at best without writing something actually stateful to manage the changes at the kernel level + userspace along with interacting with the distribution's network config manager. If you really want to do it, you'll need to switch to a different dhcp flavor like ISC and then write some hook scripts, or you have to swap to a different network configuration management structure. Alternately, you'll likely have a better experience with an edgerouter X or Ubuntu. All that said, it's been a while, so things might be better now? I'd ask on the ISC lists or stackexchange/reddit maybe to see. On Wed, Feb 22, 2017 at 9:41 PM, Bryan Holloway wrote: > What endpoint do you have? Some of Comcast's devices -- notably the > SMCD3G-CCR -- have a broken IPv6 PD implementation. > > > > On 2/22/17 6:55 PM, Jared Mauch wrote: >> >> It may be helpful to look at the forums at UBNT. They have details of how >> to make it work on their edge router platform which is a Linux box >> underneath. >> >> Jared Mauch >> >>> On Feb 22, 2017, at 6:59 PM, Harry Hoffman >>> wrote: >>> >>> Hi Folks, >>> >>> I'm wondering if anyone has successfully configured prefix delegation on >>> Comcast's service using CentOS 7 as a router/firewall. >>> >>> I'm trying to help troubleshoot a configuration and I can't find anything >>> current via Google. >>> >>> Cheers, >>> Harry >> >> > From me at nek0.net Thu Feb 23 09:38:09 2017 From: me at nek0.net (Stanislaw) Date: Thu, 23 Feb 2017 11:38:09 +0200 Subject: Juniper QFX port VLAN statistics via SNMP - is it possible? In-Reply-To: <823cfee6309a9b57c4ca5e8f27c6df62@nek0.net> References: <823cfee6309a9b57c4ca5e8f27c6df62@nek0.net> Message-ID: <58496968c46ca0909a4c0c8f4e5a5e98@nek0.net> I'll just leave the solution here in case that anybody else needs it: Firewall rule: firewall { family ethernet-switching { filter vlan-counters { interface-specific; term vlan-14 { from { dot1q-tag 14; } then { accept; count vlan-14; } } term vlan-571 { from { dot1q-tag 571; } then { accept; count vlan-571; } } term vlan-572 { from { dot1q-tag 572; } then { accept; count vlan-572; } } term default { then accept; } } } } Applying it: set interfaces ae0.0 family ethernet-switching filter input vlan-counters set interfaces ae0.0 family ethernet-switching filter output vlan-counters Checking the show firewall output: Filter: vlan-counters-ae1.0-i Counters: Name Bytes Packets vlan-14-ae1.0-i 7474383 8504 vlan-571-ae1.0-i 0 0 vlan-572-ae1.0-i 0 0 Filter: vlan-counters-ae1.0-o Counters: Name Bytes Packets vlan-14-ae1.0-o 2651051 4919 vlan-571-ae1.0-o 2057853 14731 vlan-572-ae1.0-o 644 10 Now, SNMP get: $ snmpget -v2c -cpublic 10.1.2.3 'JUNIPER-FIREWALL-MIB::jnxFWCounterByteCount."vlan-counters-ae1.0-o"."vlan-571-ae1.0-o".counter JUNIPER-FIREWALL-MIB::jnxFWCounterByteCount."vlan-counters-ae1.0-o"."vlan-571-ae1.0-o".counter = Counter64: 298848 Thanks Luke Guillory for the solution! Stanislaw ????? 2017-02-22 11:33: > Hi everybody, > Is it possible to obtain switched traffic statistics in a port+vlan > aspect via SNMP on Juniper QFX switches? > > For example, Extreme switches have a 'vlan monitor' feature: > configure ports all monitor vlan > then its counters are available by OID .1.3.6.1.4.1.1916.1.2.8.2.1.8 > and .1.3.6.1.4.1.1916.1.2.8.2.1.7 > > Does anyone know if Juniper has a similar feature? From ekgermann at semperen.com Thu Feb 23 14:08:09 2017 From: ekgermann at semperen.com (Eric Germann) Date: Thu, 23 Feb 2017 09:08:09 -0500 Subject: OSS Netflow that can use EngineID Message-ID: Colleagues, Before I go down a source code path, I wanted to get your input. I have some Linux routers I?ve built that use lots of GRE tunnels. I use ipt-netflow to export flow traffic to a collector. The issue is it seems to randomly pick an interface address and export from that. If we add a tunnel interface, it can randomly switch to that interface for exporting. I?ve played with nfsen for collection/display, but it defines a source based on IP. Since the source IP of the exporter can change, this poses a problem ipt-netflow supports EngineID, but not a specific export IP. nfsend supports a specific export IP, but not EngineID. It seems like the solution is EngineID since we could wire it down. Does anyone know of a solution to that will pull in based on EngineID and separate it that way before I chomp in to source code of one or the other patch it to support the other. TIA, EKG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From shortdudey123 at gmail.com Thu Feb 23 18:26:00 2017 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 23 Feb 2017 10:26:00 -0800 Subject: SHA1 collisions proven possisble Message-ID: Coworker passed this on to me. Looks like SHA1 hash collisions are now achievable in a reasonable time period https://shattered.io/ -Grant From cb.list6 at gmail.com Thu Feb 23 19:59:56 2017 From: cb.list6 at gmail.com (Ca By) Date: Thu, 23 Feb 2017 19:59:56 +0000 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: On Thu, Feb 23, 2017 at 10:27 AM Grant Ridder wrote: > Coworker passed this on to me. > > Looks like SHA1 hash collisions are now achievable in a reasonable time > period > https://shattered.io/ > > -Grant Good thing we "secure" our routing protocols with MD5 :) > From patrick at ianai.net Thu Feb 23 20:03:34 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 23 Feb 2017 15:03:34 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: On Feb 23, 2017, at 2:59 PM, Ca By wrote: > On Thu, Feb 23, 2017 at 10:27 AM Grant Ridder wrote: > >> Coworker passed this on to me. >> >> Looks like SHA1 hash collisions are now achievable in a reasonable time >> period >> https://shattered.io/ >> >> -Grant > > > Good thing we "secure" our routing protocols with MD5 MD5 on BGP considered Harmful. > :) :-) More seriously: The attack (or at least as much as we can glean from the blog post) cannot find a collision (file with same hash) from an arbitrary file. The attack creates two files which have the same hash, which is scary, but not as bad as it could be. For instance, someone cannot take Verisign?s root cert and create a cert which collides on SHA-1. Or at least we do not think they can. We?ll know in 90 days when Google releases the code. -- TTFN, patrick From valdis.kletnieks at vt.edu Thu Feb 23 20:57:35 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 23 Feb 2017 15:57:35 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: <14078.1487883455@turing-police.cc.vt.edu> On Thu, 23 Feb 2017 15:03:34 -0500, "Patrick W. Gilmore" said: > For instance, someone cannot take Verisign???s root cert and create a cert > which collides on SHA-1. Or at least we do not think they can. We???ll know in 90 > days when Google releases the code. >From the announce: "It is now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file." So they're able to craft two objects that collide to the same unpredictable hash, but *not* produce an object that collides to a pre-specified hash. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From jfbeam at gmail.com Thu Feb 23 22:40:42 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 23 Feb 2017 17:40:42 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: On Thu, 23 Feb 2017 15:03:34 -0500, Patrick W. Gilmore wrote: > More seriously: The attack (or at least as much as we can glean from the > blog post) cannot find a collision (file with same hash) from an > arbitrary file. The attack creates two files which have the same hash, > which is scary, but not as bad as it could be. Exactly. This is just more sky-is-falling nonsense. Of course collisions exist. They occur in every hash function. It's only marginally noteworthy when someone finds a collision. It's neat the Google has found a way to generate a pair of files with the same hash -- at colossal computational cost! However this in no way invalidates SHA-1 or documents signed by SHA-1. You still cannot take an existing document, modify it in a meaningful way, and keep the same hash. [Nor can you generate a blob to match an arbitrary hash (which would be death of all bittorrent)] From jhellenthal at dataix.net Thu Feb 23 23:11:23 2017 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 23 Feb 2017 17:11:23 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> It's actually pretty serious in Git and the banking markets where there is high usage of sha1. Considering the wide adoption of Git, this is a pretty serious issue that will only become worse ten-fold over the years. Visible abuse will not be near as widely seen as the initial shattering but escalate over much longer periods. Take it serious ? Why wouldn't you !? -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Feb 23, 2017, at 16:40, Ricky Beam wrote: > On Thu, 23 Feb 2017 15:03:34 -0500, Patrick W. Gilmore wrote: > More seriously: The attack (or at least as much as we can glean from the blog post) cannot find a collision (file with same hash) from an arbitrary file. The attack creates two files which have the same hash, which is scary, but not as bad as it could be. Exactly. This is just more sky-is-falling nonsense. Of course collisions exist. They occur in every hash function. It's only marginally noteworthy when someone finds a collision. It's neat the Google has found a way to generate a pair of files with the same hash -- at colossal computational cost! However this in no way invalidates SHA-1 or documents signed by SHA-1. You still cannot take an existing document, modify it in a meaningful way, and keep the same hash. [Nor can you generate a blob to match an arbitrary hash (which would be death of all bittorrent)] From valdis.kletnieks at vt.edu Thu Feb 23 23:21:19 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 23 Feb 2017 18:21:19 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: <23686.1487892079@turing-police.cc.vt.edu> On Thu, 23 Feb 2017 17:40:42 -0500, "Ricky Beam" said: > cost! However this in no way invalidates SHA-1 or documents signed by > SHA-1. We negotiate a contract with terms favorable to you. You sign it (or more correctly, sign the SHA-1 hash of the document). I then take your signed copy, take out the contract, splice in a different version with terms favorable to me. Since the hash didn't change, your signature on the second document remains valid. I present it in court, and the judge says "you signed it, you're stuck with the terms you signed". I think that would count as "invalidates documents signed by SHA-1", don't you? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From royce at techsolvency.com Thu Feb 23 23:24:53 2017 From: royce at techsolvency.com (Royce Williams) Date: Thu, 23 Feb 2017 14:24:53 -0900 Subject: SHA1 collisions proven possisble In-Reply-To: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> References: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> Message-ID: We just need to keep the likely timeline in mind. As I saw someone say on Twitter today ... "don't panic, just deprecate". Valeria Aurora's hash-lifecycle table is very informative (emphasis mine): http://valerieaurora.org/hash.html Reactions to stages in the life cycle of cryptographic hash functions StageExpert reactionProgrammer reactionNon-expert ("slashdotter") reaction Initial proposal Skepticism, don't recommend use in practice Wait to hear from the experts before adding to your crypto library SHA-what? Peer review Moderate effort to find holes and garner an easy publication Used by a particularly adventurous developers for specific purposes Name-drop the hash at cocktail parties to impress other geeks General acceptance Top-level researchers begin serious work on finding a weakness (and international fame) Even Microsoft is using the hash function now Flame anyone who suggests the function may be broken in our lifetime Minor weakness discovered Massive downloads of turgid pre-prints from arXiv, calls for new hash functions Start reviewing other hash functions for replacement Long semi-mathematical posts comparing the complexity of the attack to the number of protons in the universe Serious weakness discovered Tension-filled CRYPTO rump sessions! A full break is considered inevitable Migrate to new hash functions immediately, where necessary Point out that no actual collisions have been found First collision found *Uncork the champagne! Interest in the details of the construction, but no surprise* *Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them* *Explain why a simple collision attack is still useless, it's really the second pre-image attack that counts* Meaningful collisions generated on home computer How adorable! I'm busy trying to break this new hash function, though Send each other colliding X.509 certificates as pranks Claim that you always knew it would be broken Collisions generated by hand Memorize as fun party trick for next faculty mixer Boggle Try to remember how to do long division by hand Assumed to be weak but no one bothers to break No one is getting a publication out of breaking this What's this crypto library function for? Update Pokemon Wikipedia pages Royce On Thu, Feb 23, 2017 at 2:11 PM, J. Hellenthal wrote: > It's actually pretty serious in Git and the banking markets where there is > high usage of sha1. Considering the wide adoption of Git, this is a pretty > serious issue that will only become worse ten-fold over the years. Visible > abuse will not be near as widely seen as the initial shattering but > escalate over much longer periods. > > Take it serious ? Why wouldn't you !? > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Feb 23, 2017, at 16:40, Ricky Beam wrote: > > > On Thu, 23 Feb 2017 15:03:34 -0500, Patrick W. Gilmore < > patrick at ianai.net> wrote: > > More seriously: The attack (or at least as much as we can glean from the > blog post) cannot find a collision (file with same hash) from an arbitrary > file. The attack creates two files which have the same hash, which is > scary, but not as bad as it could be. > > Exactly. This is just more sky-is-falling nonsense. Of course collisions > exist. They occur in every hash function. It's only marginally noteworthy > when someone finds a collision. It's neat the Google has found a way to > generate a pair of files with the same hash -- at colossal computational > cost! However this in no way invalidates SHA-1 or documents signed by > SHA-1. You still cannot take an existing document, modify it in a > meaningful way, and keep the same hash. > > [Nor can you generate a blob to match an arbitrary hash (which would be > death of all bittorrent)] > From jlewis at lewis.org Fri Feb 24 00:28:44 2017 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 23 Feb 2017 19:28:44 -0500 (EST) Subject: SHA1 collisions proven possisble In-Reply-To: <23686.1487892079@turing-police.cc.vt.edu> References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: On Thu, 23 Feb 2017, valdis.kletnieks at vt.edu wrote: > On Thu, 23 Feb 2017 17:40:42 -0500, "Ricky Beam" said: > >> cost! However this in no way invalidates SHA-1 or documents signed by >> SHA-1. > > We negotiate a contract with terms favorable to you. You sign it (or more > correctly, sign the SHA-1 hash of the document). > > I then take your signed copy, take out the contract, splice in a different > version with terms favorable to me. Since the hash didn't change, your > signature on the second document remains valid. > > I present it in court, and the judge says "you signed it, you're stuck with > the terms you signed". > > I think that would count as "invalidates documents signed by SHA-1", don't you? Depends on the format of the document. As was just pointed out, and I almost posted earlier today, that there are collisions in SHA-1, or any hash that takes an arbitrary length input and outputs a fixed length string, should be no surprise to anyone. Infinite inputs yielding a fixed number of possible outputs. There have to be collisions. Lots of them. The question then becomes how hard is it find or craft two inputs that give the same hash or one input that gives the same hash as another? Doing this with PDFs that look similar, which can contain arbitrary bitmaps or other data is kind of a cheat / parlor trick. Doing it with an ASCII document, source code, or even something like a Word document (containing only text and formatting), and having it not be obvious upon inspection of the documents that the "imposter" document contains some "specific hash influencing 'gibberish'" would be far more disturbing. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From valdis.kletnieks at vt.edu Fri Feb 24 00:48:52 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 23 Feb 2017 19:48:52 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: <31088.1487897332@turing-police.cc.vt.edu> On Thu, 23 Feb 2017 19:28:44 -0500, Jon Lewis said: > Doing it with an ASCII document, source code, or even something like a > Word document (containing only text and formatting), and having it not be > obvious upon inspection of the documents that the "imposter" document > contains some "specific hash influencing 'gibberish'" would be far more > disturbing. Keep in mind that there's *lots* of stuff that people might want to sign that aren't flat ASCII. For instance, the video that just came out of that police officer's bodycam. If the "gibberish" is scattered across the pixels, you'll never know. And let's face it - if you need to do an inspection because you don't trust the hash to have done its job - *the hash has failed to do its job*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From patrick at ianai.net Fri Feb 24 01:56:28 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 23 Feb 2017 20:56:28 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <23686.1487892079@turing-police.cc.vt.edu> References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: <15B18A41-8051-418E-8BC3-2749590A54F6@ianai.net> On Feb 23, 2017, at 6:21 PM, valdis.kletnieks at vt.edu wrote: > On Thu, 23 Feb 2017 17:40:42 -0500, "Ricky Beam" said: > >> cost! However this in no way invalidates SHA-1 or documents signed by >> SHA-1. > > We negotiate a contract with terms favorable to you. You sign it (or more > correctly, sign the SHA-1 hash of the document). > > I then take your signed copy, take out the contract, splice in a different > version with terms favorable to me. Since the hash didn't change, your > signature on the second document remains valid. > > I present it in court, and the judge says "you signed it, you're stuck with > the terms you signed". > > I think that would count as "invalidates documents signed by SHA-1", don't you? Doesn?t work that way. According to the blog post, you can create two documents which have the same hash, but you do not know what that hash is until the algorithm finishes. You cannot create a document which matches a pre-existing hash, i.e. the one in the signed doc. Hence my comment that you can?t take Verisign?s root key and create a new key which matches the hash. -- TTFN, patrick From valdis.kletnieks at vt.edu Fri Feb 24 02:08:03 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 23 Feb 2017 21:08:03 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <15B18A41-8051-418E-8BC3-2749590A54F6@ianai.net> References: <23686.1487892079@turing-police.cc.vt.edu> <15B18A41-8051-418E-8BC3-2749590A54F6@ianai.net> Message-ID: <12541.1487902083@turing-police.cc.vt.edu> On Thu, 23 Feb 2017 20:56:28 -0500, "Patrick W. Gilmore" said: > According to the blog post, you can create two documents which have the same > hash, but you do not know what that hash is until the algorithm finishes. You > cannot create a document which matches a pre-existing hash, i.e. the one in the > signed doc. You missed the point. I generate *TWO* documents, with different terms but the same hash. I don't care if it matches anything else's hash, as long as these two documents have the same hash. I get you to sign the hash on the *ONE* document I present to you that is favorable to you. I then take your signature and transfer it to the *OTHER* document. No, I can't create a collision to a document you produced, or do anything to a document you already signed. But if I'm allowed to take it and make "minor formatting changes", or if I can just make sure I have the last turn in the back-and-forth negotiating... because the problem is if I can get you to sign a plaintext of my choosing.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From jfbeam at gmail.com Fri Feb 24 02:10:42 2017 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 23 Feb 2017 21:10:42 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <23686.1487892079@turing-police.cc.vt.edu> References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: On Thu, 23 Feb 2017 18:21:19 -0500, wrote: > We negotiate a contract with terms favorable to you. You sign it (or > more correctly, sign the SHA-1 hash of the document). > ... When you can do that in the timespan of weeks or days, get back to me. Today, it takes years to calculate a collision, and you have to start with a document specifically engineered to be modified. (such documents are easily spotted upon inspection: why does this word doc contain two documents?) You can't take any random document, modify it to say what you want, and keep the same hash. People still haven't been able to do that with MD5, and that's been "broken" for a long time. This isn't a checksum or CRC. The changing of bits in the input has an unpredictable effect on the output -- you have to do the entire hash calculation (or most of it), there is no instantaneous shortcut. They had to do 9billion billion hashes to stumble on a solution, after all. For example, one cannot recover an SSL certificate given only the hash (MD5 or SHA-1.) One cannot change the expiration date of an existing certificate while still maintaining the same hash. The fact that modern technology can perform 9BB hashes in a realistic time frame is worth noting. (that capability is usually wasted on bitcoin mining.) From patrick at ianai.net Fri Feb 24 02:16:12 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 23 Feb 2017 21:16:12 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <12541.1487902083@turing-police.cc.vt.edu> References: <23686.1487892079@turing-police.cc.vt.edu> <15B18A41-8051-418E-8BC3-2749590A54F6@ianai.net> <12541.1487902083@turing-police.cc.vt.edu> Message-ID: On Feb 23, 2017, at 9:08 PM, valdis.kletnieks at vt.edu wrote: > On Thu, 23 Feb 2017 20:56:28 -0500, "Patrick W. Gilmore" said: > >> According to the blog post, you can create two documents which have the same >> hash, but you do not know what that hash is until the algorithm finishes. You >> cannot create a document which matches a pre-existing hash, i.e. the one in the >> signed doc. > > You missed the point. I generate *TWO* documents, with different terms but the > same hash. I don't care if it matches anything else's hash, as long as these two > documents have the same hash. I get you to sign the hash on the *ONE* document I present to you > that is favorable to you. I then take your signature and transfer it to the > *OTHER* document. > > No, I can't create a collision to a document you produced, or do anything to a > document you already signed. But if I'm allowed to take it and make "minor > formatting changes", or if I can just make sure I have the last turn in the > back-and-forth negotiating... because the problem is if I can get you to sign a > plaintext of my choosing?. I did miss the point. Thanks for setting me straight. A couple things will make this slightly less useful for the attacker: 1) How many people are not going to keep a copy? Once both docs are be found to have the same hash, well, game over. 2) The headers will be very strange indeed. The way this works is Google twiddled with the headers to make them look the same. That is probably pretty obvious if you look for it. Oh, and third: Everyone should stop using SHA-1 anyway. :-) -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From valdis.kletnieks at vt.edu Fri Feb 24 02:22:21 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 23 Feb 2017 21:22:21 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: <13340.1487902941@turing-police.cc.vt.edu> On Thu, 23 Feb 2017 21:10:42 -0500, "Ricky Beam" said: > When you can do that in the timespan of weeks or days, get back to me. > Today, it takes years to calculate a collision, and you have to start with > a document specifically engineered to be modified. (such documents are > easily spotted upon inspection: why does this word doc contain two > documents?) That question never arises, because this word doc contains only one document. The *OTHER* word doc also contains only one document. > You can't take any random document, modify it to say what you > want, and keep the same hash. People still haven't been able to do that > with MD5, and that's been "broken" for a long time. That doesn't change the fact that if I can get you to sign a document I present to you, I can still have lots of fun at your expense. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From lyndon at orthanc.ca Fri Feb 24 02:29:19 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 23 Feb 2017 18:29:19 -0800 Subject: SHA1 collisions proven possisble In-Reply-To: References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: > On Feb 23, 2017, at 6:10 PM, Ricky Beam wrote: > > When you can do that in the timespan of weeks or days, get back to me. Stop thinking in the context of bits of fake news on your phone. Start thinking in the context of trans-national agreements that will soon be signed by such keys. --lyndon From dedelman at iname.com Fri Feb 24 02:51:02 2017 From: dedelman at iname.com (David Edelman) Date: Thu, 23 Feb 2017 21:51:02 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <13340.1487902941@turing-police.cc.vt.edu> References: <23686.1487892079@turing-police.cc.vt.edu> <13340.1487902941@turing-police.cc.vt.edu> Message-ID: <001d01d28e48$d639fe00$82adfa00$@iname.com> Especially if that "document" is a component of a ciphersuite exchange. --Dave -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of valdis.kletnieks at vt.edu Sent: Thursday, February 23, 2017 9:22 PM To: Ricky Beam Cc: nanog at nanog.org Subject: Re: SHA1 collisions proven possisble On Thu, 23 Feb 2017 21:10:42 -0500, "Ricky Beam" said: > When you can do that in the timespan of weeks or days, get back to me. > Today, it takes years to calculate a collision, and you have to start > with a document specifically engineered to be modified. (such > documents are easily spotted upon inspection: why does this word doc > contain two > documents?) That question never arises, because this word doc contains only one document. The *OTHER* word doc also contains only one document. > You can't take any random document, modify it to say what you want, > and keep the same hash. People still haven't been able to do that with > MD5, and that's been "broken" for a long time. That doesn't change the fact that if I can get you to sign a document I present to you, I can still have lots of fun at your expense. From israel.lugo at lugosys.com Fri Feb 24 03:31:45 2017 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 24 Feb 2017 03:31:45 +0000 Subject: Software for network modelling / documentation / GIS Message-ID: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> Hello, Does anyone have any recommendations for software to do network modelling / documentation / GIS, for a campus network? Mid-scale, a few campuses with the largest being around 25 buildings. Free/open source would be excellent, but commercial is also an option. This is a live network, with very little documentation. At the very least, I would like to document things. Ideally, though, if I were designing the software, I would like to have an intelligent model of the network from L1 to L3, serving not only for documentation but also to validate existing configuration and creating new work orders. Something like this: * conduit o has vertices (locations on the campus plant) o has a cross-section area o has links * link o has 1 port on each end o has media types (OS2, OM3, ...) o may have a cross-section area (when inside a conduit) * node o can be a switch, a router, a patch panel, an access point, a phone o has ports * circuit o can be a VLAN, or a VPN, etc o spans multiple links / nodes / circuits o has 1 port on each end (logical port, circuit endpoint) * port o has physical characteristics (E2000, SC, LC, ST, 8P8C, logical endpoint ...) o may have other properties (link speed, PoE) User Bob requests activation of the network socket D-78 in his office on building A, floor 5, room 29. An operator will use the software to connect port D-78 on the corresponding patch panel to an available port on a switch, and specify the desired VLAN (circuit). The software knows where the VLAN exists and will provide instructions on how to propagate it, taking into account redundant links. It will also provide instructions for the physical part: take one 2m patch, connect panel port D-78 to switch 2 port 17. Remember to bring the keyring because that cabinet opens with a non-standard key. If the cable guy goes on site and sees that switch 2 port 17 is already used, he will flag an inconsistency and request another port. Periodically, the software will go crawl the active equipments via SNMP or somesuch and detect existing state (port VLAN assignments, port state, link speeds, switch capacity, LLDP neighbors). If it finds any inconsistency with the configured model, it will alert an operator. Of course, all that is an ideal case. I would be happy if I can just use this for static documentation: on building A, network socket D-78 connects to switch 2 port 17, and is on VLAN 30. Does anyone know of something similar to this exist in commodity software, outside of custom solutions developed for a specific network? Anything between "purely for static documentation", and "this autodetects your cables, configures your switches and sends a robot to connect everything". Thank you and best regards, Israel G. Lugo From rdobbins at arbor.net Fri Feb 24 03:36:58 2017 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 24 Feb 2017 10:36:58 +0700 Subject: Software for network modelling / documentation / GIS In-Reply-To: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> Message-ID: On 24 Feb 2017, at 10:31, Israel G. Lugo wrote: > Does anyone know of something similar to this exist in commodity > software, outside of custom solutions developed for a specific > network? FWIW, I'm pretty sure Visio has been able to snmpwalk for many years. Some NMSes have this sort of capability, too. ----------------------------------- Roland Dobbins From mel at beckman.org Fri Feb 24 03:52:18 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 24 Feb 2017 03:52:18 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com>, Message-ID: This tool is not cheap, but I believe it can handle all the physical plant inventory and provisioning objectives you listed: http://synchronoss.com/wp-content/uploads/spatialNET.pdf -mel beckman > On Feb 23, 2017, at 7:38 PM, Roland Dobbins wrote: > >> On 24 Feb 2017, at 10:31, Israel G. Lugo wrote: >> >> Does anyone know of something similar to this exist in commodity software, outside of custom solutions developed for a specific network? > > FWIW, I'm pretty sure Visio has been able to snmpwalk for many years. Some NMSes have this sort of capability, too. > > ----------------------------------- > Roland Dobbins From hugo at slabnet.com Fri Feb 24 03:58:39 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Thu, 23 Feb 2017 19:58:39 -0800 Subject: Software for network modelling / documentation / GIS In-Reply-To: References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> Message-ID: <20170224035839.GB8654@bamboo.slabnet.com> On Fri 2017-Feb-24 10:36:58 +0700, Roland Dobbins wrote: >On 24 Feb 2017, at 10:31, Israel G. Lugo wrote: > >>Does anyone know of something similar to this exist in commodity >>software, outside of custom solutions developed for a specific >>network? > >FWIW, I'm pretty sure Visio has been able to snmpwalk for many years. >Some NMSes have this sort of capability, too. None of these necessarily get to your ideal state, but at least get you going wrt discovery for semi-dynamic documentation. netdisco: - https://metacpan.org/pod/App::Netdisco - have not used, but has been around the block. mnet: - https://github.com/MJL85/mnet - have used for rudimentary discovery - have not beat on it extensively netdot: - https://osl.uoregon.edu/redmine/projects/netdot - used at previous $dayjob - decent integration/exports for other common monitoring or network management tools /r/networking may have more. At the very least they should get you going without excessive setup time while you eval whether they fit the bill or you want something more integrated/comprehensive. >----------------------------------- >Roland Dobbins -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From nanog at yacl.net Fri Feb 24 06:59:49 2017 From: nanog at yacl.net (ML-NANOG-Stefan-Jakob) Date: Fri, 24 Feb 2017 06:59:49 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: <20170224035839.GB8654@bamboo.slabnet.com> References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <20170224035839.GB8654@bamboo.slabnet.com> Message-ID: Hi, If you want to go the full stack, start open source and to have the support and com.ext. option you can check iDoIT. Good thing is, it has also a nice API for further automation and you can use it as generall CMDB. https://www.i-doit.org/ Rgds, SJ From oscar.vives at gmail.com Fri Feb 24 12:16:38 2017 From: oscar.vives at gmail.com (Tei) Date: Fri, 24 Feb 2017 13:16:38 +0100 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: On 23 February 2017 at 20:59, Ca By wrote: > On Thu, Feb 23, 2017 at 10:27 AM Grant Ridder > wrote: > > > Coworker passed this on to me. > > > > Looks like SHA1 hash collisions are now achievable in a reasonable time > > period > > https://shattered.io/ > > > > -Grant > > > Good thing we "secure" our routing protocols with MD5 > > :) > > > > > One place that use sha1 seems to be some banking gateways. They sign the parameters of some request to authentificate the request has a valid one doing something like "sha1( MerchantID . secureCode . TerminalID . amount . exponent . moneyCode )". I have no idea how evil people would exploit collisions here, but I guest banking will move to the next hash algorithm (sha256?) and deprecate this one. This may affect more "Mom and Pa Online Shop" than bigger services. -- -- ?in del ?ensaje. From fw at deneb.enyo.de Fri Feb 24 13:06:12 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 24 Feb 2017 14:06:12 +0100 Subject: SHA1 collisions proven possisble In-Reply-To: <23686.1487892079@turing-police.cc.vt.edu> (valdis kletnieks's message of "Thu, 23 Feb 2017 18:21:19 -0500") References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: <87bmtrzqkb.fsf@mid.deneb.enyo.de> * valdis kletnieks: > We negotiate a contract with terms favorable to you. You sign it (or more > correctly, sign the SHA-1 hash of the document). > > I then take your signed copy, take out the contract, splice in a different > version with terms favorable to me. Since the hash didn't change, your > signature on the second document remains valid. > > I present it in court, and the judge says "you signed it, you're stuck with > the terms you signed". > > I think that would count as "invalidates documents signed by SHA-1", > don't you? The more immediate problem isn't that you get framed, but that someone is insinuating that you might be framing *them*, i.e. invalidation of existing signatures etc. Regarding your original scenario: You have both copies, and it is possible to analyze them and notice that they were carefully crafted to exhibit the SHA-1 collision. So it should be clear that the party who generated the document is up to to no good, and the question now is which party is responsible for the doctored document. This scenario isn't much different from abusing complex file formats to render the document differently in different contexts. There is more reliable evidence here than there is with your average disputed pen-and-paper signature. Automated processing of SHA-1-hashed data might be a problem, though. For example, a web page generator might skip proper HTML encoding if the hash of a document fragment has a known SHA-1 (assuming that this exact fragment has been checked earlier). Certification signatures (such as those found in X.509 and DNSSEC) are particularly at risk. For X.509, CAs can randomize the serial number and avoid the shared prefix, which stops these attacks AFAIK. For DNSSEC, you probably should verify that the DS records are meaningful before signing the DS RRset. If I recall correctly, there is no good way to inject randomness early into the signed data, maybe except using invalid DS records which get sorted first. From israel.lugo at lugosys.com Fri Feb 24 15:58:02 2017 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 24 Feb 2017 15:58:02 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: <20170224035839.GB8654@bamboo.slabnet.com> References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <20170224035839.GB8654@bamboo.slabnet.com> Message-ID: On 02/24/2017 03:58 AM, Hugo Slabbert wrote: > None of these necessarily get to your ideal state, but at least get > you going wrt discovery for semi-dynamic documentation. Thank you for the suggestions. I've used Netdisco in the past, older 1.x version. It was nice and useful. I've gone ahead and looked at a recent Netdisco demo and it looks even better. Doesn't seem to include passive equipment (e.g. cabling), though, but it might be useful even on its own. mnet seems to be a bit more rudimentary, more towards basic discovery indeed. As for Netdot, I've only ever used it for IPAM, but I will try it. Perhaps with some plugins it may fit the bill. Regards, Israel From israel.lugo at lugosys.com Fri Feb 24 15:59:33 2017 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 24 Feb 2017 15:59:33 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <20170224035839.GB8654@bamboo.slabnet.com> Message-ID: That actually seems nice! I tried a quick demo of the Pro version and it has a distinct DCIM-like feel. Still not sure it can place things e.g. on a floor plant but perhaps there's a way to integrate with some API. The community version does lack multiple useful features, though. I'll have to try one and the other. Thank you, Israel On 02/24/2017 06:59 AM, ML-NANOG-Stefan-Jakob wrote: > Hi, > > If you want to go the full stack, start open source and to have the support > and com.ext. option you can check iDoIT. > > Good thing is, it has also a nice API for further automation and you can > use it as generall CMDB. > > https://www.i-doit.org/ > > Rgds, SJ From uwcableguy at gmail.com Fri Feb 24 16:08:52 2017 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 24 Feb 2017 10:08:52 -0600 Subject: Cellular enabled console server Message-ID: NANOG - Are any of you running a console server to access your network equipment via a serial connection at a remote site? If so, what are you using and how much do you like it? I have a project where I need to stand up over 100 remote sites and would like a backdoor to the console just to be able to see what's going on with the equipment to hopefully avoid a truck roll for something simple like a hung device. I need 4 console ports and 1 RJ45 ethernet jack. My quick Google search landed me at BlackBox LES1204A-3G-R2, but I've never actually used such a device. This would be for use in the USA. Thank you in advance. -ben From josh at imaginenetworksllc.com Fri Feb 24 16:15:15 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 24 Feb 2017 11:15:15 -0500 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: I have been using a Sprint 3G modem to a Mikrotik (IP stuff for my use, but you can just as easily use the serial port for your needs). I pay $10/mo for a few hundred megabytes/mo. None of the Mikrotiks have 4 console ports, but you can buy 4 of them cheap. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Feb 24, 2017 at 11:08 AM, Ben Bartsch wrote: > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are you > using and how much do you like it? I have a project where I need to stand > up over 100 remote sites and would like a backdoor to the console just to > be able to see what's going on with the equipment to hopefully avoid a > truck roll for something simple like a hung device. I need 4 console ports > and 1 RJ45 ethernet jack. My quick Google search landed me at > BlackBox LES1204A-3G-R2, but I've never actually used such a device. This > would be for use in the USA. > > Thank you in advance. > > -ben > From lathama at gmail.com Fri Feb 24 16:18:12 2017 From: lathama at gmail.com (Andrew Latham) Date: Fri, 24 Feb 2017 10:18:12 -0600 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: I use https://www.lantronix.com/products/lantronix-slb/ for small sites but that looks like overkill for what you are doing. The Lantronix SLB882 has auto transfer switching (ATS) power management with port control for remote power management. On Fri, Feb 24, 2017 at 10:08 AM, Ben Bartsch wrote: > > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are you > using and how much do you like it? I have a project where I need to stand > up over 100 remote sites and would like a backdoor to the console just to > be able to see what's going on with the equipment to hopefully avoid a > truck roll for something simple like a hung device. I need 4 console ports > and 1 RJ45 ethernet jack. My quick Google search landed me at > BlackBox LES1204A-3G-R2, but I've never actually used such a device. This > would be for use in the USA. > > Thank you in advance. > > -ben -- - Andrew "lathama" Latham - From sander at steffann.nl Fri Feb 24 16:22:04 2017 From: sander at steffann.nl (Sander Steffann) Date: Fri, 24 Feb 2017 17:22:04 +0100 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: <14DDFB36-01F9-4C8F-81F3-7161720DE2B9@steffann.nl> Hi, > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are you > using and how much do you like it? I have a project where I need to stand > up over 100 remote sites and would like a backdoor to the console just to > be able to see what's going on with the equipment to hopefully avoid a > truck roll for something simple like a hung device. I need 4 console ports > and 1 RJ45 ethernet jack. My quick Google search landed me at > BlackBox LES1204A-3G-R2, but I've never actually used such a device. This > would be for use in the USA. I don't have experience with those devices, but I did just have a conversation about this with people from Opengear and they told me they have experience with it and you can even set up a OpenVPN over cellular and bridge to the ethernet port to access the management LAN. I haven't tested it yet, but at least their sales people say it works :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: From bicknell at ufp.org Fri Feb 24 16:26:08 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Feb 2017 08:26:08 -0800 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: <20170224162608.GA91541@ussenterprise.ufp.org> In a message written on Fri, Feb 24, 2017 at 10:08:52AM -0600, Ben Bartsch wrote: > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are you > using and how much do you like it? I have a project where I need to stand > up over 100 remote sites and would like a backdoor to the console just to > be able to see what's going on with the equipment to hopefully avoid a > truck roll for something simple like a hung device. I need 4 console ports > and 1 RJ45 ethernet jack. My quick Google search landed me at > BlackBox LES1204A-3G-R2, but I've never actually used such a device. This > would be for use in the USA. OpenGear all the way. Models for every need. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From israel.lugo at lugosys.com Fri Feb 24 16:36:11 2017 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 24 Feb 2017 16:36:11 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> Message-ID: <75bf7f9a-856c-31d8-8fe3-10f1df0c6065@lugosys.com> On 02/24/2017 03:52 AM, Mel Beckman wrote: > This tool is not cheap, but I believe it can handle all the physical plant inventory and provisioning objectives you listed: > > http://synchronoss.com/wp-content/uploads/spatialNET.pdf > Judging from the description on the PDF, that does seem to be very complete. Have you used the software, had a good experience? I don't have an idea of the price ballpark, but I can try to get in touch with them to find out. Regards, Israel From liam at fedney.org Fri Feb 24 16:59:25 2017 From: liam at fedney.org (L Sean Kennedy) Date: Fri, 24 Feb 2017 11:59:25 -0500 Subject: [NANOG-announce] NANOG 70 CFP Open Message-ID: NANOG Community, The NANOG Program Committee is excited to announce that we are now accepting proposals for all sessions at NANOG 70 in Bellevue, WA, June 5-7 2017. Below is a summary of key details from the Call For Presentations on the NANOG website. We look forward to seeing you in Bellevue in June! Sincerely, L Sean Kennedy NANOG PC NANOG 70 Call for Presentations The North American Network Operators' Group (NANOG) will hold its 70th conference in Bellevue, Washington. The conference takes place on June 5-7, 2017. The NANOG Program Committee seeks proposals for presentations, panels, tutorials, and track sessions for the NANOG 70 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 70 submissions can be entered on the NANOG Program Committee Tool. How To Submit The primary speaker, moderator, or author should submit a presentation proposal and an abstract on the Program Committee Tool . - Select ?Propose Talk? from the *Talks* menu - Select the NANOG 70 meeting in 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) - Provide the information requested below Upload draft slides as soon as possible so the Program Committee can understand the intended structure and level of detail covered by the talk. Draft slides are not required for a proposal to be initiated, but they are usually expected before the Program Committee can definitively accept a submission. The following information should be included in the proposal: - Author's name(s) - Professional or educational affiliation - A preferred contact email address - A preferred phone number for contact - Submission category (General Session, Panel, Tutorial, or Track) - Presentation title - Abstract - Slides in PowerPoint (preferred) or PDF format - Comments as desired including URL to materials or previous talk Timeline for submission and proposal review - Submitter enters abstract (and draft slides if possible) in Program Committee Tool . - Any time following Call for Presentations and prior to CFP 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 - Please submit initial draft slides early - Panel and Track submissions should provide topic list and intended/confirmed participants - 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 - Submitter 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 of the Program Committee will respond. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool without delay! We look forward to reviewing your submission. Key Dates For NANOG 70 Event/Deadline Date Registration for NANOG 70 Opens Friday, 02/24/2017 Agenda Outline for NANOG 70 Posted Friday, 02/24/2017 CFP Deadline: Presentation Slides Due Monday, 03/27/2017 CFP Topic List and NANOG Highlights Page Tuesday, 04/04/2017 Speaker FINAL presentation Slides to PC Tool Monday, 5/29/2017 Lightning Talk Submissions Open (Abstracts Only) Sunday, 6/4/2017 On-site Registration Sunday, 6/4/2017 Some general advice is available with our ?Guidelines for Presenting at a NANOG Meeting ?, "Present at a NANOG" and ?Tips on Giving a Talk ?. The NANOG Program Committee seeks proposals for presentations, panels, tutorial sessions, and tracks in all areas of network operations, such as: - Network Connectivity, Interconnection, and Architecture - Network Management and Configuration including Automation - Network Performance, Measurement, and Telemetry - Data Center and Physical Plant including Cooling and Power Efficiency - Network Research - Internet Governance - Routing and Switching Protocols - Network Data and Control Plane Security - Optical and Transmission Technologies - Wireless Networks - DNS, Transport, and Applications - Network Operations and Engineering Professional Experiences Submissions are welcomed by and for network operators of all sizes. Presentations about difficult problems (and interesting solutions) that you encounter in the course of your job are encouraged. The NANOG registration fee is waived for: - General Session presentations: the conference registration fee will be waived for a maximum of one speaker. - General Session panels: conference registration fees will be waived for one panel moderator and all panelists. - Tracks: conference registration fees will be waived for one moderator. - Tutorials: conference registration fees will be waived for one instructor. -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From bernat at luffy.cx Fri Feb 24 17:00:30 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 24 Feb 2017 18:00:30 +0100 Subject: SHA1 collisions proven possisble In-Reply-To: (Jon Lewis's message of "Thu, 23 Feb 2017 19:28:44 -0500 (EST)") References: <23686.1487892079@turing-police.cc.vt.edu> Message-ID: <87h93jikwh.fsf@luffy.cx> ? 23 f?vrier 2017 19:28 -0500, Jon Lewis ?: >>> cost! However this in no way invalidates SHA-1 or documents signed by >>> SHA-1. >> >> We negotiate a contract with terms favorable to you. You sign it (or more >> correctly, sign the SHA-1 hash of the document). >> >> I then take your signed copy, take out the contract, splice in a different >> version with terms favorable to me. Since the hash didn't change, your >> signature on the second document remains valid. >> >> I present it in court, and the judge says "you signed it, you're stuck with >> the terms you signed". >> >> I think that would count as "invalidates documents signed by SHA-1", don't you? > > Depends on the format of the document. As was just pointed out, and I > almost posted earlier today, that there are collisions in SHA-1, or > any hash that takes an arbitrary length input and outputs a fixed > length string, should be no surprise to anyone. Infinite inputs > yielding a fixed number of possible outputs. There have to be > collisions. Lots of them. The question then becomes how hard is it > find or craft two inputs that give the same hash or one input that > gives the same hash as another? Doing this with PDFs that look > similar, which can contain arbitrary bitmaps or other data is kind of > a cheat / parlor trick. > > Doing it with an ASCII document, source code, or even something like a > Word document (containing only text and formatting), and having it not > be obvious upon inspection of the documents that the "imposter" > document contains some "specific hash influencing 'gibberish'" would > be far more disturbing. The collision is contained in about 128 bytes. It is easy to hide this collision in almost any document. You need a common prefix between the two documents, the collision, then anything you want (you still need a lot of processing power to get the collision matching your document). It is a weakness specific to SHA-1. Another same-length hash (like RIPEMD-160) is not affected. -- The man who sets out to carry a cat by its tail learns something that will always be useful and which never will grow dim or doubtful. -- Mark Twain From bernat at luffy.cx Fri Feb 24 17:04:07 2017 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 24 Feb 2017 18:04:07 +0100 Subject: SHA1 collisions proven possisble In-Reply-To: (Patrick W. Gilmore's message of "Thu, 23 Feb 2017 21:16:12 -0500") References: <23686.1487892079@turing-police.cc.vt.edu> <15B18A41-8051-418E-8BC3-2749590A54F6@ianai.net> <12541.1487902083@turing-police.cc.vt.edu> Message-ID: <87d1e7ikqg.fsf@luffy.cx> ? 23 f?vrier 2017 21:16 -0500, "Patrick W. Gilmore" ?: > A couple things will make this slightly less useful for the attacker: > 1) How many people are not going to keep a copy? Once both docs are be > found to have the same hash, well, game over. But if a transaction is automated, it may be too late. For example, if the document is a bank transfer slip. -- "You have been in Afghanistan, I perceive." -- Sir Arthur Conan Doyle, "A Study in Scarlet" From alexsm at gmail.com Fri Feb 24 17:04:45 2017 From: alexsm at gmail.com (Alex Moura) Date: Fri, 24 Feb 2017 14:04:45 -0300 Subject: Software for network modelling / documentation / GIS In-Reply-To: <75bf7f9a-856c-31d8-8fe3-10f1df0c6065@lugosys.com> References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <75bf7f9a-856c-31d8-8fe3-10f1df0c6065@lugosys.com> Message-ID: <6D1D163B-F909-43AE-825F-BA4E978A314E@gmail.com> There is the Giiro: http://pop-ba.rnp.br/GTGIIRO Despite the content is in Brazilian Portuguese, it may work well to use Google Translator to read the overview. The software developed was funded by the Brazilian NREN. The software is maintained by a team of research and development. Alex > Em 24 de fev de 2017, ?s 13:36, Israel G. Lugo escreveu: > >> On 02/24/2017 03:52 AM, Mel Beckman wrote: >> This tool is not cheap, but I believe it can handle all the physical plant inventory and provisioning objectives you listed: >> >> http://synchronoss.com/wp-content/uploads/spatialNET.pdf >> > > Judging from the description on the PDF, that does seem to be very > complete. Have you used the software, had a good experience? > > I don't have an idea of the price ballpark, but I can try to get in > touch with them to find out. > > Regards, > Israel From mel at beckman.org Fri Feb 24 17:04:47 2017 From: mel at beckman.org (Mel Beckman) Date: Fri, 24 Feb 2017 17:04:47 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: <75bf7f9a-856c-31d8-8fe3-10f1df0c6065@lugosys.com> References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <75bf7f9a-856c-31d8-8fe3-10f1df0c6065@lugosys.com> Message-ID: <8004E9E8-71AF-4409-A8DE-DC67A587E40C@beckman.org> I?ve worked with providers that use it. I don?t know the pricing details, other than the providers were spending thousands of dollars a year just for software maintenance. But these organizations had hundreds of POPs. The software vendor likely charges based on capacity. -mel > On Feb 24, 2017, at 8:36 AM, Israel G. Lugo wrote: > > On 02/24/2017 03:52 AM, Mel Beckman wrote: >> This tool is not cheap, but I believe it can handle all the physical plant inventory and provisioning objectives you listed: >> >> http://synchronoss.com/wp-content/uploads/spatialNET.pdf >> > > Judging from the description on the PDF, that does seem to be very > complete. Have you used the software, had a good experience? > > I don't have an idea of the price ballpark, but I can try to get in > touch with them to find out. > > Regards, > Israel From patrick at ianai.net Fri Feb 24 17:11:46 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 24 Feb 2017 12:11:46 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <87d1e7ikqg.fsf@luffy.cx> References: <23686.1487892079@turing-police.cc.vt.edu> <15B18A41-8051-418E-8BC3-2749590A54F6@ianai.net> <12541.1487902083@turing-police.cc.vt.edu> <87d1e7ikqg.fsf@luffy.cx> Message-ID: On Feb 24, 2017, at 12:04 PM, Vincent Bernat wrote: > ? 23 f?vrier 2017 21:16 -0500, "Patrick W. Gilmore" : > >> A couple things will make this slightly less useful for the attacker: >> 1) How many people are not going to keep a copy? Once both docs are be >> found to have the same hash, well, game over. > > But if a transaction is automated, it may be too late. For example, if > the document is a bank transfer slip. If I can control the bank side of presenting an automated transfer slip, I really don?t need to worry about SHA-1 collisions. I already have all your money. -- TTFN, patrick From israel.lugo at lugosys.com Fri Feb 24 17:28:03 2017 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Fri, 24 Feb 2017 17:28:03 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: <6D1D163B-F909-43AE-825F-BA4E978A314E@gmail.com> References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <75bf7f9a-856c-31d8-8fe3-10f1df0c6065@lugosys.com> <6D1D163B-F909-43AE-825F-BA4E978A314E@gmail.com> Message-ID: <24435ccf-c3ad-d6c1-c0cc-5a49a542fdc7@lugosys.com> Hey, that's really interesting! I'm from Portugal, so the language isn't a problem ;) >From the overview, it seems to be more focused on the passive infra, but perhaps there may be room for developing a campus side and active equipments. I didn't find a way to access the demo, but I'll get in touch with them to see if we can get some cooperation going. My need is actually for a uni, so it would be a nice touch if we work together with an NREN. Thanks, Israel On 02/24/2017 05:04 PM, Alex Moura wrote: > There is the Giiro: > > http://pop-ba.rnp.br/GTGIIRO > > Despite the content is in Brazilian Portuguese, it may work well to > use Google Translator to read the overview. > > The software developed was funded by the Brazilian NREN. The software > is maintained by a team of research and development. > > Alex > > Em 24 de fev de 2017, ?s 13:36, Israel G. Lugo > > escreveu: > >> On 02/24/2017 03:52 AM, Mel Beckman wrote: >>> This tool is not cheap, but I believe it can handle all the physical >>> plant inventory and provisioning objectives you listed: >>> >>> http://synchronoss.com/wp-content/uploads/spatialNET.pdf >>> >> >> Judging from the description on the PDF, that does seem to be very >> complete. Have you used the software, had a good experience? >> >> I don't have an idea of the price ballpark, but I can try to get in >> touch with them to find out. >> >> Regards, >> Israel From cscora at apnic.net Fri Feb 24 18:02:45 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Feb 2017 04:02:45 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170224180245.D9810C44A1@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, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG 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 25 Feb, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 637688 Prefixes after maximum aggregation (per Origin AS): 248290 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 307053 Total ASes present in the Internet Routing Table: 56336 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 48757 Origin ASes announcing only one prefix: 21715 Transit ASes present in the Internet Routing Table: 7579 Transit-only ASes present in the Internet Routing Table: 218 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 41 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 72 Numnber of instances of unregistered ASNs: 73 Number of 32-bit ASNs allocated by the RIRs: 17465 Number of 32-bit ASNs visible in the Routing Table: 13551 Prefixes from 32-bit ASNs in the Routing Table: 54921 Number of bogon 32-bit ASNs visible in the Routing Table: 48 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 401 Number of addresses announced to Internet: 2834795780 Equivalent to 168 /8s, 247 /16s and 141 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.5 Total number of prefixes smaller than registry allocations: 213138 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 174301 Total APNIC prefixes after maximum aggregation: 49850 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 173626 Unique aggregates announced from the APNIC address blocks: 71559 APNIC Region origin ASes present in the Internet Routing Table: 7882 APNIC Prefixes per ASN: 22.03 APNIC Region origin ASes announcing only one prefix: 2212 APNIC Region transit ASes present in the Internet Routing Table: 1126 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2717 Number of APNIC addresses announced to Internet: 760730500 Equivalent to 45 /8s, 87 /16s and 211 /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-137529 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: 193820 Total ARIN prefixes after maximum aggregation: 93061 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 196248 Unique aggregates announced from the ARIN address blocks: 90025 ARIN Region origin ASes present in the Internet Routing Table: 17810 ARIN Prefixes per ASN: 11.02 ARIN Region origin ASes announcing only one prefix: 6646 ARIN Region transit ASes present in the Internet Routing Table: 1773 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1794 Number of ARIN addresses announced to Internet: 1105362080 Equivalent to 65 /8s, 226 /16s and 124 /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-397212 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: 170431 Total RIPE prefixes after maximum aggregation: 84028 RIPE Deaggregation factor: 2.03 Prefixes being announced from the RIPE address blocks: 165689 Unique aggregates announced from the RIPE address blocks: 100187 RIPE Region origin ASes present in the Internet Routing Table: 23741 RIPE Prefixes per ASN: 6.98 RIPE Region origin ASes announcing only one prefix: 10992 RIPE Region transit ASes present in the Internet Routing Table: 3368 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5585 Number of RIPE addresses announced to Internet: 709973120 Equivalent to 42 /8s, 81 /16s and 84 /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-207259 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: 82464 Total LACNIC prefixes after maximum aggregation: 17605 LACNIC Deaggregation factor: 4.68 Prefixes being announced from the LACNIC address blocks: 83647 Unique aggregates announced from the LACNIC address blocks: 38172 LACNIC Region origin ASes present in the Internet Routing Table: 5636 LACNIC Prefixes per ASN: 14.84 LACNIC Region origin ASes announcing only one prefix: 1539 LACNIC Region transit ASes present in the Internet Routing Table: 1033 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3163 Number of LACNIC addresses announced to Internet: 171272288 Equivalent to 10 /8s, 53 /16s and 104 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + 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: 16566 Total AfriNIC prefixes after maximum aggregation: 3688 AfriNIC Deaggregation factor: 4.49 Prefixes being announced from the AfriNIC address blocks: 18077 Unique aggregates announced from the AfriNIC address blocks: 6760 AfriNIC Region origin ASes present in the Internet Routing Table: 1023 AfriNIC Prefixes per ASN: 17.67 AfriNIC Region origin ASes announcing only one prefix: 326 AfriNIC Region transit ASes present in the Internet Routing Table: 197 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 292 Number of AfriNIC addresses announced to Internet: 87002112 Equivalent to 5 /8s, 47 /16s and 140 /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 5554 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3733 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2988 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2746 11133 744 KIXS-AS-KR Korea Telecom, KR 9829 2717 1501 541 BSNL-NIB National Internet Backbone, IN 9808 2288 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2065 421 219 TATACOMM-AS TATA Communications formerl 45899 1883 1303 102 VNPT-AS-VN VNPT Corp, VN 4808 1650 1786 448 CHINA169-BJ China Unicom Beijing Provin 9583 1558 120 534 SIFY-AS-IN Sify Limited, IN 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 22773 3639 2968 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3308 1333 83 SHAW - Shaw Communications Inc., CA 18566 2189 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2063 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1972 2038 403 CHARTER-NET-HKY-NC - Charter Communicat 209 1726 5067 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1705 3321 555 AMAZON-02 - Amazon.com, Inc., US 30036 1692 318 454 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1681 852 227 ITCDELTA - Earthlink, Inc., US 701 1582 10600 655 UUNET - MCI Communications Services, In 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 39891 3334 171 18 ALJAWWALSTC-AS , SA 20940 3027 1131 2142 AKAMAI-ASN1 , US 9121 2642 1691 18 TTNET , TR 34984 1990 327 381 TELLCOM-AS , TR 13188 1653 99 59 TRIOLAN , UA 8551 1604 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12479 1497 1033 50 UNI2-AS , ES 6849 1303 355 22 UKRTELNET , UA 9198 1274 352 24 KAZTELECOM-AS , KZ 12389 1268 1214 490 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3527 543 208 Telmex Colombia S.A., CO 26615 3052 2330 44 Tim Celular S.A., BR 8151 2498 3378 544 Uninet S.A. de C.V., MX 11830 1798 368 66 Instituto Costarricense de Electricidad 6503 1569 437 53 Axtel, S.A.B. de C.V., MX 7303 1548 994 253 Telecom Argentina S.A., AR 6147 1265 377 27 Telefonica del Peru S.A.A., PE 28573 1074 2285 182 CLARO S.A., BR 3816 1004 480 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11664 979 280 36 Techtel LMDS Comunicaciones Interactiva 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 1299 399 42 LINKdotNET-AS, EG 36903 717 360 125 MT-MPLS, MA 37611 695 67 6 Afrihost, ZA 36992 606 1373 25 ETISALAT-MISR, EG 24835 491 722 14 RAYA-AS, EG 8452 436 1474 16 TE-AS TE-AS, EG 37492 392 316 74 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 328 35 6 WANANCHI-KE, KE 2018 273 327 74 TENET-1, ZA 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 4538 5554 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3733 391 256 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3639 2968 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3527 543 208 Telmex Colombia S.A., CO 39891 3334 171 18 ALJAWWALSTC-AS , SA 6327 3308 1333 83 SHAW - Shaw Communications Inc., CA 26615 3052 2330 44 Tim Celular S.A., BR 20940 3027 1131 2142 AKAMAI-ASN1 , US 17974 2988 905 72 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2746 11133 744 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3639 3489 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3733 3477 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3527 3319 Telmex Colombia S.A., CO 39891 3334 3316 ALJAWWALSTC-AS , SA 6327 3308 3225 SHAW - Shaw Communications Inc., CA 26615 3052 3008 Tim Celular S.A., BR 17974 2988 2916 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 9121 2642 2624 TTNET , TR 9808 2288 2255 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2717 2176 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65555 UNALLOCATED 37.142.172.0/24 21450 MIRS-AS , IL Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG 41.73.21.0/24 37004 Suburban-Broadband-AS, NG 41.73.22.0/24 37004 Suburban-Broadband-AS, NG 41.73.23.0/24 37004 Suburban-Broadband-AS, NG 41.76.232.0/21 203496 AB-TELECOM , RU 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:16 /9:13 /10:36 /11:103 /12:277 /13:537 /14:1046 /15:1797 /16:13188 /17:7772 /18:13181 /19:24802 /20:38268 /21:41054 /22:74525 /23:63021 /24:356688 /25:558 /26:415 /27:294 /28:34 /29:18 /30:18 /31:1 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3104 3308 SHAW - Shaw Communications Inc., CA 39891 2896 3334 ALJAWWALSTC-AS , SA 22773 2833 3639 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 26615 2568 3052 Tim Celular S.A., BR 18566 2082 2189 MEGAPATH5-US - MegaPath Corporation, US 9121 1854 2642 TTNET , TR 30036 1503 1692 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1451 3527 Telmex Colombia S.A., CO 13188 1377 1653 TRIOLAN , UA 6389 1372 2063 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1584 2:837 4:25 5:2460 6:34 8:1051 12:1811 13:83 14:1778 15:22 16:2 17:107 18:128 19:1 20:54 23:2017 24:1857 25:2 27:2375 31:1870 32:89 33:4 34:1 35:19 36:359 37:2541 38:1307 39:43 40:99 41:2862 42:451 43:1926 44:63 45:2371 46:2623 47:111 49:1215 50:950 51:18 52:746 54:357 55:6 56:4 57:41 58:1616 59:990 60:389 61:1938 62:1504 63:1924 64:4568 65:2177 66:4446 67:2228 68:1189 69:3321 70:1302 71:571 72:2137 74:2615 75:400 76:411 77:1444 78:1686 79:1281 80:1359 81:1404 82:980 83:724 84:860 85:1767 86:482 87:1133 88:802 89:2050 90:209 91:6132 92:995 93:2378 94:2367 95:2829 96:561 97:357 98:938 99:83 100:153 101:1239 103:13756 104:2760 105:156 106:481 107:1554 108:794 109:2601 110:1288 111:1685 112:1153 113:1322 114:1035 115:1734 116:1766 117:1656 118:2039 119:1571 120:936 121:1093 122:2327 123:2040 124:1537 125:1811 128:706 129:620 130:412 131:1361 132:517 133:190 134:530 135:214 136:506 137:412 138:1853 139:500 140:367 141:526 142:731 143:881 144:761 145:167 146:1028 147:657 148:1368 149:572 150:691 151:946 152:725 153:313 154:759 155:972 156:552 157:600 158:446 159:1423 160:567 161:736 162:2474 163:530 164:787 165:1156 166:375 167:1256 168:2528 169:742 170:2842 171:278 172:947 173:1833 174:800 175:727 176:1778 177:4299 178:2469 179:1620 180:2173 181:2012 182:2215 183:1042 184:832 185:8866 186:3180 187:2650 188:2379 189:1824 190:8111 191:1915 192:9292 193:5761 194:4629 195:3836 196:1943 197:1298 198:5571 199:5836 200:7415 201:4112 202:10188 203:9877 204:4453 205:2772 206:2989 207:3137 208:3984 209:3940 210:3919 211:2115 212:2847 213:2482 214:863 215:64 216:5859 217:2006 218:834 219:615 220:1695 221:896 222:723 223:1150 End of report From selliott at getunwired.com Fri Feb 24 20:13:56 2017 From: selliott at getunwired.com (Shon Elliott) Date: Fri, 24 Feb 2017 20:13:56 +0000 Subject: Akamai Contact Message-ID: <2FC66B6EEF733844895E94A7FEE4FA52076D8E95@mbx032-e1-va-4.exch032.serverpod.net> Hi NANOG, Is there anyone that has any contact information for someone in Akamai's Abuse department or if anyone from Akamai is monitoring NANOG that could get in touch with me off-list, please? Thank you. Kind Regards, Shon Elliott, KK6TOO selliott at getunwired.com From selliott at getunwired.com Fri Feb 24 20:34:09 2017 From: selliott at getunwired.com (Shon Elliott) Date: Fri, 24 Feb 2017 20:34:09 +0000 Subject: Akamai Contact In-Reply-To: References: <2FC66B6EEF733844895E94A7FEE4FA52076D8E95@mbx032-e1-va-4.exch032.serverpod.net> Message-ID: <2FC66B6EEF733844895E94A7FEE4FA52076D9217@mbx032-e1-va-4.exch032.serverpod.net> Thanks, Tim! ? E-mail sent. Kind Regards, Shon Elliott, KK6TOO Level 3 IP/Routing/Security Network Engineer [unwired-new-logo] (559) 476-9463 ? Cell (559) 261-4444 x 129 ? Office (559) 943-1025 ? Direct selliott at getunwired.com www.getunwired.com From: Tim April [mailto:timapril at gmail.com] Sent: Friday, February 24, 2017 12:19 PM To: Shon Elliott Cc: North American Network Operators' Group Subject: Re: Akamai Contact Replied off-list --tim On Fri, Feb 24, 2017 at 3:13 PM, Shon Elliott > wrote: Hi NANOG, Is there anyone that has any contact information for someone in Akamai's Abuse department or if anyone from Akamai is monitoring NANOG that could get in touch with me off-list, please? Thank you. Kind Regards, Shon Elliott, KK6TOO selliott at getunwired.com> From kraig at enguity.com Fri Feb 24 22:10:47 2017 From: kraig at enguity.com (Kraig Beahn) Date: Fri, 24 Feb 2017 17:10:47 -0500 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: Netcomm NWL?25?02 Verizon LTE Router paired with a DLI SS20 gives you access to 20 serial ports natively from the NWL, without the use of USB or an intermediate technology between the router, end device and LTE interface thus signifinactly reducing the potential for an LTE communications failure, typical of external USB devices/routers. We have been deploying these on our Verizon Wireless private network for about six months now, and have been extremely impressed thus far. In addition, the NWL also has multiple GPIO's native to the platform, a WWAN-LTE (routable DMNR) ethernet port, usb port, etc. On our VZW MPN contract, each site is down to $5.00/MRC. Just have to have a minimum of 25 device on the contract to reach that pricing level. The NWL retails for $199.00 The SS20 retails for $149.00 On Feb 24, 2017 11:10 AM, "Ben Bartsch" wrote: > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are you > using and how much do you like it? I have a project where I need to stand > up over 100 remote sites and would like a backdoor to the console just to > be able to see what's going on with the equipment to hopefully avoid a > truck roll for something simple like a hung device. I need 4 console ports > and 1 RJ45 ethernet jack. My quick Google search landed me at > BlackBox LES1204A-3G-R2, but I've never actually used such a device. This > would be for use in the USA. > > Thank you in advance. > > -ben > From rsk at gsp.org Fri Feb 24 22:28:52 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 24 Feb 2017 17:28:52 -0500 Subject: Fwd: Serious Cloudflare bug exposed a potpourri of secret customer data Message-ID: <20170224222852.GA644@gsp.org> (h/t to Richard Forno) After you're done reading the Ars Technica article excerpted and linked below, you may also want to read: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory https://news.ycombinator.com/item?id=13718752 and, as background: CloudFlare, We Have A Problem http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ and then perhaps consider this comment from the Ycombinator thread: Where would you even start to address this? Everything you've been serving is potentially compromised, API keys, sessions, personal information, user passwords, the works. You've got no idea what has been leaked. Should you reset all your user passwords, cycle all or your keys, notify all your customers that there data may have been stolen? My second thought after relief was the realization that even as a consumer I'm affected by this, my password manager has > 100 entries what percentage of them are using CloudFlare? Should I change all my passwords? ---rsk ----- Forwarded message from Richard Forno ----- > From: Richard Forno > Date: Fri, 24 Feb 2017 07:30:21 -0500 > To: Infowarrior List > Subject: [Infowarrior] - Serious Cloudflare bug exposed a potpourri of > secret customer data > > Serious Cloudflare bug exposed a potpourri of secret customer data > > Service used by 5.5 million websites may have leaked passwords and authentication tokens. > > Dan Goodin - 2/23/2017, 8:35 PM > > Cloudflare, a service that helps optimize the security and performance of > more than 5.5 million websites, warned customers today that a recently > fixed software bug exposed a range of sensitive information that could > have included passwords, and cookies and tokens used to authenticate > users. > > A combination of factors made the bug particularly severe. First, the > leakage may have been active since September 22, nearly five months > before it was discovered, although the greatest period of impact was > from February 13 and February 18. Second, some of the highly sensitive > data that was leaked was cached by Google and other search engines. The > result was that for the entire time the bug was active, hackers had > the ability to access the data in real-time, by making Web requests > to affected websites, and to access some of the leaked data later by > crafting queries on search engines. > > "The bug was serious because the leaked memory could contain private > information and because it had been cached by search engines," Cloudflare > CTO John Graham-Cumming wrote in a blog post published Thursday. "We > are disclosing this problem now as we are satisfied that search engine > caches have now been cleared of sensitive information. We have also > not discovered any evidence of malicious exploits of the bug or other > reports of its existence." > > The leakage was the result of a bug in an HTML parser chain Cloudflare > uses to modify Web pages as they pass through the service's edge > servers. The parser performs a variety of tasks, such as inserting Google > Analytics tags, converting HTTP links to the more secure HTTPS variety, > obfuscating email addresses, and excluding parts of a page from malicious > Web bots. When the parser was used in combination with three Cloudflare > features???e-mail obfuscation, server-side Cusexcludes, and Automatic > HTTPS Rewrites???it caused Cloudflare edge servers to leak pseudo random > memory contents into certain HTTP responses. > < - > > > https://arstechnica.com/security/2017/02/serious-cloudflare-bug-exposed-a-potpourri-of-secret-customer-data/ > From A.L.M.Buxey at lboro.ac.uk Sat Feb 25 12:38:00 2017 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Sat, 25 Feb 2017 12:38:00 +0000 Subject: Cellular enabled console server In-Reply-To: <20170224162608.GA91541@ussenterprise.ufp.org> References: <20170224162608.GA91541@ussenterprise.ufp.org> Message-ID: <20170225123800.GA29533@lboro.ac.uk> Hi, > OpenGear all the way. Models for every need. +1 OpenGear all the time - just ensure you are patching/manageing them(!) alan From richard.hesse at weebly.com Sat Feb 25 17:26:28 2017 From: richard.hesse at weebly.com (Richard Hesse) Date: Sat, 25 Feb 2017 09:26:28 -0800 Subject: SHA1 collisions proven possisble In-Reply-To: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> References: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> Message-ID: Git prefixes blobs with its own data. You're not going to break git with a SHA-1 binary collision. However, svn is very vulnerable to breaking. On Thu, Feb 23, 2017 at 3:11 PM, J. Hellenthal wrote: > It's actually pretty serious in Git and the banking markets where there is > high usage of sha1. Considering the wide adoption of Git, this is a pretty > serious issue that will only become worse ten-fold over the years. Visible > abuse will not be near as widely seen as the initial shattering but > escalate over much longer periods. > > Take it serious ? Why wouldn't you !? > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Feb 23, 2017, at 16:40, Ricky Beam wrote: > > > On Thu, 23 Feb 2017 15:03:34 -0500, Patrick W. Gilmore < > patrick at ianai.net> wrote: > > More seriously: The attack (or at least as much as we can glean from the > blog post) cannot find a collision (file with same hash) from an arbitrary > file. The attack creates two files which have the same hash, which is > scary, but not as bad as it could be. > > Exactly. This is just more sky-is-falling nonsense. Of course collisions > exist. They occur in every hash function. It's only marginally noteworthy > when someone finds a collision. It's neat the Google has found a way to > generate a pair of files with the same hash -- at colossal computational > cost! However this in no way invalidates SHA-1 or documents signed by > SHA-1. You still cannot take an existing document, modify it in a > meaningful way, and keep the same hash. > > [Nor can you generate a blob to match an arbitrary hash (which would be > death of all bittorrent)] > From valdis.kletnieks at vt.edu Sat Feb 25 22:23:21 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 25 Feb 2017 17:23:21 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> Message-ID: <87698.1488061401@turing-police.cc.vt.edu> On Sat, 25 Feb 2017 09:26:28 -0800, Richard Hesse said: > Git prefixes blobs with its own data. You're not going to break git with a > SHA-1 binary collision. However, svn is very vulnerable to breaking. And here's the proof-of-concept for svn breakage. Somebody managed to make the WebKit svn totally lose its mind by uploading the two PoC PDFs.... https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From mysidia at gmail.com Sat Feb 25 22:44:13 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 25 Feb 2017 16:44:13 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: On Thu, Feb 23, 2017 at 2:03 PM, Patrick W. Gilmore wrote: > For instance, someone cannot take Verisign?s root cert and create a cert which collides > on SHA-1. Or at least we do not think they can. We?ll know in 90 days when > Google releases the code. Maybe. If you assume that no SHA attack was known to anybody at the time the Verisign cert was originally created, And that the process used to originally create Verisign's root cert was not tainted to leverage such attack. If it was tainted, then maybe there's another version of the certificate that was constructed with a different Subject name and Subject public key, but the same SHA1 hash, and same Issuer Name and same Issuer Public Key. > -- > TTFN, -- -JH From ryan.g at atwgpc.net Sun Feb 26 05:27:47 2017 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Sat, 25 Feb 2017 23:27:47 -0600 Subject: Cellular enabled console server In-Reply-To: <20170225123800.GA29533@lboro.ac.uk> References: <20170224162608.GA91541@ussenterprise.ufp.org> <20170225123800.GA29533@lboro.ac.uk> Message-ID: > +1 OpenGear all the time - just ensure you are patching/manageing them(!) Why do you say that? I'd love some details before buying opengear. On Sat, Feb 25, 2017 at 6:38 AM, wrote: > Hi, > > > OpenGear all the way. Models for every need. > > +1 OpenGear all the time - just ensure you are patching/manageing them(!) > > alan > From sunyucong at gmail.com Sun Feb 26 05:41:25 2017 From: sunyucong at gmail.com (Yucong Sun) Date: Sun, 26 Feb 2017 05:41:25 +0000 Subject: Cellular enabled console server In-Reply-To: References: <20170224162608.GA91541@ussenterprise.ufp.org> <20170225123800.GA29533@lboro.ac.uk> Message-ID: opengear is just atom based linux?at least the one i used. On Sun, Feb 26, 2017 at 1:29 PM Ryan Gelobter wrote: > > +1 OpenGear all the time - just ensure you are patching/manageing > them(!) > > Why do you say that? I'd love some details before buying opengear. > > On Sat, Feb 25, 2017 at 6:38 AM, wrote: > > > Hi, > > > > > OpenGear all the way. Models for every need. > > > > +1 OpenGear all the time - just ensure you are patching/manageing > them(!) > > > > alan > > > From nagarjun.govindraj at imaginea.com Sun Feb 26 12:12:38 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Sun, 26 Feb 2017 12:12:38 +0000 Subject: BGP IP prefix hijack detection times Message-ID: Hi Nanog, what are the detection times for BGP IP prefix hijack detection systems adopted by community members/operators (if any) ? Regards, Nagarjun From nanog at lodpp.net Sun Feb 26 14:07:20 2017 From: nanog at lodpp.net (nanog_maillinglist) Date: Sun, 26 Feb 2017 14:07:20 +0000 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: <7fdb40abf86b4f2d9b3954f9d7d81eed@lodpp.net> Hi. I use lots of opengears boxes - mainly the Console Manager range 41xx then 71xx for "big location" with more than 8 consoles needed 550x when it's less than 8. We use them only as out-of-band access when either we have inband pbm or when a intervention is risky - so no fancy feature is needed here ( hense the CM71xx range.. ) I tried from them a cellular one ( 5504 I guess back in the days ) but the cellular cover wasn't great in the particular DC i've tested it. + it was hard to get a cellular with static IP .... So I stayed with small/cheap 10mb access for that box. short feedback: + It just works - no hardware issues so far ( in years ) - software stable. + ZTP also works okay for provisionning with XML config ( I do it with Ansible/Jinja2 ) + Support ready to help - even though we are not a huge buyer, they provide us the feature we needed right quick ( beeing able to touch the serial config as a "user" instead of admin + cisco pinout by default - no overcharge if you want the classic serial rs232 pinout - From my test, provisionning is limited to a basic config - I couln't make it work buy generating the whole setup in the .opg images. So I generated basic XML config file to make the box pings then i use ansible in RAW SSH for post-deploy. - No python on the box so for every-day update/config I need to use ansible in raw SSH mode - which is a bit dumb in 2016/17 :) - Still no that cheap for a rasp like base box Cheers, Nico -----Original Message----- From: NANOG [mailto:nanog-bounces+nanog=lodpp.net at nanog.org] On Behalf Of Ben Bartsch Sent: Friday, February 24, 2017 5:09 PM To: NANOG Subject: Cellular enabled console server NANOG - Are any of you running a console server to access your network equipment via a serial connection at a remote site? If so, what are you using and how much do you like it? I have a project where I need to stand up over 100 remote sites and would like a backdoor to the console just to be able to see what's going on with the equipment to hopefully avoid a truck roll for something simple like a hung device. I need 4 console ports and 1 RJ45 ethernet jack. My quick Google search landed me at BlackBox LES1204A-3G-R2, but I've never actually used such a device. This would be for use in the USA. Thank you in advance. -ben From davidbass570 at gmail.com Sun Feb 26 15:48:24 2017 From: davidbass570 at gmail.com (David Bass) Date: Sun, 26 Feb 2017 10:48:24 -0500 Subject: Cellular enabled console server In-Reply-To: <7fdb40abf86b4f2d9b3954f9d7d81eed@lodpp.net> References: <7fdb40abf86b4f2d9b3954f9d7d81eed@lodpp.net> Message-ID: <1179321F-5D79-4ADB-9DDE-CC2D13508F37@gmail.com> I tried to build one in the past, but didn't have much success. Anyone successfully built some and willing to give details? > On Feb 26, 2017, at 9:07 AM, nanog_maillinglist wrote: > > Hi. > > I use lots of opengears boxes - mainly the Console Manager range 41xx then 71xx for "big location" with more than 8 consoles needed > 550x when it's less than 8. > We use them only as out-of-band access when either we have inband pbm or when a intervention is risky - so no fancy feature is needed here ( hense the CM71xx range.. ) > > I tried from them a cellular one ( 5504 I guess back in the days ) but the cellular cover wasn't great in the particular DC i've tested it. > + it was hard to get a cellular with static IP .... > So I stayed with small/cheap 10mb access for that box. > > short feedback: > + It just works - no hardware issues so far ( in years ) - software stable. > + ZTP also works okay for provisionning with XML config ( I do it with Ansible/Jinja2 ) > + Support ready to help - even though we are not a huge buyer, they provide us the feature we needed right quick ( beeing able to touch the serial config as a "user" instead of admin > + cisco pinout by default - no overcharge if you want the classic serial rs232 pinout > > - From my test, provisionning is limited to a basic config - I couln't make it work buy generating the whole setup in the .opg images. > So I generated basic XML config file to make the box pings then i use ansible in RAW SSH for post-deploy. > - No python on the box so for every-day update/config I need to use ansible in raw SSH mode - which is a bit dumb in 2016/17 :) > - Still no that cheap for a rasp like base box > > Cheers, > Nico > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+nanog=lodpp.net at nanog.org] On Behalf Of Ben Bartsch > Sent: Friday, February 24, 2017 5:09 PM > To: NANOG > Subject: Cellular enabled console server > > NANOG - Are any of you running a console server to access your network equipment via a serial connection at a remote site? If so, what are you using and how much do you like it? I have a project where I need to stand up over 100 remote sites and would like a backdoor to the console just to be able to see what's going on with the equipment to hopefully avoid a truck roll for something simple like a hung device. I need 4 console ports and 1 RJ45 ethernet jack. My quick Google search landed me at BlackBox LES1204A-3G-R2, but I've never actually used such a device. This would be for use in the USA. > > Thank you in advance. > > -ben From jared at puck.nether.net Sun Feb 26 16:40:51 2017 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 26 Feb 2017 11:40:51 -0500 Subject: Cellular enabled console server In-Reply-To: <1179321F-5D79-4ADB-9DDE-CC2D13508F37@gmail.com> References: <7fdb40abf86b4f2d9b3954f9d7d81eed@lodpp.net> <1179321F-5D79-4ADB-9DDE-CC2D13508F37@gmail.com> Message-ID: I've been toying with the FreeTSERV stuff. Ping me if you are interested in some boards Jared Mauch > On Feb 26, 2017, at 10:48 AM, David Bass wrote: > > I tried to build one in the past, but didn't have much success. Anyone successfully built some and willing to give details? > >> On Feb 26, 2017, at 9:07 AM, nanog_maillinglist wrote: >> >> Hi. >> >> I use lots of opengears boxes - mainly the Console Manager range 41xx then 71xx for "big location" with more than 8 consoles needed >> 550x when it's less than 8. >> We use them only as out-of-band access when either we have inband pbm or when a intervention is risky - so no fancy feature is needed here ( hense the CM71xx range.. ) >> >> I tried from them a cellular one ( 5504 I guess back in the days ) but the cellular cover wasn't great in the particular DC i've tested it. >> + it was hard to get a cellular with static IP .... >> So I stayed with small/cheap 10mb access for that box. >> >> short feedback: >> + It just works - no hardware issues so far ( in years ) - software stable. >> + ZTP also works okay for provisionning with XML config ( I do it with Ansible/Jinja2 ) >> + Support ready to help - even though we are not a huge buyer, they provide us the feature we needed right quick ( beeing able to touch the serial config as a "user" instead of admin >> + cisco pinout by default - no overcharge if you want the classic serial rs232 pinout >> >> - From my test, provisionning is limited to a basic config - I couln't make it work buy generating the whole setup in the .opg images. >> So I generated basic XML config file to make the box pings then i use ansible in RAW SSH for post-deploy. >> - No python on the box so for every-day update/config I need to use ansible in raw SSH mode - which is a bit dumb in 2016/17 :) >> - Still no that cheap for a rasp like base box >> >> Cheers, >> Nico >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+nanog=lodpp.net at nanog.org] On Behalf Of Ben Bartsch >> Sent: Friday, February 24, 2017 5:09 PM >> To: NANOG >> Subject: Cellular enabled console server >> >> NANOG - Are any of you running a console server to access your network equipment via a serial connection at a remote site? If so, what are you using and how much do you like it? I have a project where I need to stand up over 100 remote sites and would like a backdoor to the console just to be able to see what's going on with the equipment to hopefully avoid a truck roll for something simple like a hung device. I need 4 console ports and 1 RJ45 ethernet jack. My quick Google search landed me at BlackBox LES1204A-3G-R2, but I've never actually used such a device. This would be for use in the USA. >> >> Thank you in advance. >> >> -ben From patrick at ianai.net Sun Feb 26 17:18:48 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 26 Feb 2017 12:18:48 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: Message-ID: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> On Feb 25, 2017, at 17:44, Jimmy Hess wrote: >> On Thu, Feb 23, 2017 at 2:03 PM, Patrick W. Gilmore wrote: >> >> For instance, someone cannot take Verisign?s root cert and create a cert which collides >> on SHA-1. Or at least we do not think they can. We?ll know in 90 days when >> Google releases the code. > > Maybe. If you assume that no SHA attack was known to anybody at the > time the Verisign > cert was originally created, And that the process used to originally > create Verisign's root cert > was not tainted to leverage such attack. > > If it was tainted, then maybe there's another version of the > certificate that was constructed > with a different Subject name and Subject public key, but the same > SHA1 hash, and same Issuer Name and same Issuer Public Key. I repeat something I've said a couple times in this thread: If I can somehow create two docs with the same hash, and somehow con someone into using one of them, chances are there are bigger problems than a SHA1 hash collision. If you assume I could somehow get Verisign to use a cert I created to match another cert with the same hash, why in the hell would that matter? I HAVE THE ONE VERISIGN IS USING. Game over. Valdis came up with a possible use of such documents. While I do not think there is zero utility in those instances, they are pretty small vectors compared to, say, having a root cert at a major CA. -- TTFN, patrick From nick at foobar.org Sun Feb 26 23:15:58 2017 From: nick at foobar.org (Nick Hilliard) Date: Sun, 26 Feb 2017 23:15:58 +0000 Subject: SHA1 collisions proven possisble In-Reply-To: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> Message-ID: <58B361AE.7080804@foobar.org> Patrick W. Gilmore wrote: > I repeat something I've said a couple times in this thread: If I can > somehow create two docs with the same hash, and somehow con someone > into using one of them, chances are there are bigger problems than a > SHA1 hash collision. This collision turns a theoretical aspiration into a simple matter of financials, and those financials will only reduce over time. The incident needs to be taken in the context of how md5, rc4 and other hash functions were relentlessly battered to death over time. After the first collisions are found in a hash function, exploits only improve, so NIST's advice in 2004 to retire all SHA1 usage by 2010 was sound. >From a practical point of view, the danger that this presents is hypothetical for most people right now. It's just not worth spending 6000 years of CPU time in order to steal ?1000 from someone's bank. But by the same token, there are plenty of people in the world who would be happy to invest this sort of computing power if the target were valuable enough. Nick From rbf+nanog at panix.com Sun Feb 26 23:41:47 2017 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 26 Feb 2017 17:41:47 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> Message-ID: <20170226234147.GA3408@panix.com> On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote: > > I repeat something I've said a couple times in this thread: If I can > somehow create two docs with the same hash, and somehow con someone > into using one of them, chances are there are bigger problems than a > SHA1 hash collision. > > If you assume I could somehow get Verisign to use a cert I created to > match another cert with the same hash, why in the hell would that > matter? I HAVE THE ONE VERISIGN IS USING. Game over. > > Valdis came up with a possible use of such documents. While I do not > think there is zero utility in those instances, they are pretty small > vectors compared to, say, having a root cert at a major CA. I want a google.com cert. I ask a CA to sign my fake google.com certificate. They decline, because I can't prove I control google.com. I create a cert for mydomain.com,that hashes to the same value as my fake google.com cret. I ask a CA to sign my mydomain.com cert. They do, because I can prove I control mydomain.com. Now I effectively have a signed google.com cert. Of course, SHA1 is already deprecated for this purpose, and the currently demonstrated attack isn't flexible enough to have much chance at getting a colliding certificate signed. So, practically speaking, this isn't a problem *today* (even if SHA1 were deprecated). So this is more of a "here's the sort of thing collision attacks can be used for" point, rather than "here's what you can do with this attack right now" point. -- Brett From pete at ots.utsystem.edu Mon Feb 27 02:11:16 2017 From: pete at ots.utsystem.edu (Mitcheltree, Harold B) Date: Mon, 27 Feb 2017 02:11:16 +0000 Subject: Cellular enabled console server In-Reply-To: References: <7fdb40abf86b4f2d9b3954f9d7d81eed@lodpp.net> <1179321F-5D79-4ADB-9DDE-CC2D13508F37@gmail.com>, Message-ID: http://opengear.com/solutions/smart-out-band-management Out-of-Band Management - Opengear opengear.com Smart OOB? is out-of-band access, management, auto-response and remediation for network resilience raised to a new level. The continued exponential growth and ... we are in the processes of procurement and deployment of some of the product type in link above. --pete ________________________________ From: NANOG on behalf of Jared Mauch Sent: Sunday, February 26, 2017 10:40:51 AM To: David Bass Cc: NANOG Subject: Re: Cellular enabled console server I've been toying with the FreeTSERV stuff. Ping me if you are interested in some boards Jared Mauch > On Feb 26, 2017, at 10:48 AM, David Bass wrote: > > I tried to build one in the past, but didn't have much success. Anyone successfully built some and willing to give details? > >> On Feb 26, 2017, at 9:07 AM, nanog_maillinglist wrote: >> >> Hi. >> >> I use lots of opengears boxes - mainly the Console Manager range 41xx then 71xx for "big location" with more than 8 consoles needed >> 550x when it's less than 8. >> We use them only as out-of-band access when either we have inband pbm or when a intervention is risky - so no fancy feature is needed here ( hense the CM71xx range.. ) >> >> I tried from them a cellular one ( 5504 I guess back in the days ) but the cellular cover wasn't great in the particular DC i've tested it. >> + it was hard to get a cellular with static IP .... >> So I stayed with small/cheap 10mb access for that box. >> >> short feedback: >> + It just works - no hardware issues so far ( in years ) - software stable. >> + ZTP also works okay for provisionning with XML config ( I do it with Ansible/Jinja2 ) >> + Support ready to help - even though we are not a huge buyer, they provide us the feature we needed right quick ( beeing able to touch the serial config as a "user" instead of admin >> + cisco pinout by default - no overcharge if you want the classic serial rs232 pinout >> >> - From my test, provisionning is limited to a basic config - I couln't make it work buy generating the whole setup in the .opg images. >> So I generated basic XML config file to make the box pings then i use ansible in RAW SSH for post-deploy. >> - No python on the box so for every-day update/config I need to use ansible in raw SSH mode - which is a bit dumb in 2016/17 :) >> - Still no that cheap for a rasp like base box >> >> Cheers, >> Nico >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces+nanog=lodpp.net at nanog.org] On Behalf Of Ben Bartsch >> Sent: Friday, February 24, 2017 5:09 PM >> To: NANOG >> Subject: Cellular enabled console server >> >> NANOG - Are any of you running a console server to access your network equipment via a serial connection at a remote site? If so, what are you using and how much do you like it? I have a project where I need to stand up over 100 remote sites and would like a backdoor to the console just to be able to see what's going on with the equipment to hopefully avoid a truck roll for something simple like a hung device. I need 4 console ports and 1 RJ45 ethernet jack. My quick Google search landed me at BlackBox LES1204A-3G-R2, but I've never actually used such a device. This would be for use in the USA. >> >> Thank you in advance. >> >> -ben From mpalmer at hezmatt.org Mon Feb 27 02:16:00 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 27 Feb 2017 13:16:00 +1100 Subject: SHA1 collisions proven possisble In-Reply-To: <20170226234147.GA3408@panix.com> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> Message-ID: <20170227021600.GA28832@hezmatt.org> On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote: > On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote: > > I repeat something I've said a couple times in this thread: If I can > > somehow create two docs with the same hash, and somehow con someone > > into using one of them, chances are there are bigger problems than a > > SHA1 hash collision. > > > > If you assume I could somehow get Verisign to use a cert I created to > > match another cert with the same hash, why in the hell would that > > matter? I HAVE THE ONE VERISIGN IS USING. Game over. > > > > Valdis came up with a possible use of such documents. While I do not > > think there is zero utility in those instances, they are pretty small > > vectors compared to, say, having a root cert at a major CA. > > I want a google.com cert. I ask a CA to sign my fake google.com > certificate. They decline, because I can't prove I control google.com. Even better: I want a CA cert. I convince a CA to issue me a regular, end-entity cert for `example.com` (which I control) in such a way that I can generate another cert with the same SHA1 hash, but which has `CA:TRUE` for the Basic Constraints extension. Wham! I can now generate certs for *EVERYONE*. At least until someone notices and takes away my shiny new toy... - Matt -- [M]ost of the other people here [...] drive cars that they have personally built (starting with iron ore, charcoal, and a Malaysian turn-signal tree) [...] but I wimp out on all of those points. Sometimes there are advantages to paying somebody else to do it for you. -- Matt Roberds, in the Monastery From kmedcalf at dessus.com Mon Feb 27 04:02:48 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 26 Feb 2017 21:02:48 -0700 Subject: SHA1 collisions proven possisble In-Reply-To: <20170227021600.GA28832@hezmatt.org> Message-ID: <4d232756f7c9734ba4df14c96d94beaf@mail.dessus.com> On Sunday, 26 February, 2017 19:16 Matt Palmer said: > On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote: > > On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote: > > > I repeat something I've said a couple times in this thread: If I can > > > somehow create two docs with the same hash, and somehow con someone > > > into using one of them, chances are there are bigger problems than a > > > SHA1 hash collision. > > > > > > If you assume I could somehow get Verisign to use a cert I created to > > > match another cert with the same hash, why in the hell would that > > > matter? I HAVE THE ONE VERISIGN IS USING. Game over. > > > > > > Valdis came up with a possible use of such documents. While I do not > > > think there is zero utility in those instances, they are pretty small > > > vectors compared to, say, having a root cert at a major CA. > > > > I want a google.com cert. I ask a CA to sign my fake google.com > > certificate. They decline, because I can't prove I control google.com. > > Even better: I want a CA cert. I convince a CA to issue me a regular, > end-entity cert for `example.com` (which I control) in such a way that I > can > generate another cert with the same SHA1 hash, but which has `CA:TRUE` for > the Basic Constraints extension. > > Wham! I can now generate certs for *EVERYONE*. At least until someone > notices and takes away my shiny new toy... So you would need 6000 years of computer time to compute the collision on the SHA1 signature, and how much additional time to compute the trapdoor (private) key, in order for the cert to be of any use? From randy at psg.com Mon Feb 27 04:18:20 2017 From: randy at psg.com (Randy Bush) Date: Mon, 27 Feb 2017 11:18:20 +0700 Subject: SHA1 collisions proven possisble In-Reply-To: References: <8DEE02BF-CF6E-450A-BC62-2B817FA0408D@DataIX.net> Message-ID: > Git prefixes blobs with its own data. You're not going to break git with a > SHA-1 binary collision. http://www.metzdowd.com/pipermail/cryptography/2017-February/031623.html From patrick at ianai.net Mon Feb 27 06:15:28 2017 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 27 Feb 2017 01:15:28 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <20170227021600.GA28832@hezmatt.org> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> Message-ID: <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> Composed on a virtual keyboard, please forgive typos. On Feb 26, 2017, at 21:16, Matt Palmer wrote: >> On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote: >>> On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote: >>> I repeat something I've said a couple times in this thread: If I can >>> somehow create two docs with the same hash, and somehow con someone >>> into using one of them, chances are there are bigger problems than a >>> SHA1 hash collision. >>> >>> If you assume I could somehow get Verisign to use a cert I created to >>> match another cert with the same hash, why in the hell would that >>> matter? I HAVE THE ONE VERISIGN IS USING. Game over. >>> >>> Valdis came up with a possible use of such documents. While I do not >>> think there is zero utility in those instances, they are pretty small >>> vectors compared to, say, having a root cert at a major CA. >> >> I want a google.com cert. I ask a CA to sign my fake google.com >> certificate. They decline, because I can't prove I control google.com. > > Even better: I want a CA cert. I convince a CA to issue me a regular, > end-entity cert for `example.com` (which I control) in such a way that I can > generate another cert with the same SHA1 hash, but which has `CA:TRUE` for > the Basic Constraints extension. > > Wham! I can now generate certs for *EVERYONE*. At least until someone > notices and takes away my shiny new toy... Since I have said this somewhere on the order of half a dozen times, I will assume I am missing something obvious and all of you are doing it right. So let me ask you: The attack creates two docs. You do not know the hash before the attack starts. You cannot take an existing file with a known hash and create a second file which matches the known hash. You start with nothing, run the "attack", and get two NEW docs that have the same hash. A hash which is brand new. Now, please explain how you take a cert with one hash and somehow use this attack, which creates two new docs with a new hash, to do, well, anything? In the example above, the CA knows the SHA-1 hash of the cert it issued. (We are assuming there is a CA which still does SHA-1.) How do you get that CA to believe the two OTHER certs with DIFFERENT hashes you have to create so you can have two docs with the same hash? -- TTFN, patrick From lists at eitanadler.com Mon Feb 27 06:25:20 2017 From: lists at eitanadler.com (Eitan Adler) Date: Sun, 26 Feb 2017 22:25:20 -0800 Subject: SHA1 collisions proven possisble In-Reply-To: <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> Message-ID: On 26 February 2017 at 22:15, Patrick W. Gilmore wrote: > Composed on a virtual keyboard, please forgive typos. > > On Feb 26, 2017, at 21:16, Matt Palmer wrote: >>> On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote: >>>> On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote: >>>> I repeat something I've said a couple times in this thread: If I can >>>> somehow create two docs with the same hash, and somehow con someone >>>> into using one of them, chances are there are bigger problems than a >>>> SHA1 hash collision. >>>> >>>> If you assume I could somehow get Verisign to use a cert I created to >>>> match another cert with the same hash, why in the hell would that >>>> matter? I HAVE THE ONE VERISIGN IS USING. Game over. >>>> >>>> Valdis came up with a possible use of such documents. While I do not >>>> think there is zero utility in those instances, they are pretty small >>>> vectors compared to, say, having a root cert at a major CA. >>> >>> I want a google.com cert. I ask a CA to sign my fake google.com >>> certificate. They decline, because I can't prove I control google.com. >> >> Even better: I want a CA cert. I convince a CA to issue me a regular, >> end-entity cert for `example.com` (which I control) in such a way that I can >> generate another cert with the same SHA1 hash, but which has `CA:TRUE` for >> the Basic Constraints extension. >> >> Wham! I can now generate certs for *EVERYONE*. At least until someone >> notices and takes away my shiny new toy... > > Since I have said this somewhere on the order of half a dozen times, I will assume I am missing something obvious and all of you are doing it right. > > So let me ask you: The attack creates two docs. You do not know the hash before the attack starts. You cannot take an existing file with a known hash and create a second file which matches the known hash. You start with nothing, run the "attack", and get two NEW docs that have the same hash. A hash which is brand new. > > Now, please explain how you take a cert with one hash and somehow use this attack, which creates two new docs with a new hash, to do, well, anything? 1. Create a certificate C[ert] for a single domain you control with hash h(c). 2. Create a second certificate A[ttack] marked as a certificate authority such that h(C) = h(A). 3. Have a certificate authority sign cert C 4. Present the signature for A along with A for whatever nefarious purpose you want. See a similar version of this attack here using MD5 chosen-prefix collision attack: https://www.win.tue.nl/hashclash/rogue-ca/ -- Eitan Adler From mpalmer at hezmatt.org Mon Feb 27 07:58:14 2017 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 27 Feb 2017 18:58:14 +1100 Subject: SHA1 collisions proven possisble In-Reply-To: <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> Message-ID: <20170227075814.GH28832@hezmatt.org> On Mon, Feb 27, 2017 at 01:15:28AM -0500, Patrick W. Gilmore wrote: > On Feb 26, 2017, at 21:16, Matt Palmer wrote: > > Even better: I want a CA cert. I convince a CA to issue me a regular, > > end-entity cert for `example.com` (which I control) in such a way that I can > > generate another cert with the same SHA1 hash, but which has `CA:TRUE` for > > the Basic Constraints extension. > > > > Wham! I can now generate certs for *EVERYONE*. At least until someone > > notices and takes away my shiny new toy... > > In the example above, the CA knows the SHA-1 hash of the cert it issued. > (We are assuming there is a CA which still does SHA-1.) How do you get > that CA to believe the two OTHER certs with DIFFERENT hashes you have to > create so you can have two docs with the same hash? This is doable because the data that goes into the cert is mostly predictable (or attacker controlled). The public key is provided by the attacker; the subject and sAN extension is attacker-provided, and a lot of the rest is predictable (issuer, policy OIDs, etc etc). Even the notBefore and notAfter fields are, to some degree, predictable; you can measure the average issuance delay to figure out when you need to submit your CSR(s) to get favourable timestamps, and many CAs "round" values, to make that easier. Thus, constructing a "dummy" TBSCertificate ("to-be-signed certificate") to play with isn't difficult. The mitigation to a chosen prefix attack (which is what this is) is to make the serial number a random number. The CA/Browser Forum Baseline Requirements (the agreed-upon rules between CAs and browsers) say that you need to put "at least 64 bits of randomness" into the serial number field, which supposedly mitigates this. Unfortunately, that isn't a property you can easily determine by observation, and I'll bet dollars to donuts it isn't audited, so whether that would stand up to a determined attacker is a Rumsfeldian question.. - Matt From randy at psg.com Mon Feb 27 09:03:40 2017 From: randy at psg.com (Randy Bush) Date: Mon, 27 Feb 2017 16:03:40 +0700 Subject: SHA1 collisions proven possisble In-Reply-To: References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> Message-ID: > 1. Create a certificate C[ert] for a single domain you control with hash h(c). > 2. Create a second certificate A[ttack] marked as a certificate > authority such that h(C) = h(A). > 3. Have a certificate authority sign cert C > 4. Present the signature for A along with A for whatever nefarious > purpose you want. luckily, step 2 can be done in a minute on a raspberry pi From valdis.kletnieks at vt.edu Mon Feb 27 09:14:38 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 27 Feb 2017 04:14:38 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> Message-ID: <218246.1488186878@turing-police.cc.vt.edu> On Mon, 27 Feb 2017 01:15:28 -0500, "Patrick W. Gilmore" said: > In the example above, the CA knows the SHA-1 hash of the cert it issued. (We > are assuming there is a CA which still does SHA-1.) How do you get that CA to > believe the two OTHER certs with DIFFERENT hashes you have to create so you > can have two docs with the same hash? There's only 2 certs. You generate 2 certs with the same hash, and *then* get the CA to sign one of them. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From jlewis at lewis.org Mon Feb 27 12:23:43 2017 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 27 Feb 2017 07:23:43 -0500 (EST) Subject: SHA1 collisions proven possisble In-Reply-To: <4d232756f7c9734ba4df14c96d94beaf@mail.dessus.com> References: <4d232756f7c9734ba4df14c96d94beaf@mail.dessus.com> Message-ID: On Sun, 26 Feb 2017, Keith Medcalf wrote: > So you would need 6000 years of computer time to compute the collision > on the SHA1 signature, and how much additional time to compute the > trapdoor (private) key, in order for the cert to be of any use? 1) Wasn't the 6000 years estimate from an article >10 years ago? Computers have gotten a bit faster. 2) I suspect the sort of person interested in doing this, unburdened by ethics, would have no issues using a large botnet to speed up the process. How long does it take if you have a million PCs working on the problem? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From valdis.kletnieks at vt.edu Mon Feb 27 13:39:34 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Mon, 27 Feb 2017 08:39:34 -0500 Subject: SHA1 collisions proven possisble In-Reply-To: References: <4d232756f7c9734ba4df14c96d94beaf@mail.dessus.com> Message-ID: <235866.1488202774@turing-police.cc.vt.edu> On Mon, 27 Feb 2017 07:23:43 -0500, Jon Lewis said: > On Sun, 26 Feb 2017, Keith Medcalf wrote: > > > So you would need 6000 years of computer time to compute the collision > > on the SHA1 signature, and how much additional time to compute the > > trapdoor (private) key, in order for the cert to be of any use? > > 1) Wasn't the 6000 years estimate from an article >10 years ago? > Computers have gotten a bit faster. No, Google's announcement last week said their POC took 6500 CPU-years for the first phase and 110 GPU-accelerated for the second phase. You are totally on target on your second point. A million node botnet reduces it to right around 60 hours. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From cma at cmadams.net Mon Feb 27 14:18:35 2017 From: cma at cmadams.net (Chris Adams) Date: Mon, 27 Feb 2017 08:18:35 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <218246.1488186878@turing-police.cc.vt.edu> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> Message-ID: <20170227141835.GA29888@cmadams.net> Once upon a time, valdis.kletnieks at vt.edu said: > There's only 2 certs. You generate 2 certs with the same hash, and *then* get > the CA to sign one of them. The point is that the signed cert you get back from the CA will have a different hash, and the things that they change that cause the hash to change are outside your control and prediction. -- Chris Adams From morrowc.lists at gmail.com Mon Feb 27 17:19:53 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 27 Feb 2017 12:19:53 -0500 Subject: BGP IP prefix hijack detection times In-Reply-To: References: Message-ID: you probably want to ask the people that make these systems, yes? On Sun, Feb 26, 2017 at 7:12 AM, Nagarjun Govindraj via NANOG < nanog at nanog.org> wrote: > Hi Nanog, > > what are the detection times for BGP IP prefix hijack detection systems > adopted by community members/operators (if any) ? > > Regards, > Nagarjun > From morrowc.lists at gmail.com Mon Feb 27 17:20:20 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 27 Feb 2017 12:20:20 -0500 Subject: BGP IP prefix hijack detection times In-Reply-To: References: Message-ID: Also: "How reliable are the alerts being sent?" On Mon, Feb 27, 2017 at 12:19 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > you probably want to ask the people that make these systems, yes? > > On Sun, Feb 26, 2017 at 7:12 AM, Nagarjun Govindraj via NANOG < > nanog at nanog.org> wrote: > >> Hi Nanog, >> >> what are the detection times for BGP IP prefix hijack detection systems >> adopted by community members/operators (if any) ? >> >> Regards, >> Nagarjun >> > > From nick at foobar.org Mon Feb 27 17:28:50 2017 From: nick at foobar.org (Nick Hilliard) Date: Mon, 27 Feb 2017 17:28:50 +0000 Subject: BGP IP prefix hijack detection times In-Reply-To: References: Message-ID: <58B461D2.7020301@foobar.org> Christopher Morrow wrote: > Also: "How reliable are the alerts being sent?" also: do the smtp servers which handle mail for the domain of the alerting email address use the IP address space as they're notifying about? Nick From nagarjun.govindraj at imaginea.com Tue Feb 28 05:15:34 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Tue, 28 Feb 2017 05:15:34 +0000 Subject: BGP IP prefix hijack detection times In-Reply-To: <58B461D2.7020301@foobar.org> References: <58B461D2.7020301@foobar.org> Message-ID: Well, the idea behind the mail was to know if anyone in the community are doing real time BGP IP prefix hijacking. Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes. So I wanted to know if anyone in the community are using such tools for detecting hijacks, if yes how much time does the system take to detect. Regards, Nagarjun On Mon, Feb 27, 2017 at 10:59 PM Nick Hilliard wrote: > Christopher Morrow wrote: > > Also: "How reliable are the alerts being sent?" > > also: do the smtp servers which handle mail for the domain of the > alerting email address use the IP address space as they're notifying about? > > Nick > > From morrowc.lists at gmail.com Tue Feb 28 05:47:07 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 28 Feb 2017 00:47:07 -0500 Subject: BGP IP prefix hijack detection times In-Reply-To: References: <58B461D2.7020301@foobar.org> Message-ID: On Tue, Feb 28, 2017 at 12:15 AM, Nagarjun Govindraj < nagarjun.govindraj at imaginea.com> wrote: > > Well, the idea behind the mail was to know if anyone in the community are > doing real time BGP IP prefix hijacking. > Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes. > So I wanted to know if anyone in the community are using such tools for > detecting hijacks, if yes how much time does the system take to detect. > > My guess is: "yes, people are struggling through hjjack detection problems" and: "1-3 minutes isn't as important as the time spent figuring out: 1) is the alert real (this time!), 2) what will you do about it?" Then you sink time into: "Hey remote peer of not me, could you stop accepting the prefix X/y from your 'customer' because .. clearly they are not me..." Also, maybe time to push for more RPKI deployment so you can say: "Hey peer of not me out there in the world, you note that I've a signed certificate from $RIR attesting that I'm the proper user of prefix X/y and I've created and published ROA data saying the proper origin-as for X/y is M... your customer isn't M... so, yea, please stop accepting that prefix from them? Kthxbi!" You may ALSO want to ask: "So, about that customer (and all your other customers) you DO have bgp prefix filters on their sessions, right? because the year is 2017 and that is ... table-stakes for operating a part of the global internet now... right?" -chris > > Regards, > Nagarjun > > On Mon, Feb 27, 2017 at 10:59 PM Nick Hilliard wrote: > >> Christopher Morrow wrote: >> > Also: "How reliable are the alerts being sent?" >> >> also: do the smtp servers which handle mail for the domain of the >> alerting email address use the IP address space as they're notifying >> about? >> >> Nick >> >> From hank at efes.iucc.ac.il Tue Feb 28 06:01:40 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 28 Feb 2017 08:01:40 +0200 Subject: BGP IP prefix hijack detection times In-Reply-To: References: <58B461D2.7020301@foobar.org> Message-ID: <81c86c86-d7d8-0035-f5e4-5c8b84ffa21f@efes.iucc.ac.il> On 28/02/2017 07:15, Nagarjun Govindraj via NANOG wrote: So what if you detect in 1.4 minutes of 3.1 minutes? Or even 8 minutes? What then? You certainly couldn't do anything to prevent it after 3.1 minutes. First you need to analyze whether the BGP hijack is a false positive or not. Could be the customer you are watching is testing out some cloud based anti-DDOS mitigation and is allowing some other ASN to announce their /24 (intentional). Could be the ASN on the other side of the world has implemented some BGP optimization box which announces prefixes internally to do TE but they also happen to be sending BGP updates to Dyn/BGPMON/Team Cymru/whoever. Could be the customer you are monitoring has decided to blackhole some malicious IP and has started to announce a /32 internally and they too feed BGP announcements to Dyn/BGPMON/Team Cymru/whoever. I have many other examples. After you get an announcement of a BGP hijack, you start investigating. You determine the extent of the hijack - is it localized to one geographic area or is it worldwide. Is it just you or are there thousands of other prefixes affected. After 15 minutes you sit down and write an email to the ASN doing the announcement. For that you hope whois is up to date which 60% of the time it is not. So you start scraping Google for possible email addresses to contact. After not getting a response for 24 hours you send an email to their upstream ASN (also contingent on finding proper email addresses that will respond). After waiting another day you send an email to the upstream of the upstream and you keep repeating the process until you find someone responsive. Stopping a BGP hijack does not take 1.4 minutes or 3.1 minutes. It is usually hours and sometimes days until the hijack is stopped. -Hank > Well, the idea behind the mail was to know if anyone in the community are > doing real time BGP IP prefix hijacking. > Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes. So > I wanted to know if anyone in the community are using such tools for > detecting hijacks, if yes how much time does the system take to detect. > > > Regards, > Nagarjun > > On Mon, Feb 27, 2017 at 10:59 PM Nick Hilliard wrote: > >> Christopher Morrow wrote: >>> Also: "How reliable are the alerts being sent?" >> also: do the smtp servers which handle mail for the domain of the >> alerting email address use the IP address space as they're notifying about? >> >> Nick >> >> From nagarjun.govindraj at imaginea.com Tue Feb 28 06:17:56 2017 From: nagarjun.govindraj at imaginea.com (Nagarjun Govindraj) Date: Tue, 28 Feb 2017 06:17:56 +0000 Subject: BGP IP prefix hijack detection times In-Reply-To: <81c86c86-d7d8-0035-f5e4-5c8b84ffa21f@efes.iucc.ac.il> References: <58B461D2.7020301@foobar.org> <81c86c86-d7d8-0035-f5e4-5c8b84ffa21f@efes.iucc.ac.il> Message-ID: The Goal is not to mitigate or take action against the malicious activity. Goal is to detect the hijacking event by trying to reduce false posivites as much as possible. I know false positives is one of the key factor to consider. I am just trying to distinguish between a legitimate advertisement against hijack event. Regards, Nagarjun On Tue, Feb 28, 2017 at 11:31 AM Hank Nussbacher wrote: > On 28/02/2017 07:15, Nagarjun Govindraj via NANOG wrote: > > So what if you detect in 1.4 minutes of 3.1 minutes? Or even 8 > minutes? What then? > You certainly couldn't do anything to prevent it after 3.1 minutes. > First you need to analyze whether the BGP hijack is a false positive or > not. > Could be the customer you are watching is testing out some cloud based > anti-DDOS mitigation and is allowing some other ASN to announce their > /24 (intentional). > Could be the ASN on the other side of the world has implemented some BGP > optimization box which announces prefixes internally to do TE but they > also happen to be sending BGP updates to Dyn/BGPMON/Team Cymru/whoever. > Could be the customer you are monitoring has decided to blackhole some > malicious IP and has started to announce a /32 internally and they too > feed BGP announcements to Dyn/BGPMON/Team Cymru/whoever. > I have many other examples. > After you get an announcement of a BGP hijack, you start investigating. > You determine the extent of the hijack - is it localized to one > geographic area or is it worldwide. Is it just you or are there > thousands of other prefixes affected. After 15 minutes you sit down and > write an email to the ASN doing the announcement. For that you hope > whois is up to date which 60% of the time it is not. So you start > scraping Google for possible email addresses to contact. > After not getting a response for 24 hours you send an email to their > upstream ASN (also contingent on finding proper email addresses that > will respond). > After waiting another day you send an email to the upstream of the > upstream and you keep repeating the process until you find someone > responsive. > Stopping a BGP hijack does not take 1.4 minutes or 3.1 minutes. It is > usually hours and sometimes days until the hijack is stopped. > > -Hank > > > > Well, the idea behind the mail was to know if anyone in the community are > > doing real time BGP IP prefix hijacking. > > Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes. > So > > I wanted to know if anyone in the community are using such tools for > > detecting hijacks, if yes how much time does the system take to detect. > > > > > > Regards, > > Nagarjun > > > > On Mon, Feb 27, 2017 at 10:59 PM Nick Hilliard wrote: > > > >> Christopher Morrow wrote: > >>> Also: "How reliable are the alerts being sent?" > >> also: do the smtp servers which handle mail for the domain of the > >> alerting email address use the IP address space as they're notifying > about? > >> > >> Nick > >> > >> > > > From morrowc.lists at gmail.com Tue Feb 28 17:01:00 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 28 Feb 2017 12:01:00 -0500 Subject: BGP IP prefix hijack detection times In-Reply-To: References: <58B461D2.7020301@foobar.org> <81c86c86-d7d8-0035-f5e4-5c8b84ffa21f@efes.iucc.ac.il> Message-ID: On Tue, Feb 28, 2017 at 1:17 AM, Nagarjun Govindraj < nagarjun.govindraj at imaginea.com> wrote: > > > I am just trying to distinguish between a legitimate advertisement against > hijack event. > > that's what everyone's trying to do... if you aren't trying to fix things, why do you care about them at all? From fgont at si6networks.com Tue Feb 28 23:25:25 2017 From: fgont at si6networks.com (Fernando Gont) Date: Tue, 28 Feb 2017 20:25:25 -0300 Subject: Fwd: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) In-Reply-To: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> References: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> Message-ID: <64599ca5-aa34-bbd3-9706-7d8e6b4a3cce@si6networks.com> Folks, FYI: The document is being discussed in the v6ops wg of the IETF. Looks like IETF is not going to do anything about it. But check the corresponding thread at: , since you'll have at least a few #facepalm moments. Thanks, Fernando -------- Forwarded Message -------- Subject: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) Date: Tue, 28 Feb 2017 05:13:25 -0300 From: Fernando Gont To: IPv6 Operations Folks, Based on a recent discussion regarding the problem of conveying DNS information in IPv6 networks, we have submitted this short I-D, in the hopes of getting the aforementioned problem solved. Your feedback will be appreciated. Thanks! Fernando (and co-autors) -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-host-configuration-00.txt Date: Mon, 27 Feb 2017 23:51:03 -0800 From: internet-drafts at ietf.org To: Fernando Gont , Gert Doering , Madelen Garcia Corbo , Madelen Corbo , Guillermo Gont A new version of I-D, draft-gont-v6ops-host-configuration-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-host-configuration Revision: 00 Title: On the Dynamic/Automatic Configuration of IPv6 Hosts Document date: 2017-02-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 Abstract: IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From james.d at hexhost.net Tue Feb 28 19:16:23 2017 From: james.d at hexhost.net (James DeVincentis) Date: Tue, 28 Feb 2017 13:16:23 -0600 Subject: SHA1 collisions proven possisble In-Reply-To: <20170227141835.GA29888@cmadams.net> References: <06CA245F-452B-4CF9-9F21-ADACEA08C051@ianai.net> <20170226234147.GA3408@panix.com> <20170227021600.GA28832@hezmatt.org> <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net> <218246.1488186878@turing-police.cc.vt.edu> <20170227141835.GA29888@cmadams.net> Message-ID: <96BEAFFF-A0C3-4D6A-8B5C-0073A9492B40@hexhost.net> The CA signing the cert actually changes the fingerprint (and serial number, which is what is checked on revocation lists), so this is not a viable scenario. Beyond that, SHA1 signing of certificates has long been deprecated and no new public CAs will sign a CSR and cert with SHA1. > On Feb 27, 2017, at 8:18 AM, Chris Adams wrote: > > Once upon a time, valdis.kletnieks at vt.edu said: >> There's only 2 certs. You generate 2 certs with the same hash, and *then* get >> the CA to sign one of them. > > The point is that the signed cert you get back from the CA will have a > different hash, and the things that they change that cause the hash to > change are outside your control and prediction. > > -- > Chris Adams Even with massive computing power, the tampering is still detectable since this attack does not allow for the creation of a hash collision from any arbitrary document. It requires specific manipulation of all items that result in a collision. > On Feb 27, 2017, at 7:39 AM, valdis.kletnieks at vt.edu wrote: > > On Mon, 27 Feb 2017 07:23:43 -0500, Jon Lewis said: >> On Sun, 26 Feb 2017, Keith Medcalf wrote: >> >>> So you would need 6000 years of computer time to compute the collision >>> on the SHA1 signature, and how much additional time to compute the >>> trapdoor (private) key, in order for the cert to be of any use? >> >> 1) Wasn't the 6000 years estimate from an article >10 years ago? >> Computers have gotten a bit faster. > > No, Google's announcement last week said their POC took 6500 CPU-years > for the first phase and 110 GPU-accelerated for the second phase. > > You are totally on target on your second point. A million node botnet > reduces it to right around 60 hours. From aaron1 at gvtc.com Sat Feb 25 15:49:56 2017 From: aaron1 at gvtc.com (Aaron) Date: Sat, 25 Feb 2017 09:49:56 -0600 Subject: google ipv6 routes via cogent Message-ID: <001801d28f7e$d063ac10$712b0430$@gvtc.com> Hi, I'm new to the nanog list, hope this isn't out of scope for what is usually discussed here. Cogent is telling me that I can't route through cogent to get to google ipv6 routes (particularly the well known dns addresses 2001:4860:4860::88xx) because google decided not to advertise those route to one of their mutual peers. Anyone know anything about this ? .and why it happened and when it will be resolved ? -Aaron From mike.goodwin at sep2.co.uk Sat Feb 25 07:21:48 2017 From: mike.goodwin at sep2.co.uk (Mike Goodwin) Date: Sat, 25 Feb 2017 07:21:48 +0000 Subject: Serious Cloudflare bug exposed a potpourri of secret customer data In-Reply-To: <20170224222852.GA644@gsp.org> References: <20170224222852.GA644@gsp.org> Message-ID: <99FF5A5E-1E62-44E4-A306-4053D522005F@sep2.co.uk> Useful information on potentially compromised sites due to this: https://github.com/pirate/sites-using-cloudflare Mike On 24 Feb 2017, at 10:31 pm, Rich Kulawiec > wrote: (h/t to Richard Forno) After you're done reading the Ars Technica article excerpted and linked below, you may also want to read: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory https://news.ycombinator.com/item?id=13718752 and, as background: CloudFlare, We Have A Problem http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ and then perhaps consider this comment from the Ycombinator thread: Where would you even start to address this? Everything you've been serving is potentially compromised, API keys, sessions, personal information, user passwords, the works. You've got no idea what has been leaked. Should you reset all your user passwords, cycle all or your keys, notify all your customers that there data may have been stolen? My second thought after relief was the realization that even as a consumer I'm affected by this, my password manager has > 100 entries what percentage of them are using CloudFlare? Should I change all my passwords? ---rsk ----- Forwarded message from Richard Forno > ----- From: Richard Forno > Date: Fri, 24 Feb 2017 07:30:21 -0500 To: Infowarrior List > Subject: [Infowarrior] - Serious Cloudflare bug exposed a potpourri of secret customer data Serious Cloudflare bug exposed a potpourri of secret customer data Service used by 5.5 million websites may have leaked passwords and authentication tokens. Dan Goodin - 2/23/2017, 8:35 PM Cloudflare, a service that helps optimize the security and performance of more than 5.5 million websites, warned customers today that a recently fixed software bug exposed a range of sensitive information that could have included passwords, and cookies and tokens used to authenticate users. A combination of factors made the bug particularly severe. First, the leakage may have been active since September 22, nearly five months before it was discovered, although the greatest period of impact was from February 13 and February 18. Second, some of the highly sensitive data that was leaked was cached by Google and other search engines. The result was that for the entire time the bug was active, hackers had the ability to access the data in real-time, by making Web requests to affected websites, and to access some of the leaked data later by crafting queries on search engines. "The bug was serious because the leaked memory could contain private information and because it had been cached by search engines," Cloudflare CTO John Graham-Cumming wrote in a blog post published Thursday. "We are disclosing this problem now as we are satisfied that search engine caches have now been cleared of sensitive information. We have also not discovered any evidence of malicious exploits of the bug or other reports of its existence." The leakage was the result of a bug in an HTML parser chain Cloudflare uses to modify Web pages as they pass through the service's edge servers. The parser performs a variety of tasks, such as inserting Google Analytics tags, converting HTTP links to the more secure HTTPS variety, obfuscating email addresses, and excluding parts of a page from malicious Web bots. When the parser was used in combination with three Cloudflare features???e-mail obfuscation, server-side Cusexcludes, and Automatic HTTPS Rewrites???it caused Cloudflare edge servers to leak pseudo random memory contents into certain HTTP responses. < - > https://arstechnica.com/security/2017/02/serious-cloudflare-bug-exposed-a-potpourri-of-secret-customer-data/ This email and any attachment to it are confidential. Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately. Any views or opinions expressed in this email are those of the sender only, unless otherwise stated. All copyright in any sep2 material in this email is reserved. All emails, incoming and outgoing, may be recorded by sep2 and monitored for legitimate business purposes. sep2 exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law. sep2 limited is Registered in England number 09988870, registered office sep2 limited, Swale Suite, 2nd Floor, 5 York Place, Leeds LS1 2DR From simon at linx.net Fri Feb 24 16:27:16 2017 From: simon at linx.net (Simon Woodhead) Date: Fri, 24 Feb 2017 16:27:16 +0000 Subject: Cellular enabled console server In-Reply-To: References: Message-ID: Hi Ben We run OpenGears at Simwood. They do various flavours some with 3G; we?ve used both the 3G and the ethernet variety and all worked well. Serial access is essentially ssh to the console server specifying a custom port that relates to the serial port. They also support the addition of other sensors, e.g. temperature. The smallest one is 4 ports but I can?t presently see it on their website. cheers Simon > On 24 Feb 2017, at 16:08, Ben Bartsch wrote: > > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are you > using and how much do you like it? I have a project where I need to stand > up over 100 remote sites and would like a backdoor to the console just to > be able to see what's going on with the equipment to hopefully avoid a > truck roll for something simple like a hung device. I need 4 console ports > and 1 RJ45 ethernet jack. My quick Google search landed me at > BlackBox LES1204A-3G-R2, but I've never actually used such a device. This > would be for use in the USA. > > Thank you in advance. > > -ben From Steve.Benoit at GeorgianCollege.ca Fri Feb 24 13:48:40 2017 From: Steve.Benoit at GeorgianCollege.ca (Steve Benoit) Date: Fri, 24 Feb 2017 13:48:40 +0000 Subject: Software for network modelling / documentation / GIS In-Reply-To: References: <942a104b-7d76-00cc-cb10-aa8b05758c14@lugosys.com> <20170224035839.GB8654@bamboo.slabnet.com> Message-ID: Good day Have you had a look at NEDI ? http://www.nedi.ch/ While quite Cisco centric, it can, and has been extended, to other manufacturers. I previously ran it in a multisite LAN/WAN environment and the team liked it. It lacks some of the physical layer attributes I think you want - conduit IDs and such but has layer 2 connectivity , tickets, and monitoring There is a "free" version (the previous release) and options for paid support. Steve Benoit Manager, Academic Technology, Information Technology Georgian College| One Georgian Drive | Barrie?ON |?L4M?3X9 705.728.1968,?ext. 1185 | GeorgianCollege.ca -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of ML-NANOG-Stefan-Jakob Sent: Friday, February 24, 2017 2:00 AM Cc: nanog at nanog.org Subject: Re: Software for network modelling / documentation / GIS Hi, If you want to go the full stack, start open source and to have the support and com.ext. option you can check iDoIT. Good thing is, it has also a nice API for further automation and you can use it as generall CMDB. https://www.i-doit.org/ Rgds, SJ From JTyler at fiberutilities.com Fri Feb 24 18:13:36 2017 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Fri, 24 Feb 2017 18:13:36 +0000 Subject: Cellular enabled console server In-Reply-To: <20170224162608.GA91541@ussenterprise.ufp.org> References: <20170224162608.GA91541@ussenterprise.ufp.org> Message-ID: +1 for opengear as well. We have over 100 deployed and have been a solid product as well as a good company to work with. We also setup a private network with Verizon so that our console servers would not be on the Internet. Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Leo Bicknell Sent: Friday, February 24, 2017 10:26 AM To: nanog at nanog.org Subject: Re: Cellular enabled console server In a message written on Fri, Feb 24, 2017 at 10:08:52AM -0600, Ben Bartsch wrote: > NANOG - Are any of you running a console server to access your network > equipment via a serial connection at a remote site? If so, what are > you using and how much do you like it? I have a project where I need > to stand up over 100 remote sites and would like a backdoor to the > console just to be able to see what's going on with the equipment to > hopefully avoid a truck roll for something simple like a hung device. > I need 4 console ports and 1 RJ45 ethernet jack. My quick Google > search landed me at BlackBox LES1204A-3G-R2, but I've never actually > used such a device. This would be for use in the USA. OpenGear all the way. Models for every need. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ From hgm+nanog at ip-64-139-1-69.sjc.megapath.net Wed Feb 22 12:59:53 2017 From: hgm+nanog at ip-64-139-1-69.sjc.megapath.net (Hal Murray) Date: Wed, 22 Feb 2017 04:59:53 -0800 Subject: WWV Broadcast Outages Message-ID: <20170222125953.C30D4406060@ip-64-139-1-69.sjc.megapath.net> "Majdi S. Abbas" said: > That said, I and many others "still use" WWV -- there aren't exactly a > surplus of suitable backup methods to GPS these days. Any suggestions for gear and/or software that works with WWV (or CHU)? Or general suggestions for non GPS sources of time? Dave Mills had a driver in ntpd that used a PC audio port to listen to WWV. I don't know anybody who ever used it. I think there was code to tell some brand of receiver with a serial/USB port how to change frequencies so you could use the one that worked best for that time of day. There used to be WWVB (60 KHz) receivers. The good ones phase locked to the carrier. The general rise in EMI made those close to useless in most locations. NIST finished the job when they changed the modulation format a few years ago. As far as I know, there aren't any replacements for the old gear that take advantage of the new modulation format. GPS works too well. There are some boxes that recover the time from nearby cell phone towers. I think they will stop working as the towers get upgraded to the newer protocols that use a different form of timing. That will probably take many years. But the cell phone towers depend on GPS. (You can ususlly spot the conical antenna(s) if you look around a bit.) -- These are my opinions. I hate spam. From jcotton1123 at gmail.com Wed Feb 22 23:55:30 2017 From: jcotton1123 at gmail.com (Jesse Cotton) Date: Wed, 22 Feb 2017 15:55:30 -0800 Subject: Any Github Experts online ? In-Reply-To: References: Message-ID: <50CD4AF0-91BD-4704-9B12-43505AD595C6@gmail.com> Also, performing a git clone or git pull is significantly different than downloading a tarball. Someone correct me if I am wrong but Git essentially has to reconstruct the files from its internal data structures. If you clone a large repository with a lot of history it will take longer than a smaller repository with less history. > On Feb 22, 2017, at 3:47 PM, Aaron C. de Bruyn via NANOG wrote: > > If they are using 'git pull', or 'git push' for example, they may be > accessing the data via HTTPS or SSH. > > Can your user do a 'git remote -v' and see if they are connecting via > HTTPS or SSH to assist you with troubleshooting? > > Then see if it's something specific to one or the other and if it's > specific to github or all sites. > > -A > > On Wed, Feb 22, 2017 at 3:40 PM, Bob Evans wrote: >> Hello NANOGers, >> >> I have one customer that claims that 2 out of 17 downloads using the git >> command on github's service are slow and poor on our network when compared >> to others. >> >> However, when not using the git command , but using a simple web page link >> to a large zipped file from github, its always nice and fast. Using the >> git command 8% of the time being slow is unacceptable. Github just doesnt >> responds lethargically at best. BTW, have you seen how many hex digits a >> github ticket number is ? >> >> Of course Github says try a different ISP...Customer tries to tell me >> comcast is better ! What ! I dont believe it. No help from Github NOC - we >> have asked and asked... And we peer with Github and for some reason they >> do not transmit the Prefixes of the IP range that the customer uses for >> the git command. github.com resolve IPv4 is not in the prefix list. So >> the exit is transits. >> >> I need more clues. Is it the resources the git command uses when checking >> files for dates etc ? >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >> >> From ctassisf at gmail.com Mon Feb 20 21:36:24 2017 From: ctassisf at gmail.com (=?UTF-8?Q?C=C3=A9sar_de_Tassis_Filho?=) Date: Mon, 20 Feb 2017 18:36:24 -0300 Subject: Issues with .org domain after removing DS records Message-ID: Hello, I just removed the DS records from my .org domain but the delegation is now broken due to an issue with .org's NSEC3 [1]. The domain is still signed on my authoritative nameservers because DS records on .org have 24h TTL. It is the second time I have this issue with the same domain. My registrar is Google Domains, I contacted their support but they could not help me with this issue. I also removed the DS records of 4 other domains on Google Domains but I am not seeing any issues with them, including a .info domain [2]. Do you guys have any idea on how to help me? Maybe someone from Afilias to contact me off-list? Thanks in advance, C?sar [1] http://dnsviz.net/d/z0p.org/WKtZtQ/dnssec/ [2] http://dnsviz.net/d/acessototal.info/WKtWXg/dnssec/ From cheako at mikemestnik.net Mon Feb 20 21:33:13 2017 From: cheako at mikemestnik.net (Mike Mestnik) Date: Mon, 20 Feb 2017 15:33:13 -0600 Subject: To comcast noc: gogoc IPv4 address does not reply /w ICMP unreachable. Message-ID: The app hangs waiting for a reply that will never come. >From 24.131.129.29 traceroute to ip-50-63-202-26.ip.secureserver.net (50.63.202.26), 30 hops max, 60 byte packets 1 10.0.0.3 (10.0.0.3) 8.793 ms 8.830 ms 8.833 ms 2 96.120.48.61 (96.120.48.61) 18.319 ms 22.334 ms 22.343 ms 3 et-1-2-rur01.afton.mn.minn.comcast.net (68.86.235.225) 22.579 ms 22.849 ms 22.848 ms 4 po-2-rur02.afton.mn.minn.comcast.net (68.87.174.226) 26.273 ms 26.247 ms 27.296 ms 5 be-35-ar01.roseville.mn.minn.comcast.net (162.151.54.193) 28.377 ms 32.872 ms 32.850 ms 6 4.68.71.61 (4.68.71.61) 32.508 ms 10.760 ms 10.753 ms 7 * * * 8 4.28.83.74 (4.28.83.74) 66.690 ms 66.668 ms 66.320 ms From dougm at nist.gov Tue Feb 21 16:17:14 2017 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Tue, 21 Feb 2017 16:17:14 +0000 Subject: RPKI coverage statistics Message-ID: >Date: Mon, 20 Feb 2017 05:52:17 +0000 >From: Nagarjun Govindraj >To: "nanog at nanog.org" >Subject: RPKI coverage statistics >Message-ID: > >Content-Type: text/plain; charset=UTF-8 > >Hi All, > >where can I found the current coverage of IP prefixes under RPKI system. >Stats like total prefixes issued collectively by all the organisations >like >RIR's/IANA/ISP's. >stats like prefixes coverd under RPKI system. > >The goal is to detect the BGP IP prefix hijacking using RPKI system. >I would like to know the coverage before adopting RPKI system. > >I would like to know the suggestions from the community on using this >system. > >Regards, >Nagarjun Another site with a few other statistical / adoption views: https://rpki-monitor.antd.nist.gov/ dougm ? Doug Montgomery, Mgr Internet & Scalable Systems Research at NIST/ITL/ANTD From kvicknair at reservetele.com Wed Feb 22 12:56:09 2017 From: kvicknair at reservetele.com (Kody Vicknair) Date: Wed, 22 Feb 2017 12:56:09 +0000 Subject: Juniper QFX port VLAN statistics via SNMP - is it possible? Message-ID: <26a1f169-e904-4aa0-9959-b206e03f490c@email.android.com> I haven't tried to do anything like this on ours. Getting a copy of the juniper qfx mib would be a good start. Kody Vicknair Network Engineer [cid:image9d67f5.JPG at a30b92f4.4698f933] Tel: 985.536.1214 Fax: 985.536.0300 Email: kvicknair at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Feb 22, 2017 3:34 AM, Stanislaw wrote: Hi everybody, Is it possible to obtain switched traffic statistics in a port+vlan aspect via SNMP on Juniper QFX switches? For example, Extreme switches have a 'vlan monitor' feature: configure ports all monitor vlan then its counters are available by OID .1.3.6.1.4.1.1916.1.2.8.2.1.8 and .1.3.6.1.4.1.1916.1.2.8.2.1.7 Does anyone know if Juniper has a similar feature? From sergervautour at gmail.com Mon Feb 20 20:26:00 2017 From: sergervautour at gmail.com (serge vautour) Date: Mon, 20 Feb 2017 16:26:00 -0400 Subject: 6PE on ALU Message-ID: Hello, Running into a little problem configuring 6PE on ALU7750. All prefixes in the IPv6 table except prefixes learned via my eBGP peers are getting exported via MP-BGP: group "IPV6-LU" description "6PE config" family label-ipv6 remove-private export "permitAll" peer-as 123 neighbor 10.1.2.3 exit exit policy-statement "permitAll" default-action accept exit exit This is on SROS 14. The "advertise-label ipv6" command no longer exists. "family label-ipv6" seems to do the same thing. For locally connected subnet the next hop gets set to IPv4-IPv6 mapped address. I've tried different export policies and cannot get eBGP learned IPv6 prefixes to get exported. Has anyone run into this before? Thanks, Serge