From mleber at he.net Mon Apr 1 00:19:05 2019 From: mleber at he.net (Mike Leber) Date: Sun, 31 Mar 2019 17:19:05 -0700 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <293EE676-667B-4984-A37F-DA077D175E25@rivervalleyinternet.net> References: <293EE676-667B-4984-A37F-DA077D175E25@rivervalleyinternet.net> Message-ID: <3b39c152-6f68-d400-44ca-ccfac350a0c5@he.net> You mean like pulse dialing and stepper relays vs touch tone dialing? I'm sure there were people that felt the same about that too. That mindset is simply you already paid for the old stuff, it's working fine, you would rather not understand or think about the problems the new tech solves or benefits it provides. To be motivated to do something you have to have a reason or goal. Most all goal seeking behavior in business can be put two buckets: 1) revenue at risk and 2) revenue enabled. i.e. one is going away from pain and the other is going towards a reward. Making a plan is based on your perception of current and future events. At scale the market does a whole lot of testing of economic fitness functions that are the result of the decisions of each of our companies makes about what all of this means. If you were an independent telephone company around 1955 to 1965 with relay based switches deciding when and if and why to use DTMF or a variant, I'm sure there was exactly the same dynamic.  Situation: telecom company with old technology that was still working trying to decide what to do. I mean, your phones still worked on that day you were starting out the window musing about it.  Why not just go to lunch and forget about it? While you were out to lunch after putting off deciding what to do about your relay switches around the same period of time the global phone system was growing at a breakneck speed and the first submarine transatlantic telephone cable system was getting run. Some people won't like this story because it is about making business decisions about technology when you aren't sure of the reasons to either do or not do something and isn't arguing about some specific concrete reason to add IPv6 support like: 1) the world has more people than IPv4 addresses or something 2) you work for a big company and would like your revenue from the Internet to keep growing over the next 10 years uninterrupted due the risk of not supporting IPv6 and this is too trivial of a technology decision because the incremental cost is so small (compared to all the other fires you have burning) to just add support anyway.  I get where you are coming from. On 3/31/19 4:19 PM, Matt Hoppes wrote: > Going to play devils advocate.  > > If frontier has a ton of ipv4 addresses, what benefit is there to them > in rolling out ipv6? > > What benefit is there to you? > > On Mar 31, 2019, at 7:11 PM, C. A. Fillekes > wrote: > >> >> Still it's pretty darn good having real broadband on the farm.  One >> thing at a time.  >> >> But, let's start thinking about ways to get Frontier up to speed on >> the IPv6 thing. >> >> >> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn > > wrote: >> >> You're not alone. >> >> I talked with my local provider about 4 years ago and they said >> "We will probably start looking into IPv6 next year". >> I talked with them last month and they said "Yeah, everyone seems >> to be offering it.  I guess I'll have to start reading how to >> implement it". >> >> I'm sure 2045 will finally be the year of IPv6 everywhere. >> >> -A >> >> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >> > wrote: >> >> >> So by COB yesterday we now officially have FIOS at our farm.  >> >> Went from 3Mbps to around 30 measured average.  Yay.  >> >> It's a business account, Frontier.  But...still no IPv6. >> >> The new router's capable of it.  What's the hold up?  >> >> Customer service's response is "We don't offer that". >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Mon Apr 1 00:52:37 2019 From: cb.list6 at gmail.com (Ca By) Date: Sun, 31 Mar 2019 17:52:37 -0700 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <293EE676-667B-4984-A37F-DA077D175E25@rivervalleyinternet.net> References: <293EE676-667B-4984-A37F-DA077D175E25@rivervalleyinternet.net> Message-ID: On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Going to play devils advocate. > > If frontier has a ton of ipv4 addresses, what benefit is there to them in > rolling out ipv6? > > What benefit is there to you? > I love xbox and xbox works better on ipv6, https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf Also, webpages load faster , and i love fast web pages https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on-board/ https://www.akamai.com/fr/fr/multimedia/documents/technical-publication/a-case-for-faster-mobile-web-in-cellular-ipv6-networks.pdf > On Mar 31, 2019, at 7:11 PM, C. A. Fillekes wrote: > > > Still it's pretty darn good having real broadband on the farm. One thing > at a time. > > But, let's start thinking about ways to get Frontier up to speed on the > IPv6 thing. > > > On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn > wrote: > >> You're not alone. >> >> I talked with my local provider about 4 years ago and they said "We will >> probably start looking into IPv6 next year". >> I talked with them last month and they said "Yeah, everyone seems to be >> offering it. I guess I'll have to start reading how to implement it". >> >> I'm sure 2045 will finally be the year of IPv6 everywhere. >> >> -A >> >> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >> wrote: >> >>> >>> So by COB yesterday we now officially have FIOS at our farm. >>> >>> Went from 3Mbps to around 30 measured average. Yay. >>> >>> It's a business account, Frontier. But...still no IPv6. >>> >>> The new router's capable of it. What's the hold up? >>> >>> Customer service's response is "We don't offer that". >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Mon Apr 1 00:59:02 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 1 Apr 2019 00:59:02 +0000 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <3b39c152-6f68-d400-44ca-ccfac350a0c5@he.net> References: <293EE676-667B-4984-A37F-DA077D175E25@rivervalleyinternet.net>, <3b39c152-6f68-d400-44ca-ccfac350a0c5@he.net> Message-ID: <2E4E7881-96D5-4AEA-8E13-E359F7017380@reservetele.com> Telcos had an advantage, they were able to put the cost of that new fancy switch into our cost study / rate base. So they were rewarded for spending money, and boy did they spend money. Luke Ns Sent from my iPhone On Mar 31, 2019, at 7:20 PM, Mike Leber > wrote: You mean like pulse dialing and stepper relays vs touch tone dialing? I'm sure there were people that felt the same about that too. That mindset is simply you already paid for the old stuff, it's working fine, you would rather not understand or think about the problems the new tech solves or benefits it provides. To be motivated to do something you have to have a reason or goal. Most all goal seeking behavior in business can be put two buckets: 1) revenue at risk and 2) revenue enabled. i.e. one is going away from pain and the other is going towards a reward. Making a plan is based on your perception of current and future events. At scale the market does a whole lot of testing of economic fitness functions that are the result of the decisions of each of our companies makes about what all of this means. If you were an independent telephone company around 1955 to 1965 with relay based switches deciding when and if and why to use DTMF or a variant, I'm sure there was exactly the same dynamic. Situation: telecom company with old technology that was still working trying to decide what to do. I mean, your phones still worked on that day you were starting out the window musing about it. Why not just go to lunch and forget about it? While you were out to lunch after putting off deciding what to do about your relay switches around the same period of time the global phone system was growing at a breakneck speed and the first submarine transatlantic telephone cable system was getting run. Some people won't like this story because it is about making business decisions about technology when you aren't sure of the reasons to either do or not do something and isn't arguing about some specific concrete reason to add IPv6 support like: 1) the world has more people than IPv4 addresses or something 2) you work for a big company and would like your revenue from the Internet to keep growing over the next 10 years uninterrupted due the risk of not supporting IPv6 and this is too trivial of a technology decision because the incremental cost is so small (compared to all the other fires you have burning) to just add support anyway. I get where you are coming from. On 3/31/19 4:19 PM, Matt Hoppes wrote: Going to play devils advocate. If frontier has a ton of ipv4 addresses, what benefit is there to them in rolling out ipv6? What benefit is there to you? On Mar 31, 2019, at 7:11 PM, C. A. Fillekes > wrote: Still it's pretty darn good having real broadband on the farm. One thing at a time. But, let's start thinking about ways to get Frontier up to speed on the IPv6 thing. On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn > wrote: You're not alone. I talked with my local provider about 4 years ago and they said "We will probably start looking into IPv6 next year". I talked with them last month and they said "Yeah, everyone seems to be offering it. I guess I'll have to start reading how to implement it". I'm sure 2045 will finally be the year of IPv6 everywhere. -A On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes > wrote: So by COB yesterday we now officially have FIOS at our farm. Went from 3Mbps to around 30 measured average. Yay. It's a business account, Frontier. But...still no IPv6. The new router's capable of it. What's the hold up? Customer service's response is "We don't offer that". -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Apr 1 01:07:42 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 31 Mar 2019 18:07:42 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: On Sat, Mar 30, 2019 at 4:37 AM Matthew Petach wrote: > > > > On Sat, Mar 30, 2019 at 4:33 AM Matthew Petach wrote: >> >> >> >> On Thu, Mar 28, 2019 at 12:40 PM David Hubbard wrote: >>> >>> Hey all, I’ve been having bad luck searching around, but did IPv6 transit between HE and google ever get resolved? Ironically, I can now get to them cheaply from a location we currently have equipment that has been Cogent-only, so if it fixes the IPv6 issue I’d like to make the move. Anyone peer with HE in general and want to share their experience offlist? With the price, if they’re a good option, I’d consider rolling them in to other locations where we have redundancy already, so the v6 isn’t as big a deal there. >>> >>> >>> >>> Thanks >>> >>> >> >> >> I wasn't aware of any issues between HE.net and Google; >> are you sure you don't mean HE.net and Cogent? thread subject still says 'google and he', I don't think there's ever been problems between google/he for v6. I think there are some issues from cogent - > he over v6 :( Looking at a sample AS6939 customer link I see no: ".* 174$" ".* 174 .*$" routes in the bgp stream :( Looking at a AS174 customer link session I see no: ".* 6939$" ".* 6939 .*" routes in the bgp stream :( -chris >> >> Matt >> > > Ah. Sorry, the changed subject line didn't thread in with this, > so this showed up as an unreplied singleton in my inbox. > > Apologies for the duplicated response; at least this won't > be a lonely singleton in anyone else's inbox now. ^_^; > > Matt > From morrowc.lists at gmail.com Mon Apr 1 01:10:09 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 31 Mar 2019 18:10:09 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: On Sun, Mar 31, 2019 at 6:07 PM Christopher Morrow wrote: > > thread subject still says 'google and he', I don't think there's ever > been problems between google/he for v6. > I think there are some issues from cogent - > he over v6 :( > > Looking at a sample AS6939 customer link I see no: > ".* 174$" > ".* 174 .*$" > > routes in the bgp stream :( > > Looking at a AS174 customer link session I see no: > ".* 6939$" > ".* 6939 .*" > > routes in the bgp stream :( Apologies, I do actually see a path from 174 -> 6939 (well 28 paths): 174 6939 it's clearly not all of HE -> Cogent, and it's clearly not supposed to be working (I would think). -chris > > -chris > > >> > >> Matt > >> > > > > Ah. Sorry, the changed subject line didn't thread in with this, > > so this showed up as an unreplied singleton in my inbox. > > > > Apologies for the duplicated response; at least this won't > > be a lonely singleton in anyone else's inbox now. ^_^; > > > > Matt > > From mleber at he.net Mon Apr 1 01:19:27 2019 From: mleber at he.net (Mike Leber) Date: Sun, 31 Mar 2019 18:19:27 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: The routes you see are Cogent using IPv6 leaks. We chase these down as we see them. Obviously if Cogent is happy enough to use leaks, we could just give them our IPv6 customer routes directly.  ;) As a backbone operator, I'd prefer all routing we do (for at least the first hop leaving our network) to be intentional.  Perhaps they are the same? Should I wait for to get an interesting email?  (haha) Mike. On 3/31/19 6:10 PM, Christopher Morrow wrote: > On Sun, Mar 31, 2019 at 6:07 PM Christopher Morrow > wrote: >> thread subject still says 'google and he', I don't think there's ever >> been problems between google/he for v6. >> I think there are some issues from cogent - > he over v6 :( >> >> Looking at a sample AS6939 customer link I see no: >> ".* 174$" >> ".* 174 .*$" >> >> routes in the bgp stream :( >> >> Looking at a AS174 customer link session I see no: >> ".* 6939$" >> ".* 6939 .*" >> >> routes in the bgp stream :( > Apologies, I do actually see a path from 174 -> 6939 (well 28 paths): > 174 6939 > > it's clearly not all of HE -> Cogent, and it's clearly not supposed to > be working (I would think). > -chris > >> -chris >> >>>> Matt >>>> >>> Ah. Sorry, the changed subject line didn't thread in with this, >>> so this showed up as an unreplied singleton in my inbox. >>> >>> Apologies for the duplicated response; at least this won't >>> be a lonely singleton in anyone else's inbox now. ^_^; >>> >>> Matt >>> From valdis.kletnieks at vt.edu Mon Apr 1 01:21:11 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sun, 31 Mar 2019 21:21:11 -0400 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: <29933.1554081671@turing-police> On Sun, 31 Mar 2019 18:10:09 -0700, Christopher Morrow said: > Apologies, I do actually see a path from 174 -> 6939 (well 28 paths): > 174 6939 > > it's clearly not all of HE -> Cogent, and it's clearly not supposed to > be working (I would think). Wait, what? Are you saying that they refused to peer - and then failed at refusing? :) From kmedcalf at dessus.com Mon Apr 1 01:21:38 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 31 Mar 2019 19:21:38 -0600 Subject: Frontier rural FIOS & IPv6 In-Reply-To: Message-ID: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> It is not possible for web pages to load faster over IPv6 than over IPv4. All other factors being equal, IPv6 has higher overhead than IPv4 for the same payload throughput. This means that it is physically impossible for IPv6 to be move payload bytes "faster" than IPv4 can move the same payload. In other words, IPv6 has a higher "packet tax" than IPv4. Since you have no choice but to pay the "packet tax" the actual payload data flows more slowly. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By >Sent: Sunday, 31 March, 2019 18:53 >To: Matt Hoppes >Cc: Aaron C. de Bruyn; NANOG mailing list >Subject: Re: Frontier rural FIOS & IPv6 > > > >On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes > wrote: > > > Going to play devils advocate. > > If frontier has a ton of ipv4 addresses, what benefit is there >to them in rolling out ipv6? > > What benefit is there to you? > > >I love xbox and xbox works better on ipv6, > >https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47 >.pdf > >Also, webpages load faster , and i love fast web pages > >https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on- >board/ > > >https://www.akamai.com/fr/fr/multimedia/documents/technical- >publication/a-case-for-faster-mobile-web-in-cellular-ipv6- >networks.pdf > > > > > On Mar 31, 2019, at 7:11 PM, C. A. Fillekes > wrote: > > > > > Still it's pretty darn good having real broadband on the >farm. One thing at a time. > > > But, let's start thinking about ways to get Frontier up to >speed on the IPv6 thing. > > > > On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn > wrote: > > > You're not alone. > > I talked with my local provider about 4 years ago and >they said "We will probably start looking into IPv6 next year". > I talked with them last month and they said "Yeah, >everyone seems to be offering it. I guess I'll have to start reading >how to implement it". > > I'm sure 2045 will finally be the year of IPv6 >everywhere. > > -A > > On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes > wrote: > > > > So by COB yesterday we now officially have FIOS >at our farm. > > > Went from 3Mbps to around 30 measured average. >Yay. > > > It's a business account, Frontier. But...still >no IPv6. > > > The new router's capable of it. What's the hold >up? > > > Customer service's response is "We don't offer >that". > > > > > From bryan at shout.net Mon Apr 1 01:24:00 2019 From: bryan at shout.net (Bryan Holloway) Date: Sun, 31 Mar 2019 20:24:00 -0500 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <29933.1554081671@turing-police> References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> <29933.1554081671@turing-police> Message-ID: On 3/31/19 8:21 PM, Valdis Klētnieks wrote: > On Sun, 31 Mar 2019 18:10:09 -0700, Christopher Morrow said: > >> Apologies, I do actually see a path from 174 -> 6939 (well 28 paths): >> 174 6939 >> >> it's clearly not all of HE -> Cogent, and it's clearly not supposed to >> be working (I would think). > > Wait, what? > > Are you saying that they refused to peer - and then failed at refusing? :) > Let them eat cake. From jay at west.net Mon Apr 1 01:38:37 2019 From: jay at west.net (Jay Hennigan) Date: Sun, 31 Mar 2019 18:38:37 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: <6146caf7-76fe-3ac5-d4e5-8f748e7d04ae@west.net> On 3/31/19 6:19 PM, Mike Leber wrote: > The routes you see are Cogent using IPv6 leaks. > > We chase these down as we see them. > > Obviously if Cogent is happy enough to use leaks, we could just give > them our IPv6 customer routes directly.  ;) > > As a backbone operator, I'd prefer all routing we do (for at least the > first hop leaving our network) to be intentional.  Perhaps they are the > same? > > Should I wait for to get an interesting email?  (haha) Perhaps you should bake them a cake. :-) -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV From mleber at he.net Mon Apr 1 01:42:08 2019 From: mleber at he.net (Mike Leber) Date: Sun, 31 Mar 2019 18:42:08 -0700 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> References: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> Message-ID: <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> You are assuming the routing and transit relationships in IPv4 are the same in IPv6. IPv4 has many many many suboptimal transit relationships where routing is purposely suboptimal on the part of the networks in the path due to competitive reasons.  One example of suboptimal routing is traffic not being exchanged in a closer location where both networks exist and instead being routed hundreds or thousands of miles out of the way. Customers don't get to influence the decisions of monopolies etc. Customers choose based on inertia, brand experience, and what options are even available to them to get IPv6 vs IPv4. IPv6 has randomized some of these vendor relationships due to some upstream networks not even implementing IPv6, meaning the downstream networks were forced to make other choices. On 3/31/19 6:21 PM, Keith Medcalf wrote: > It is not possible for web pages to load faster over IPv6 than over IPv4. All other factors being equal, IPv6 has higher overhead than IPv4 for the same payload throughput. This means that it is physically impossible for IPv6 to be move payload bytes "faster" than IPv4 can move the same payload. > > In other words, IPv6 has a higher "packet tax" than IPv4. Since you have no choice but to pay the "packet tax" the actual payload data flows more slowly. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By >> Sent: Sunday, 31 March, 2019 18:53 >> To: Matt Hoppes >> Cc: Aaron C. de Bruyn; NANOG mailing list >> Subject: Re: Frontier rural FIOS & IPv6 >> >> >> >> On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes >> wrote: >> >> >> Going to play devils advocate. >> >> If frontier has a ton of ipv4 addresses, what benefit is there >> to them in rolling out ipv6? >> >> What benefit is there to you? >> >> >> I love xbox and xbox works better on ipv6, >> >> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47 >> .pdf >> >> Also, webpages load faster , and i love fast web pages >> >> https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on- >> board/ >> >> >> https://www.akamai.com/fr/fr/multimedia/documents/technical- >> publication/a-case-for-faster-mobile-web-in-cellular-ipv6- >> networks.pdf >> >> >> >> >> On Mar 31, 2019, at 7:11 PM, C. A. Fillekes >> wrote: >> >> >> >> >> Still it's pretty darn good having real broadband on the >> farm. One thing at a time. >> >> >> But, let's start thinking about ways to get Frontier up to >> speed on the IPv6 thing. >> >> >> >> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn >> wrote: >> >> >> You're not alone. >> >> I talked with my local provider about 4 years ago and >> they said "We will probably start looking into IPv6 next year". >> I talked with them last month and they said "Yeah, >> everyone seems to be offering it. I guess I'll have to start reading >> how to implement it". >> >> I'm sure 2045 will finally be the year of IPv6 >> everywhere. >> >> -A >> >> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >> wrote: >> >> >> >> So by COB yesterday we now officially have FIOS >> at our farm. >> >> >> Went from 3Mbps to around 30 measured average. >> Yay. >> >> >> It's a business account, Frontier. But...still >> no IPv6. >> >> >> The new router's capable of it. What's the hold >> up? >> >> >> Customer service's response is "We don't offer >> that". >> >> >> >> >> From randy at psg.com Mon Apr 1 01:47:09 2019 From: randy at psg.com (Randy Bush) Date: Sun, 31 Mar 2019 18:47:09 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <29933.1554081671@turing-police> References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> <29933.1554081671@turing-police> Message-ID: > Are you saying that they refused to peer - and then failed at refusing? :) luckily, none of the rest of us have bugs. whew! From bryan at shout.net Mon Apr 1 01:49:54 2019 From: bryan at shout.net (Bryan Holloway) Date: Sun, 31 Mar 2019 20:49:54 -0500 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> References: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> Message-ID: <70c67476-c48c-ab4d-ffef-46a0ea2fb804@shout.net> Furthermore, NAT, prevalent with IPv4, adds latency. There is none with IPv6 (unless you're doing it wrong.) On 3/31/19 8:42 PM, Mike Leber wrote: > You are assuming the routing and transit relationships in IPv4 are the > same in IPv6. > > IPv4 has many many many suboptimal transit relationships where routing > is purposely suboptimal on the part of the networks in the path due to > competitive reasons.  One example of suboptimal routing is traffic not > being exchanged in a closer location where both networks exist and > instead being routed hundreds or thousands of miles out of the way. > > Customers don't get to influence the decisions of monopolies etc. > > Customers choose based on inertia, brand experience, and what options > are even available to them to get IPv6 vs IPv4. > > IPv6 has randomized some of these vendor relationships due to some > upstream networks not even implementing IPv6, meaning the downstream > networks were forced to make other choices. > > > On 3/31/19 6:21 PM, Keith Medcalf wrote: >> It is not possible for web pages to load faster over IPv6 than over IPv4. All other factors being equal, IPv6 has higher overhead than IPv4 for the same payload throughput. This means that it is physically impossible for IPv6 to be move payload bytes "faster" than IPv4 can move the same payload. >> >> In other words, IPv6 has a higher "packet tax" than IPv4. Since you have no choice but to pay the "packet tax" the actual payload data flows more slowly. >> >> --- >> The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >> >> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By >>> Sent: Sunday, 31 March, 2019 18:53 >>> To: Matt Hoppes >>> Cc: Aaron C. de Bruyn; NANOG mailing list >>> Subject: Re: Frontier rural FIOS & IPv6 >>> >>> >>> >>> On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes >>> wrote: >>> >>> >>> Going to play devils advocate. >>> >>> If frontier has a ton of ipv4 addresses, what benefit is there >>> to them in rolling out ipv6? >>> >>> What benefit is there to you? >>> >>> >>> I love xbox and xbox works better on ipv6, >>> >>> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47 >>> .pdf >>> >>> Also, webpages load faster , and i love fast web pages >>> >>> https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on- >>> board/ >>> >>> >>> https://www.akamai.com/fr/fr/multimedia/documents/technical- >>> publication/a-case-for-faster-mobile-web-in-cellular-ipv6- >>> networks.pdf >>> >>> >>> >>> >>> On Mar 31, 2019, at 7:11 PM, C. A. Fillekes >>> wrote: >>> >>> >>> >>> >>> Still it's pretty darn good having real broadband on the >>> farm. One thing at a time. >>> >>> >>> But, let's start thinking about ways to get Frontier up to >>> speed on the IPv6 thing. >>> >>> >>> >>> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn >>> wrote: >>> >>> >>> You're not alone. >>> >>> I talked with my local provider about 4 years ago and >>> they said "We will probably start looking into IPv6 next year". >>> I talked with them last month and they said "Yeah, >>> everyone seems to be offering it. I guess I'll have to start reading >>> how to implement it". >>> >>> I'm sure 2045 will finally be the year of IPv6 >>> everywhere. >>> >>> -A >>> >>> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >>> wrote: >>> >>> >>> >>> So by COB yesterday we now officially have FIOS >>> at our farm. >>> >>> >>> Went from 3Mbps to around 30 measured average. >>> Yay. >>> >>> >>> It's a business account, Frontier. But...still >>> no IPv6. >>> >>> >>> The new router's capable of it. What's the hold >>> up? >>> >>> >>> Customer service's response is "We don't offer >>> that". >>> >>> >>> >>> >>> > From mattlists at rivervalleyinternet.net Mon Apr 1 01:50:21 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sun, 31 Mar 2019 21:50:21 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> References: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> Message-ID: The telephone example: What IS the benefit of DTMF other than I can dial faster? None. And I can use IVRs. Again - no impact to me as a telephone company. As far as ipv6. It’s been proven things “load faster” because the ipv6 servers of the various websites are not as heavily loaded as the ipv4 variants. All things equal - ipv6 doesn’t load faster. There’s literally no advantage to ipv6 other than “I’m out of ipv4 and need to continue to provide public routable Ips to my customers. “ > On Mar 31, 2019, at 9:42 PM, Mike Leber wrote: > > You are assuming the routing and transit relationships in IPv4 are the > same in IPv6. > > IPv4 has many many many suboptimal transit relationships where routing > is purposely suboptimal on the part of the networks in the path due to > competitive reasons. One example of suboptimal routing is traffic not > being exchanged in a closer location where both networks exist and > instead being routed hundreds or thousands of miles out of the way. > > Customers don't get to influence the decisions of monopolies etc. > > Customers choose based on inertia, brand experience, and what options > are even available to them to get IPv6 vs IPv4. > > IPv6 has randomized some of these vendor relationships due to some > upstream networks not even implementing IPv6, meaning the downstream > networks were forced to make other choices. > > >> On 3/31/19 6:21 PM, Keith Medcalf wrote: >> It is not possible for web pages to load faster over IPv6 than over IPv4. All other factors being equal, IPv6 has higher overhead than IPv4 for the same payload throughput. This means that it is physically impossible for IPv6 to be move payload bytes "faster" than IPv4 can move the same payload. >> >> In other words, IPv6 has a higher "packet tax" than IPv4. Since you have no choice but to pay the "packet tax" the actual payload data flows more slowly. >> >> --- >> The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >> >> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By >>> Sent: Sunday, 31 March, 2019 18:53 >>> To: Matt Hoppes >>> Cc: Aaron C. de Bruyn; NANOG mailing list >>> Subject: Re: Frontier rural FIOS & IPv6 >>> >>> >>> >>> On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes >>> wrote: >>> >>> >>> Going to play devils advocate. >>> >>> If frontier has a ton of ipv4 addresses, what benefit is there >>> to them in rolling out ipv6? >>> >>> What benefit is there to you? >>> >>> >>> I love xbox and xbox works better on ipv6, >>> >>> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47 >>> .pdf >>> >>> Also, webpages load faster , and i love fast web pages >>> >>> https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on- >>> board/ >>> >>> >>> https://www.akamai.com/fr/fr/multimedia/documents/technical- >>> publication/a-case-for-faster-mobile-web-in-cellular-ipv6- >>> networks.pdf >>> >>> >>> >>> >>> On Mar 31, 2019, at 7:11 PM, C. A. Fillekes >>> wrote: >>> >>> >>> >>> >>> Still it's pretty darn good having real broadband on the >>> farm. One thing at a time. >>> >>> >>> But, let's start thinking about ways to get Frontier up to >>> speed on the IPv6 thing. >>> >>> >>> >>> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn >>> wrote: >>> >>> >>> You're not alone. >>> >>> I talked with my local provider about 4 years ago and >>> they said "We will probably start looking into IPv6 next year". >>> I talked with them last month and they said "Yeah, >>> everyone seems to be offering it. I guess I'll have to start reading >>> how to implement it". >>> >>> I'm sure 2045 will finally be the year of IPv6 >>> everywhere. >>> >>> -A >>> >>> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >>> wrote: >>> >>> >>> >>> So by COB yesterday we now officially have FIOS >>> at our farm. >>> >>> >>> Went from 3Mbps to around 30 measured average. >>> Yay. >>> >>> >>> It's a business account, Frontier. But...still >>> no IPv6. >>> >>> >>> The new router's capable of it. What's the hold >>> up? >>> >>> >>> Customer service's response is "We don't offer >>> that". >>> >>> >>> >>> >>> > From mpetach at netflight.com Mon Apr 1 01:57:32 2019 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 31 Mar 2019 18:57:32 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: <6146caf7-76fe-3ac5-d4e5-8f748e7d04ae@west.net> References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> <6146caf7-76fe-3ac5-d4e5-8f748e7d04ae@west.net> Message-ID: On Sun, Mar 31, 2019 at 6:40 PM Jay Hennigan wrote: > Perhaps you should bake them a cake. :-) > The cake was delicious and moist https://www.flickr.com/photos/mpetach/4031434206 "I'd like to buy a vowel. Can I get an 'e', pleas?" ^_^;; -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Mon Apr 1 02:01:47 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 1 Apr 2019 02:01:47 +0000 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net>, Message-ID: <4A78C303-2066-421E-A93A-5DABF9F6B5D1@reservetele.com> My mom was cheap and only had pulse dialing in the 90s, it made using pagers difficult. Had to flip to tone after it dialed. Ns Sent from my iPad > On Mar 31, 2019, at 8:53 PM, Matt Hoppes wrote: > > The telephone example: > What IS the benefit of DTMF other than I can dial faster? None. And I can use IVRs. Again - no impact to me as a telephone company. > > As far as ipv6. It’s been proven things “load faster” because the ipv6 servers of the various websites are not as heavily loaded as the ipv4 variants. > > All things equal - ipv6 doesn’t load faster. There’s literally no advantage to ipv6 other than “I’m out of ipv4 and need to continue to provide public routable Ips to my customers. “ > >> On Mar 31, 2019, at 9:42 PM, Mike Leber wrote: >> >> You are assuming the routing and transit relationships in IPv4 are the >> same in IPv6. >> >> IPv4 has many many many suboptimal transit relationships where routing >> is purposely suboptimal on the part of the networks in the path due to >> competitive reasons. One example of suboptimal routing is traffic not >> being exchanged in a closer location where both networks exist and >> instead being routed hundreds or thousands of miles out of the way. >> >> Customers don't get to influence the decisions of monopolies etc. >> >> Customers choose based on inertia, brand experience, and what options >> are even available to them to get IPv6 vs IPv4. >> >> IPv6 has randomized some of these vendor relationships due to some >> upstream networks not even implementing IPv6, meaning the downstream >> networks were forced to make other choices. >> >> >>> On 3/31/19 6:21 PM, Keith Medcalf wrote: >>> It is not possible for web pages to load faster over IPv6 than over IPv4. All other factors being equal, IPv6 has higher overhead than IPv4 for the same payload throughput. This means that it is physically impossible for IPv6 to be move payload bytes "faster" than IPv4 can move the same payload. >>> >>> In other words, IPv6 has a higher "packet tax" than IPv4. Since you have no choice but to pay the "packet tax" the actual payload data flows more slowly. >>> >>> --- >>> The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >>> >>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By >>>> Sent: Sunday, 31 March, 2019 18:53 >>>> To: Matt Hoppes >>>> Cc: Aaron C. de Bruyn; NANOG mailing list >>>> Subject: Re: Frontier rural FIOS & IPv6 >>>> >>>> >>>> >>>> On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes >>>> wrote: >>>> >>>> >>>> Going to play devils advocate. >>>> >>>> If frontier has a ton of ipv4 addresses, what benefit is there >>>> to them in rolling out ipv6? >>>> >>>> What benefit is there to you? >>>> >>>> >>>> I love xbox and xbox works better on ipv6, >>>> >>>> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47 >>>> .pdf >>>> >>>> Also, webpages load faster , and i love fast web pages >>>> >>>> https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on- >>>> board/ >>>> >>>> >>>> https://www.akamai.com/fr/fr/multimedia/documents/technical- >>>> publication/a-case-for-faster-mobile-web-in-cellular-ipv6- >>>> networks.pdf >>>> >>>> >>>> >>>> >>>> On Mar 31, 2019, at 7:11 PM, C. A. Fillekes >>>> wrote: >>>> >>>> >>>> >>>> >>>> Still it's pretty darn good having real broadband on the >>>> farm. One thing at a time. >>>> >>>> >>>> But, let's start thinking about ways to get Frontier up to >>>> speed on the IPv6 thing. >>>> >>>> >>>> >>>> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn >>>> wrote: >>>> >>>> >>>> You're not alone. >>>> >>>> I talked with my local provider about 4 years ago and >>>> they said "We will probably start looking into IPv6 next year". >>>> I talked with them last month and they said "Yeah, >>>> everyone seems to be offering it. I guess I'll have to start reading >>>> how to implement it". >>>> >>>> I'm sure 2045 will finally be the year of IPv6 >>>> everywhere. >>>> >>>> -A >>>> >>>> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >>>> wrote: >>>> >>>> >>>> >>>> So by COB yesterday we now officially have FIOS >>>> at our farm. >>>> >>>> >>>> Went from 3Mbps to around 30 measured average. >>>> Yay. >>>> >>>> >>>> It's a business account, Frontier. But...still >>>> no IPv6. >>>> >>>> >>>> The new router's capable of it. What's the hold >>>> up? >>>> >>>> >>>> Customer service's response is "We don't offer >>>> that". >>>> >>>> >>>> >>>> >>>> >> > From beecher at beecher.cc Mon Apr 1 02:05:48 2019 From: beecher at beecher.cc (Tom Beecher) Date: Sun, 31 Mar 2019 22:05:48 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> Message-ID: I’m in Spectrum land, née Time Warner, née Rigas Cash Extraction Machine... errr Adelphia. ( Buffalo / WNY ) We’ve had native v6 for quite a few years up here. On Sun, Mar 31, 2019 at 16:55 Seth Mattinen wrote: > On 3/31/19 13:31, David Hubbard wrote: > > Things are no better in Spectrum land; gotta love the innovation in > > monopoly markets…. I ask every year and expect it in perhaps thirty. > > > It depends if you're Charter or Time Warner. Charter does. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Mon Apr 1 02:06:06 2019 From: bryan at shout.net (Bryan Holloway) Date: Sun, 31 Mar 2019 21:06:06 -0500 Subject: Frontier rural FIOS & IPv6 In-Reply-To: <4A78C303-2066-421E-A93A-5DABF9F6B5D1@reservetele.com> References: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> <4A78C303-2066-421E-A93A-5DABF9F6B5D1@reservetele.com> Message-ID: <10edadf5-7b45-e34d-6ea0-1506f747b9ae@shout.net> I remember tapping the switch-hook to emulate pulse-dialing on touch-tone phones. Few were impressed. On 3/31/19 9:01 PM, Luke Guillory wrote: > My mom was cheap and only had pulse dialing in the 90s, it made using pagers difficult. Had to flip to tone after it dialed. > > > > Ns > > Sent from my iPad > >> > > > > On Mar 31, 2019, at 8:53 PM, Matt Hoppes wrote: >> >> The telephone example: >> What IS the benefit of DTMF other than I can dial faster? None. And I can use IVRs. Again - no impact to me as a telephone company. >> >> As far as ipv6. It’s been proven things “load faster” because the ipv6 servers of the various websites are not as heavily loaded as the ipv4 variants. >> >> All things equal - ipv6 doesn’t load faster. There’s literally no advantage to ipv6 other than “I’m out of ipv4 and need to continue to provide public routable Ips to my customers. “ >> >>> On Mar 31, 2019, at 9:42 PM, Mike Leber wrote: >>> >>> You are assuming the routing and transit relationships in IPv4 are the >>> same in IPv6. >>> >>> IPv4 has many many many suboptimal transit relationships where routing >>> is purposely suboptimal on the part of the networks in the path due to >>> competitive reasons. One example of suboptimal routing is traffic not >>> being exchanged in a closer location where both networks exist and >>> instead being routed hundreds or thousands of miles out of the way. >>> >>> Customers don't get to influence the decisions of monopolies etc. >>> >>> Customers choose based on inertia, brand experience, and what options >>> are even available to them to get IPv6 vs IPv4. >>> >>> IPv6 has randomized some of these vendor relationships due to some >>> upstream networks not even implementing IPv6, meaning the downstream >>> networks were forced to make other choices. >>> >>> >>>> On 3/31/19 6:21 PM, Keith Medcalf wrote: >>>> It is not possible for web pages to load faster over IPv6 than over IPv4. All other factors being equal, IPv6 has higher overhead than IPv4 for the same payload throughput. This means that it is physically impossible for IPv6 to be move payload bytes "faster" than IPv4 can move the same payload. >>>> >>>> In other words, IPv6 has a higher "packet tax" than IPv4. Since you have no choice but to pay the "packet tax" the actual payload data flows more slowly. >>>> >>>> --- >>>> The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >>>> >>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By >>>>> Sent: Sunday, 31 March, 2019 18:53 >>>>> To: Matt Hoppes >>>>> Cc: Aaron C. de Bruyn; NANOG mailing list >>>>> Subject: Re: Frontier rural FIOS & IPv6 >>>>> >>>>> >>>>> >>>>> On Sun, Mar 31, 2019 at 4:20 PM Matt Hoppes >>>>> wrote: >>>>> >>>>> >>>>> Going to play devils advocate. >>>>> >>>>> If frontier has a ton of ipv4 addresses, what benefit is there >>>>> to them in rolling out ipv6? >>>>> >>>>> What benefit is there to you? >>>>> >>>>> >>>>> I love xbox and xbox works better on ipv6, >>>>> >>>>> https://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47 >>>>> .pdf >>>>> >>>>> Also, webpages load faster , and i love fast web pages >>>>> >>>>> https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on- >>>>> board/ >>>>> >>>>> >>>>> https://www.akamai.com/fr/fr/multimedia/documents/technical- >>>>> publication/a-case-for-faster-mobile-web-in-cellular-ipv6- >>>>> networks.pdf >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 31, 2019, at 7:11 PM, C. A. Fillekes >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> Still it's pretty darn good having real broadband on the >>>>> farm. One thing at a time. >>>>> >>>>> >>>>> But, let's start thinking about ways to get Frontier up to >>>>> speed on the IPv6 thing. >>>>> >>>>> >>>>> >>>>> On Sun, Mar 31, 2019 at 4:24 PM Aaron C. de Bruyn >>>>> wrote: >>>>> >>>>> >>>>> You're not alone. >>>>> >>>>> I talked with my local provider about 4 years ago and >>>>> they said "We will probably start looking into IPv6 next year". >>>>> I talked with them last month and they said "Yeah, >>>>> everyone seems to be offering it. I guess I'll have to start reading >>>>> how to implement it". >>>>> >>>>> I'm sure 2045 will finally be the year of IPv6 >>>>> everywhere. >>>>> >>>>> -A >>>>> >>>>> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes >>>>> wrote: >>>>> >>>>> >>>>> >>>>> So by COB yesterday we now officially have FIOS >>>>> at our farm. >>>>> >>>>> >>>>> Went from 3Mbps to around 30 measured average. >>>>> Yay. >>>>> >>>>> >>>>> It's a business account, Frontier. But...still >>>>> no IPv6. >>>>> >>>>> >>>>> The new router's capable of it. What's the hold >>>>> up? >>>>> >>>>> >>>>> Customer service's response is "We don't offer >>>>> that". >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> From lists.nanog at monmotha.net Mon Apr 1 02:09:11 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 31 Mar 2019 22:09:11 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: <698612A2-3A02-449B-9D01-10CF723CB6D1@dino.hostasaurus.com> Message-ID: On 3/31/19 10:05 PM, Tom Beecher wrote: > I’m in Spectrum land, née Time Warner, née Rigas Cash Extraction > Machine... errr Adelphia. ( Buffalo / WNY ) > > We’ve had native v6 for quite a few years up here. Spectrum ex. Bright House/Time Warner varies by region. NY region has had it, apparently. Indianapolis has not, does not, and, from what I gather, will not (for a long time). Apparently the regional operations of Bright House/TWC were very separated. They had other significant policy differences, too, e.g. caps/overages, AUP differences (especially as enforced vs. as written), etc. -- Brandon Martin From owen at delong.com Mon Apr 1 06:29:50 2019 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Mar 2019 23:29:50 -0700 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> Message-ID: <17CDE037-A2EA-4A29-A11F-8F99496787D5@delong.com> Send them another cake… Owen > On Mar 31, 2019, at 18:19 , Mike Leber wrote: > > The routes you see are Cogent using IPv6 leaks. > > We chase these down as we see them. > > Obviously if Cogent is happy enough to use leaks, we could just give > them our IPv6 customer routes directly. ;) > > As a backbone operator, I'd prefer all routing we do (for at least the > first hop leaving our network) to be intentional. Perhaps they are the > same? > > Should I wait for to get an interesting email? (haha) > > Mike. > > > On 3/31/19 6:10 PM, Christopher Morrow wrote: >> On Sun, Mar 31, 2019 at 6:07 PM Christopher Morrow >> wrote: >>> thread subject still says 'google and he', I don't think there's ever >>> been problems between google/he for v6. >>> I think there are some issues from cogent - > he over v6 :( >>> >>> Looking at a sample AS6939 customer link I see no: >>> ".* 174$" >>> ".* 174 .*$" >>> >>> routes in the bgp stream :( >>> >>> Looking at a AS174 customer link session I see no: >>> ".* 6939$" >>> ".* 6939 .*" >>> >>> routes in the bgp stream :( >> Apologies, I do actually see a path from 174 -> 6939 (well 28 paths): >> 174 6939 >> >> it's clearly not all of HE -> Cogent, and it's clearly not supposed to >> be working (I would think). >> -chris >> >>> -chris >>> >>>>> Matt >>>>> >>>> Ah. Sorry, the changed subject line didn't thread in with this, >>>> so this showed up as an unreplied singleton in my inbox. >>>> >>>> Apologies for the duplicated response; at least this won't >>>> be a lonely singleton in anyone else's inbox now. ^_^; >>>> >>>> Matt >>>> > From rwfireguru at gmail.com Mon Apr 1 12:25:02 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Mon, 1 Apr 2019 08:25:02 -0400 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> <6146caf7-76fe-3ac5-d4e5-8f748e7d04ae@west.net> Message-ID: Maybe I am just a tad bit illiterate on the the way a word on that cake can be spelled/used, but maybe Cogent doesn't want to peer with a provider that cannot spell.... :-\ plea /plē/ *noun* plural noun: *pleas* please /plēz/ *adverb* 1. 1. used in polite requests or questions. "please address letters to the Editor" On Sun, Mar 31, 2019 at 9:59 PM Matthew Petach wrote: > > > On Sun, Mar 31, 2019 at 6:40 PM Jay Hennigan wrote: > >> Perhaps you should bake them a cake. :-) >> > > The cake was delicious and moist > > https://www.flickr.com/photos/mpetach/4031434206 > > "I'd like to buy a vowel. Can I get an 'e', pleas?" ^_^;; > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at studio442.com.au Mon Apr 1 12:35:53 2019 From: nanog at studio442.com.au (Julien Goodwin) Date: Mon, 1 Apr 2019 23:35:53 +1100 Subject: Did IPv6 between HE and Google ever get resolved? In-Reply-To: References: <84C6285F-9D45-4B87-9FC8-F541A246195E@dino.hostasaurus.com> <6146caf7-76fe-3ac5-d4e5-8f748e7d04ae@west.net> Message-ID: On 1/4/19 11:25 pm, Robert Webb wrote: > Maybe I am just a tad bit illiterate on the the way a word on that cake > can be spelled/used, but maybe Cogent doesn't want to peer with a > provider that cannot spell....  :-\ I like that theory. Explains why they don't peer with Google ("googol" being the correct spelling of the number) too. From james.cutler at consultant.com Mon Apr 1 14:41:19 2019 From: james.cutler at consultant.com (James R Cutler) Date: Mon, 1 Apr 2019 10:41:19 -0400 Subject: Frontier rural FIOS & IPv6 In-Reply-To: References: <6cdb939d4020c3408e26822ff16fe5fb@mail.dessus.com> <94b6350f-97b2-93c5-b5b5-7915b1e4752a@he.net> Message-ID: <01525FAD-637B-4B1A-AAF2-081CE5F61C76@consultant.com> > On Mar 31, 2019, at 9:50 PM, Matt Hoppes wrote: > > The telephone example: > What IS the benefit of DTMF other than I can dial faster? None. And I can use IVRs. Again - no impact to me as a telephone company. > OK, this is off topic to an extent, but DTMF provided the opportunity for immense savings in the cable plant because of the copper gauge reduction allowed. Dropping the requirement for transmitting switch actuations (DC on-off) allowed development of more cost effective transmission solutions. The removal of the mechanical dial and included governor mechanism dropped both manufacturing and maintenance costs for telephone sets and provided the opportunity for creative packaging not limited by the rotary dial size. That’s enough off topic for now. As for IPv6: If one assumes that the Internet is a world-wide network of networks and that connected devices, including multiple personal devices, will continue to proliferate — Management and equipment cost for kluges to compensate for the dearth of IPv4 addresses and still provide universal connectivity will continue to escalate. Investment in native IPv6 provides an obvious future cost avoidance opportunity. Even ISPs that say, “My network is just fine.” will eventually run into this financial reality. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From markjr at easydns.com Mon Apr 1 14:59:28 2019 From: markjr at easydns.com (Mark E. Jeftovic) Date: Mon, 1 Apr 2019 10:59:28 -0400 Subject: DNS Qtypes and class values are a social construct Message-ID: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> The DNS is an inverted-tree hierarchy, which is problematic and promotes unequal outcomes among system participants. After a lengthy contemplative process we have enacted a system of social justice pricing which will rectify historical inequality. The new pricing is effective immediately and retroactive across all customers. Details - https://easydns.com/blog/2019/04/01/easydns-social-justice-pricing-goes-into-effect-today/ - mark -- Mark E. Jeftovic Co-founder & CEO, easyDNS Technologies Inc. /Author of Managing Mission Critical Domains & DNS: The Book / /Personal Blog: Guerrilla-Capitalism.com / -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas at ncartron.org Mon Apr 1 15:35:18 2019 From: nicolas at ncartron.org (nicolas at ncartron.org) Date: Mon, 1 Apr 2019 15:35:18 +0000 Subject: DNS Qtypes and class values are a social construct In-Reply-To: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> Message-ID: <9hbdat.ppagmv.1hge9a0-qmf@mx1.ncartron.org> On Monday, 1 April 2019, Mark E. Jeftovic wrote: > The DNS is an inverted-tree hierarchy, which is problematic and promotes > unequal outcomes among system participants. > > After a lengthy contemplative process we have enacted a system of social > justice pricing which will rectify historical inequality. The new > pricing is effective immediately and retroactive across all customers. > > Details - > https://easydns.com/blog/2019/04/01/easydns-social-justice-pricing-goes-into-effect-today/ Nice try, Mark ;) -- Sent from my Sailfish device From alfie at fdx.services Mon Apr 1 16:08:08 2019 From: alfie at fdx.services (Alfie Pates) Date: Mon, 01 Apr 2019 12:08:08 -0400 Subject: DNS Qtypes and class values are a social construct In-Reply-To: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> Message-ID: I feel this comes off as poking fun at trans people, women, and earnest attempts to combat what are actual problems in our industry, more than it pokes fun at the industry itself which is what a good April Fool should do - this feels more like laughing at "outsiders" more than laughing at ourselves. I think this is pretty tone-deaf, in my opinion. ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From alter3d at alter3d.ca Mon Apr 1 16:16:17 2019 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 1 Apr 2019 12:16:17 -0400 Subject: DNS Qtypes and class values are a social construct In-Reply-To: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> Message-ID: On 2019-04-01 10:59 AM, Mark E. Jeftovic wrote: > > The DNS is an inverted-tree hierarchy, which is problematic and > promotes unequal outcomes among system participants. > > After a lengthy contemplative process we have enacted a system of > social justice pricing which will rectify historical inequality. The > new pricing is effective immediately and retroactive across all > customers. > > Details - > https://easydns.com/blog/2019/04/01/easydns-social-justice-pricing-goes-into-effect-today/ > > > - mark > > -- > Mark E. Jeftovic > Co-founder & CEO, easyDNS Technologies Inc. > /Author of Managing Mission Critical Domains & DNS: The Book > / > /Personal Blog: Guerrilla-Capitalism.com > / Your lack of consideration for the latency-impaired is triggering for me.  I demand that you address the problems of network-topology inequality and bandwidth privilege by ensuring that everyone gets identical response times to their DNS queries, or else I and the other member of the Democratic Union for Meme-access Balance (DUMB) will shame you on Tumblr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayb at braeburn.org Mon Apr 1 17:25:54 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Mon, 1 Apr 2019 13:25:54 -0400 Subject: request for help: 192.139.135.0/24 Message-ID: <23714.18850.7120.200041@oz.mt.att.com> [No attempts at 01-April humor will be attempted in this message.] Seeking help from routing engineers around the 'net: ARIN documents that 192.139.135.0/24 has been allocated to Metro Wireless International: https://whois.arin.net/rest/net/NET-192-139-135-0-1 Further, the party to whom 192.139.135.0/24 has been allocated has published a ROA in ARIN's hosted RPKI asserting that bgp announcements for that prefix are valid only when originating in AS63251. To view this, go to your favorite RPKI vantage point that uses ARIN's TAL. If you don't yet have a favorite, feel free to telnet to route-server.ip.att.net and run: show validation database record 192.139.135.0/24 Unfortunately, as may be seen at route-views, etc, most of the Internet now prefers an invalid path that's mis-originated in as4808: Network Next Hop Path * 192.139.135.0 208.51.134.254 3549 3356 4837 4808 i * 194.85.40.15 3267 3356 4837 4808 i * 193.0.0.56 3333 1273 4837 4808 i * 37.139.139.0 57866 6762 4837 4808 i * 12.0.1.63 7018 1299 53292 63251 ? * 140.192.8.16 54728 20130 6939 4837 4808 i * 91.218.184.60 49788 1299 53292 63251 ? * 203.181.248.168 7660 2516 4837 4808 i * 154.11.12.212 852 4837 4808 i * 134.222.87.1 286 1299 53292 63251 ? * 209.124.176.223 101 101 3356 4837 4808 i * 137.39.3.55 701 4837 4808 i * 94.142.247.3 8283 1239 4837 4808 i * 162.251.163.2 53767 3257 1299 53292 63251 ? * 212.66.96.126 20912 1267 3356 4837 4808 i * 198.58.198.255 1403 6461 4837 4808 i * 198.58.198.254 1403 6461 4837 4808 i *> 202.232.0.2 2497 4837 4808 i * 203.62.252.83 1221 4637 4837 4808 i * 132.198.255.253 1351 6939 4837 4808 i * 206.24.210.80 3561 209 4837 4808 i * 195.208.112.161 3277 39710 9002 3356 4837 4808 i * 217.192.89.50 3303 4837 4808 i * 173.205.57.234 53364 3257 1299 53292 63251 ? * 207.172.6.20 6079 3356 4837 4808 i * 207.172.6.1 6079 3356 4837 4808 i * 208.74.64.40 19214 174 4837 4837 4808 i * 144.228.241.130 1239 4837 4808 i * 162.250.137.254 4901 6079 3356 4837 4808 i * 114.31.199.1 4826 1299 53292 63251 i * 64.71.137.241 6939 4837 4808 i Please help the Metro Wireless International folks get this cleared up so their 192.139.135.0/24 can once again be usable. In particular, help is sought from 4837 and their transit providers: 1239 701 3356 (Yes, I am trying to reach folks at those networks in other ways, too.) Thanks. Jay B. From morrowc.lists at gmail.com Mon Apr 1 19:35:30 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 1 Apr 2019 15:35:30 -0400 Subject: request for help: 192.139.135.0/24 In-Reply-To: <23714.18850.7120.200041@oz.mt.att.com> References: <23714.18850.7120.200041@oz.mt.att.com> Message-ID: (from offline chat and pokery) It looks like 701/1239/3356 are permitting 4837 to announce this prefix because: $ whois -h whois.radb.net 192.139.135.0 route: 192.139.135.0/24 descr: managedway company origin: AS53292 mnt-by: MAINT-AS53292 changed: rsanders at managedway.com 20181128 #23:11:53Z source: RADB route: 192.139.135.0/24 descr: GLENQCY1 origin: AS271 mnt-by: BELL-RC changed: config at in.bell.ca 19930820 source: BELL route: 192.139.135.0/24 descr: CMI IP Transit origin: AS4808 admin-c: MAINT-CMI-INT-HK tech-c: MAINT-CMI-INT-HK mnt-by: MAINT-CMI-INT-HK changed: qas_support at cmi.chinamobile.com 20160525 source: NTTCOM mntner: MAINT-CMI-INT-HK descr: China Mobile International Limited country: HK admin-c: CMIL1-AP upd-to: qas_support at cmi.chinamobile.com auth: # Filtered mnt-by: MAINT-CMI-INT-HK referral-by: APNIC-HM last-modified: 2017-11-22T09:00:43Z source: APNIC There is some less-than-great management of the associated IRR data. It'd be in the best interest of (Metro Wireless) to start asking the various IRR's: bell - config at in.bell.ca ? radb - nttcom - job? apnic - to remove the objects in question. I'm curious why NTT's still holding this record since there's a competing ROA? On Mon, Apr 1, 2019 at 1:27 PM Jay Borkenhagen wrote: > > [No attempts at 01-April humor will be attempted in this message.] > > > Seeking help from routing engineers around the 'net: > > > ARIN documents that 192.139.135.0/24 has been allocated to Metro > Wireless International: > > https://whois.arin.net/rest/net/NET-192-139-135-0-1 > > Further, the party to whom 192.139.135.0/24 has been allocated has > published a ROA in ARIN's hosted RPKI asserting that bgp announcements > for that prefix are valid only when originating in AS63251. To view > this, go to your favorite RPKI vantage point that uses ARIN's TAL. If > you don't yet have a favorite, feel free to telnet to > route-server.ip.att.net and run: > > show validation database record 192.139.135.0/24 > > > Unfortunately, as may be seen at route-views, etc, most of the > Internet now prefers an invalid path that's mis-originated in as4808: > > > Network Next Hop Path > * 192.139.135.0 208.51.134.254 3549 3356 4837 4808 i > * 194.85.40.15 3267 3356 4837 4808 i > * 193.0.0.56 3333 1273 4837 4808 i > * 37.139.139.0 57866 6762 4837 4808 i > * 12.0.1.63 7018 1299 53292 63251 ? > * 140.192.8.16 54728 20130 6939 4837 4808 i > * 91.218.184.60 49788 1299 53292 63251 ? > * 203.181.248.168 7660 2516 4837 4808 i > * 154.11.12.212 852 4837 4808 i > * 134.222.87.1 286 1299 53292 63251 ? > * 209.124.176.223 101 101 3356 4837 4808 i > * 137.39.3.55 701 4837 4808 i > * 94.142.247.3 8283 1239 4837 4808 i > * 162.251.163.2 53767 3257 1299 53292 63251 ? > * 212.66.96.126 20912 1267 3356 4837 4808 i > * 198.58.198.255 1403 6461 4837 4808 i > * 198.58.198.254 1403 6461 4837 4808 i > *> 202.232.0.2 2497 4837 4808 i > * 203.62.252.83 1221 4637 4837 4808 i > * 132.198.255.253 1351 6939 4837 4808 i > * 206.24.210.80 3561 209 4837 4808 i > * 195.208.112.161 3277 39710 9002 3356 4837 4808 i > * 217.192.89.50 3303 4837 4808 i > * 173.205.57.234 53364 3257 1299 53292 63251 ? > * 207.172.6.20 6079 3356 4837 4808 i > * 207.172.6.1 6079 3356 4837 4808 i > * 208.74.64.40 19214 174 4837 4837 4808 i > * 144.228.241.130 1239 4837 4808 i > * 162.250.137.254 4901 6079 3356 4837 4808 i > * 114.31.199.1 4826 1299 53292 63251 i > * 64.71.137.241 6939 4837 4808 i > > > Please help the Metro Wireless International folks get this cleared up > so their 192.139.135.0/24 can once again be usable. In particular, > help is sought from 4837 and their transit providers: > > 1239 > 701 > 3356 > > (Yes, I am trying to reach folks at those networks in other ways, too.) > > > Thanks. > > Jay B. > > > From john at alcock.org Mon Apr 1 19:36:34 2019 From: john at alcock.org (John Alcock) Date: Mon, 1 Apr 2019 15:36:34 -0400 Subject: Contact information requested - Sony/Playstation Message-ID: Ahh... More problems with my new IP Block. Any contacts on the list for Sony/PlayStation Network. My new IP Block 138.43.128.0/18 can not access. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at slimey.org Mon Apr 1 19:48:25 2019 From: simon at slimey.org (Simon Lockhart) Date: Mon, 1 Apr 2019 20:48:25 +0100 Subject: Contact information requested - Sony/Playstation In-Reply-To: References: Message-ID: <20190401194825.GG22741@dilbert.slimey.org> On Mon Apr 01, 2019 at 03:36:34pm -0400, John Alcock wrote: > More problems with my new IP Block. Any contacts on the list for > Sony/PlayStation Network. My new IP Block 138.43.128.0/18 can not access. SNEI-NOC-Abuse at am.sony.com are the right people, and generally responsive. Simon From john at alcock.org Mon Apr 1 19:52:57 2019 From: john at alcock.org (John Alcock) Date: Mon, 1 Apr 2019 15:52:57 -0400 Subject: Contact information requested - Sony/Playstation In-Reply-To: <20190401194825.GG22741@dilbert.slimey.org> References: <20190401194825.GG22741@dilbert.slimey.org> Message-ID: Awesome, thanks! On Mon, Apr 1, 2019 at 3:48 PM Simon Lockhart wrote: > On Mon Apr 01, 2019 at 03:36:34pm -0400, John Alcock wrote: > > More problems with my new IP Block. Any contacts on the list for > > Sony/PlayStation Network. My new IP Block 138.43.128.0/18 can not > access. > > SNEI-NOC-Abuse at am.sony.com are the right people, and generally responsive. > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Mon Apr 1 21:48:28 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 1 Apr 2019 17:48:28 -0400 (EDT) Subject: FCC seeks comment on improving the wireless resiliency cooperative framework Message-ID: FCC Public Safety and Homeland Security Bureau Seeks Comment on Improving the Wireless Resiiency Cooperative Framework Comment Date: April 29, 2019 Reply Date: May 20, 2019 https://docs.fcc.gov/public/attachments/DA-19-242A1.pdf The Bureau particularly welcomes comments from cross-sector stakeholders with on-the-ground experience during a disaster in which wireless providers utilized the Framework. The Bureau intends to use these experiences to help inform recommendations it may make to the Commission on measures to expedite service restoration efforts in the face of a storm or other disastrous event and to also inform the FCC’s ongoing review of the efficacy of the Framework. In addition to stakeholders in the communications and emergency response sectors, we are interested in hearing from industry and government bodies at all levels, and particularly from consumers, including people with disabilities and those who may be disproportionately affected by communications outages, as well as from any other interested stakeholders. [...] The Framework enumerates five prongs of commitment: providing for reasonable roaming arrangements during disasters when technically feasible; fostering mutual aid during emergencies; enhancing municipal preparedness and restoration; increasing consumer readiness and preparation; and improving public awareness and stakeholder communications on service and restoration status. [...] From Courtney_Smith at comcast.com Tue Apr 2 15:55:14 2019 From: Courtney_Smith at comcast.com (Smith, Courtney) Date: Tue, 2 Apr 2019 15:55:14 +0000 Subject: request for help: 192.139.135.0/24 In-Reply-To: <23714.18850.7120.200041@oz.mt.att.com> References: <23714.18850.7120.200041@oz.mt.att.com> Message-ID: <77BF56D8-998F-4718-B353-FAB8392B3C19@Cable.Comcast.com> Any luck reaching AS4837? route-views>show ip bgp 192.139.135.0/24 longer-prefixes BGP table version is 103101215, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 192.139.135.0 208.51.134.254 0 0 3549 3356 4837 4808 i * 194.85.40.15 0 0 3267 3356 4837 4808 i * 193.0.0.56 0 3333 1273 4837 4808 i * 37.139.139.0 0 57866 6762 4837 4808 i * 12.0.1.63 0 7018 1299 53292 63251 ? * 140.192.8.16 0 54728 20130 6939 4837 4808 i * 91.218.184.60 0 49788 1299 53292 63251 ? * 203.181.248.168 0 7660 2516 4837 4808 i * 154.11.12.212 0 0 852 4837 4808 i * 134.222.87.1 700 0 286 1299 53292 63251 ? * 209.124.176.223 0 101 101 3356 4837 4808 i * 137.39.3.55 0 701 3356 4837 4808 i * 94.142.247.3 0 0 8283 1299 53292 63251 ? * 162.251.163.2 0 53767 3257 1299 53292 63251 ? * 212.66.96.126 0 20912 1267 3356 4837 4808 i * 198.58.198.255 0 1403 6461 4837 4808 i * 198.58.198.254 0 1403 6461 4837 4808 i *> 202.232.0.2 0 2497 4837 4808 i * 203.62.252.83 0 1221 4637 4837 4808 i * 132.198.255.253 0 1351 6939 4837 4808 i * 206.24.210.80 0 3561 209 4837 4808 i * 195.208.112.161 0 3277 39710 9002 3356 4837 4808 i * 217.192.89.50 0 3303 4837 4808 i * 173.205.57.234 0 53364 3257 1299 53292 63251 ? * 207.172.6.20 0 0 6079 3356 4837 4808 i * 207.172.6.1 0 0 6079 3356 4837 4808 i * 208.74.64.40 0 19214 174 3356 4837 4808 i * 144.228.241.130 240 0 1239 4837 4808 i * 162.250.137.254 0 4901 6079 3356 4837 4808 i * 114.31.199.1 0 4826 1299 53292 63251 i * 64.71.137.241 0 6939 4837 4808 i route-views> On 4/1/19, 1:30 PM, "NANOG on behalf of Jay Borkenhagen" wrote: [No attempts at 01-April humor will be attempted in this message.] Seeking help from routing engineers around the 'net: ARIN documents that 192.139.135.0/24 has been allocated to Metro Wireless International: https://whois.arin.net/rest/net/NET-192-139-135-0-1 Further, the party to whom 192.139.135.0/24 has been allocated has published a ROA in ARIN's hosted RPKI asserting that bgp announcements for that prefix are valid only when originating in AS63251. To view this, go to your favorite RPKI vantage point that uses ARIN's TAL. If you don't yet have a favorite, feel free to telnet to route-server.ip.att.net and run: show validation database record 192.139.135.0/24 Unfortunately, as may be seen at route-views, etc, most of the Internet now prefers an invalid path that's mis-originated in as4808: Network Next Hop Path * 192.139.135.0 208.51.134.254 3549 3356 4837 4808 i * 194.85.40.15 3267 3356 4837 4808 i * 193.0.0.56 3333 1273 4837 4808 i * 37.139.139.0 57866 6762 4837 4808 i * 12.0.1.63 7018 1299 53292 63251 ? * 140.192.8.16 54728 20130 6939 4837 4808 i * 91.218.184.60 49788 1299 53292 63251 ? * 203.181.248.168 7660 2516 4837 4808 i * 154.11.12.212 852 4837 4808 i * 134.222.87.1 286 1299 53292 63251 ? * 209.124.176.223 101 101 3356 4837 4808 i * 137.39.3.55 701 4837 4808 i * 94.142.247.3 8283 1239 4837 4808 i * 162.251.163.2 53767 3257 1299 53292 63251 ? * 212.66.96.126 20912 1267 3356 4837 4808 i * 198.58.198.255 1403 6461 4837 4808 i * 198.58.198.254 1403 6461 4837 4808 i *> 202.232.0.2 2497 4837 4808 i * 203.62.252.83 1221 4637 4837 4808 i * 132.198.255.253 1351 6939 4837 4808 i * 206.24.210.80 3561 209 4837 4808 i * 195.208.112.161 3277 39710 9002 3356 4837 4808 i * 217.192.89.50 3303 4837 4808 i * 173.205.57.234 53364 3257 1299 53292 63251 ? * 207.172.6.20 6079 3356 4837 4808 i * 207.172.6.1 6079 3356 4837 4808 i * 208.74.64.40 19214 174 4837 4837 4808 i * 144.228.241.130 1239 4837 4808 i * 162.250.137.254 4901 6079 3356 4837 4808 i * 114.31.199.1 4826 1299 53292 63251 i * 64.71.137.241 6939 4837 4808 i Please help the Metro Wireless International folks get this cleared up so their 192.139.135.0/24 can once again be usable. In particular, help is sought from 4837 and their transit providers: 1239 701 3356 (Yes, I am trying to reach folks at those networks in other ways, too.) Thanks. Jay B. From thomasammon at gmail.com Tue Apr 2 16:54:47 2019 From: thomasammon at gmail.com (Tom Ammon) Date: Tue, 2 Apr 2019 12:54:47 -0400 Subject: modeling residential subscriber bandwidth demand Message-ID: How do people model and try to project residential subscriber bandwidth demands into the future? Do you base it primarily on historical data? Are there more sophisticated approaches that you use to figure out how much backbone bandwidth you need to build to keep your eyeballs happy? Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Apr 2 16:57:44 2019 From: job at ntt.net (Job Snijders) Date: Tue, 2 Apr 2019 18:57:44 +0200 Subject: request for help: 192.139.135.0/24 In-Reply-To: References: <23714.18850.7120.200041@oz.mt.att.com> Message-ID: Ack for NTT On Mon, Apr 1, 2019 at 21:36 Christopher Morrow wrote: > (from offline chat and pokery) > > It looks like 701/1239/3356 are permitting 4837 to announce this prefix > because: > $ whois -h whois.radb.net 192.139.135.0 > route: 192.139.135.0/24 > descr: managedway company > origin: AS53292 > mnt-by: MAINT-AS53292 > changed: rsanders at managedway.com 20181128 #23:11:53Z > source: RADB > > route: 192.139.135.0/24 > descr: GLENQCY1 > origin: AS271 > mnt-by: BELL-RC > changed: config at in.bell.ca 19930820 > source: BELL > > route: 192.139.135.0/24 > descr: CMI IP Transit > origin: AS4808 > admin-c: MAINT-CMI-INT-HK > tech-c: MAINT-CMI-INT-HK > mnt-by: MAINT-CMI-INT-HK > changed: qas_support at cmi.chinamobile.com 20160525 > source: NTTCOM > > mntner: MAINT-CMI-INT-HK > descr: China Mobile International Limited > country: HK > admin-c: CMIL1-AP > upd-to: qas_support at cmi.chinamobile.com > auth: # Filtered > mnt-by: MAINT-CMI-INT-HK > referral-by: APNIC-HM > last-modified: 2017-11-22T09:00:43Z > source: APNIC > > > There is some less-than-great management of the associated IRR data. > It'd be in the best interest of (Metro Wireless) to start > asking the various IRR's: > bell - config at in.bell.ca ? > radb - > nttcom - job? > apnic - > > to remove the objects in question. > I'm curious why NTT's still holding this record since there's a competing > ROA? > > On Mon, Apr 1, 2019 at 1:27 PM Jay Borkenhagen wrote: > > > > [No attempts at 01-April humor will be attempted in this message.] > > > > > > Seeking help from routing engineers around the 'net: > > > > > > ARIN documents that 192.139.135.0/24 has been allocated to Metro > > Wireless International: > > > > https://whois.arin.net/rest/net/NET-192-139-135-0-1 > > > > Further, the party to whom 192.139.135.0/24 has been allocated has > > published a ROA in ARIN's hosted RPKI asserting that bgp announcements > > for that prefix are valid only when originating in AS63251. To view > > this, go to your favorite RPKI vantage point that uses ARIN's TAL. If > > you don't yet have a favorite, feel free to telnet to > > route-server.ip.att.net and run: > > > > show validation database record 192.139.135.0/24 > > > > > > Unfortunately, as may be seen at route-views, etc, most of the > > Internet now prefers an invalid path that's mis-originated in as4808: > > > > > > Network Next Hop Path > > * 192.139.135.0 208.51.134.254 3549 3356 4837 4808 i > > * 194.85.40.15 3267 3356 4837 4808 i > > * 193.0.0.56 3333 1273 4837 4808 i > > * 37.139.139.0 57866 6762 4837 4808 i > > * 12.0.1.63 7018 1299 53292 63251 ? > > * 140.192.8.16 54728 20130 6939 4837 4808 i > > * 91.218.184.60 49788 1299 53292 63251 ? > > * 203.181.248.168 7660 2516 4837 4808 i > > * 154.11.12.212 852 4837 4808 i > > * 134.222.87.1 286 1299 53292 63251 ? > > * 209.124.176.223 101 101 3356 4837 4808 i > > * 137.39.3.55 701 4837 4808 i > > * 94.142.247.3 8283 1239 4837 4808 i > > * 162.251.163.2 53767 3257 1299 53292 63251 ? > > * 212.66.96.126 20912 1267 3356 4837 4808 i > > * 198.58.198.255 1403 6461 4837 4808 i > > * 198.58.198.254 1403 6461 4837 4808 i > > *> 202.232.0.2 2497 4837 4808 i > > * 203.62.252.83 1221 4637 4837 4808 i > > * 132.198.255.253 1351 6939 4837 4808 i > > * 206.24.210.80 3561 209 4837 4808 i > > * 195.208.112.161 3277 39710 9002 3356 4837 4808 i > > * 217.192.89.50 3303 4837 4808 i > > * 173.205.57.234 53364 3257 1299 53292 63251 ? > > * 207.172.6.20 6079 3356 4837 4808 i > > * 207.172.6.1 6079 3356 4837 4808 i > > * 208.74.64.40 19214 174 4837 4837 4808 i > > * 144.228.241.130 1239 4837 4808 i > > * 162.250.137.254 4901 6079 3356 4837 4808 i > > * 114.31.199.1 4826 1299 53292 63251 i > > * 64.71.137.241 6939 4837 4808 i > > > > > > Please help the Metro Wireless International folks get this cleared up > > so their 192.139.135.0/24 can once again be usable. In particular, > > help is sought from 4837 and their transit providers: > > > > 1239 > > 701 > > 3356 > > > > (Yes, I am trying to reach folks at those networks in other ways, too.) > > > > > > Thanks. > > > > Jay B. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Tue Apr 2 17:03:33 2019 From: ben at 6by7.net (Ben Cannon) Date: Tue, 2 Apr 2019 10:03:33 -0700 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: Residential whatnow? Sorry, to be honest, there really isn’t any. I suppose if one is buying lit services, this is important to model. But an *incredibly* huge residential network can be served by a single basic 10/40g backbone connection or two. And if you own the glass it’s trivial to spin up very many of those. Aggregate in metro cores, put the Netflix OC there, done. Then again, we don’t even do DNS anymore, we’re <1ms from Cloudflare, so in 2019 why bother? I don’t miss the days of ISDN backhaul, but those days are long gone. And I won’t go back. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Apr 2, 2019, at 9:54 AM, Tom Ammon wrote: > > How do people model and try to project residential subscriber bandwidth demands into the future? Do you base it primarily on historical data? Are there more sophisticated approaches that you use to figure out how much backbone bandwidth you need to build to keep your eyeballs happy? > > Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? > > Tom > -- > ----------------------------------------------------------------------------- > Tom Ammon > M: (801) 784-2628 > thomasammon at gmail.com > ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Apr 2 17:47:50 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 2 Apr 2019 10:47:50 -0700 Subject: modeling residential subscriber bandwidth demand Message-ID: <20190402104750.DB512778@m0117458.ppops.net> :: How do people model and try to project residential :: subscriber bandwidth demands into the future? Do :: you base it primarily on historical data? ------------------------------------------------------ Yes, if you have a lot of quality data that goes far back in the past you can make pretty good judgements on future needs. Less data and/or not very far back lessens the accuracy of a prediction about the future. scott --- thomasammon at gmail.com wrote: From: Tom Ammon To: NANOG Subject: modeling residential subscriber bandwidth demand Date: Tue, 2 Apr 2019 12:54:47 -0400 How do people model and try to project residential subscriber bandwidth demands into the future? Do you base it primarily on historical data? Are there more sophisticated approaches that you use to figure out how much backbone bandwidth you need to build to keep your eyeballs happy? Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- From aaron1 at gvtc.com Tue Apr 2 18:13:11 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 2 Apr 2019 13:13:11 -0500 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: <000f01d4e97f$bc23acc0$346b0640$@gvtc.com> We use trendline/95% trendline that’s built into a lot of graphing tools… solarwinds, I think even cdn cache portals have trendlines… forecasts, etc. My boss might use other growth percentages gleaned from previous years… but yeah, like another person mentioned, the more history you have the better it seems… unless there is some major shift for some strange big reason… but have we ever seen that with internet usage growth ? …yet. ? I mean has the internet bandwidth usage ever gone down nationally/globally , similar to like a graph of the housing market in 2007/2008 ? -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Tue Apr 2 18:15:38 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 2 Apr 2019 13:15:38 -0500 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: <001c01d4e980$13aa98a0$3affc9e0$@gvtc.com> “…especially in the face of transport tweaks such as QUIC and TCP BBR? “ Do these “quic and tcp bbr” change bandwidth utilization as we’ve know it for years ? -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Tue Apr 2 18:20:02 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 2 Apr 2019 14:20:02 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: <001c01d4e980$13aa98a0$3affc9e0$@gvtc.com> References: <001c01d4e980$13aa98a0$3affc9e0$@gvtc.com> Message-ID: We have GB/mo figures for our customers for every month for the last ~10 years. Is there some simple figure you're looking for? I can tell you off hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500 GB/mo at similar rates per month. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Apr 2, 2019 at 2:16 PM Aaron Gould wrote: > “…especially in the face of transport tweaks such as QUIC and TCP BBR? “ > > > > Do these “quic and tcp bbr” change bandwidth utilization as we’ve know it > for years ? > > > > -Aaron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Tue Apr 2 18:24:46 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 2 Apr 2019 20:24:46 +0200 (CEST) Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: On Tue, 2 Apr 2019, Tom Ammon wrote: > Netflow for historical data is great, but I guess what I am really > asking is - how do you anticipate the load that your eyeballs are going > to bring to your network, especially in the face of transport tweaks > such as QUIC and TCP BBR? I don't see how QUIC and BBR is going to change how much bandwidth is flowing. If you want to make your eyeballs happy then make sure you're not congesting your upstream links. Aim for max 50-75% utilization in 5 minute average at peak hour (graph by polling interface counters every 5 minutes). Depending on your growth curve you might need to initiate upgrades to make sure they're complete before utilization hits 75%. If you have thousands of users then typically just look at the statistics per user and extrapolate. I don't believe this has fundamentally changed in the past 20 years, this is still best common practice. If you go into the game of running your links full parts of the day then you're into the game of trying to figure out QoE values which might mean you spend more time doing that than the upgrade would cost. -- Mikael Abrahamsson email: swmike at swm.pp.se From deleskie at gmail.com Tue Apr 2 18:35:43 2019 From: deleskie at gmail.com (jim deleskie) Date: Tue, 2 Apr 2019 15:35:43 -0300 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: +1 on this. its been more than 10 years since I've been responsible for a broadband network but have friends that still play in that world and do some very good work on making sure their models are very well managed, with more math than I ever bothered with, That being said, If had used the methods I'd had used back in the 90's they would have fully predicted per sub growth including all the FB/YoutubeNetflix traffic we have today. The "rapid" growth we say in the 90's and the 2000' and even this decade are all magically the same curve, we'd just further up the incline, the question is will it continue another 10+ years, where the growth rate is nearing straight up :) -jim On Tue, Apr 2, 2019 at 3:26 PM Mikael Abrahamsson wrote: > On Tue, 2 Apr 2019, Tom Ammon wrote: > > > Netflow for historical data is great, but I guess what I am really > > asking is - how do you anticipate the load that your eyeballs are going > > to bring to your network, especially in the face of transport tweaks > > such as QUIC and TCP BBR? > > I don't see how QUIC and BBR is going to change how much bandwidth is > flowing. > > If you want to make your eyeballs happy then make sure you're not > congesting your upstream links. Aim for max 50-75% utilization in 5 minute > average at peak hour (graph by polling interface counters every 5 > minutes). Depending on your growth curve you might need to initiate > upgrades to make sure they're complete before utilization hits 75%. > > If you have thousands of users then typically just look at the statistics > per user and extrapolate. I don't believe this has fundamentally changed > in the past 20 years, this is still best common practice. > > If you go into the game of running your links full parts of the day then > you're into the game of trying to figure out QoE values which might mean > you spend more time doing that than the upgrade would cost. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at enger.us Tue Apr 2 17:36:12 2019 From: nanog at enger.us (Robert M. Enger) Date: Tue, 2 Apr 2019 13:36:12 -0400 (EDT) Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: <1488131553.3697908.1554226572658.JavaMail.zimbra@enger.us> An article was published recently that discusses the possible impact of Cloud-based gaming on last-mile capacity requirements, as well as external connections. The author suggests that decentralized video services won't be the only big user of last-mile capacity. https://medium.com/@rudolfvanderberg/what-google-stadia-will-mean-for-broadband-and-interconnection-and-sony-microsoft-and-nintendo-fe20866e6c5b From: "Tom Ammon" To: "NANOG" Sent: Tuesday, April 2, 2019 9:54:47 AM Subject: modeling residential subscriber bandwidth demand How do people model and try to project residential subscriber bandwidth demands into the future? Do you base it primarily on historical data? Are there more sophisticated approaches that you use to figure out how much backbone bandwidth you need to build to keep your eyeballs happy? Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.connolly at verizon.com Tue Apr 2 18:03:44 2019 From: thomas.connolly at verizon.com (thomas.connolly at verizon.com) Date: Tue, 2 Apr 2019 18:03:44 +0000 Subject: Google AS15169 trace route request Message-ID: Hello all, If there’s someone on the Google (AS15169) network, preferably in San Jose or Denver area, could you please send me a trace route to the following IP: 2600:1010:b062:616f:f0da:421c:c752:2780 Off-list would be great, we are trying to identify the return path for traffic being sourced through AS2828 (former XO). Thanks, Tom [Verizon] Tom Connolly Principal Member of Technical Staff - National Operations 4800 Concentric Blvd, Saginaw, MI 48604 T: 989-758-6563 C: 989-493-9356 E: thomas.connolly at verizon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From deleskie at gmail.com Tue Apr 2 18:56:09 2019 From: deleskie at gmail.com (jim deleskie) Date: Tue, 2 Apr 2019 15:56:09 -0300 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: Louie, Its almost like us old guys knew something, and did know everything back then, the more things have changed the more that they have stayed the same :) -jim On Tue, Apr 2, 2019 at 3:52 PM Louie Lee wrote: > +1 Also on this. > > From my viewpoint, the game is roughly the same for the last 20+ years. > You might want to validate that your per-customer bandwidth use across your > markets is roughly the same for the same service/speeds/product. If you > have that data over time, then you can extrapolate what each market's > bandwidth use would be when you lay on a customer growth forecast. > > But for something that's simpler and actionable now, yeah, just make sure > that your upstream and peering(!!) links are not congested. I agree that > the 50-75% is a good target not only for the lead time to bring up more > capacity, but also to allow for spikes in traffic for various events > throughout the year. > > Louie > Google Fiber > > > On Tue, Apr 2, 2019 at 11:36 AM jim deleskie wrote: > >> +1 on this. its been more than 10 years since I've been responsible for a >> broadband network but have friends that still play in that world and do >> some very good work on making sure their models are very well managed, with >> more math than I ever bothered with, That being said, If had used the >> methods I'd had used back in the 90's they would have fully predicted per >> sub growth including all the FB/YoutubeNetflix traffic we have today. The >> "rapid" growth we say in the 90's and the 2000' and even this decade are >> all magically the same curve, we'd just further up the incline, the >> question is will it continue another 10+ years, where the growth rate is >> nearing straight up :) >> >> -jim >> >> On Tue, Apr 2, 2019 at 3:26 PM Mikael Abrahamsson >> wrote: >> >>> On Tue, 2 Apr 2019, Tom Ammon wrote: >>> >>> > Netflow for historical data is great, but I guess what I am really >>> > asking is - how do you anticipate the load that your eyeballs are >>> going >>> > to bring to your network, especially in the face of transport tweaks >>> > such as QUIC and TCP BBR? >>> >>> I don't see how QUIC and BBR is going to change how much bandwidth is >>> flowing. >>> >>> If you want to make your eyeballs happy then make sure you're not >>> congesting your upstream links. Aim for max 50-75% utilization in 5 >>> minute >>> average at peak hour (graph by polling interface counters every 5 >>> minutes). Depending on your growth curve you might need to initiate >>> upgrades to make sure they're complete before utilization hits 75%. >>> >>> If you have thousands of users then typically just look at the >>> statistics >>> per user and extrapolate. I don't believe this has fundamentally changed >>> in the past 20 years, this is still best common practice. >>> >>> If you go into the game of running your links full parts of the day then >>> you're into the game of trying to figure out QoE values which might mean >>> you spend more time doing that than the upgrade would cost. >>> >>> -- >>> Mikael Abrahamsson email: swmike at swm.pp.se >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Apr 2 18:58:08 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 2 Apr 2019 14:58:08 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> > On Apr 2, 2019, at 2:35 PM, jim deleskie wrote: > > +1 on this. its been more than 10 years since I've been responsible for a broadband network but have friends that still play in that world and do some very good work on making sure their models are very well managed, with more math than I ever bothered with, That being said, If had used the methods I'd had used back in the 90's they would have fully predicted per sub growth including all the FB/YoutubeNetflix traffic we have today. The "rapid" growth we say in the 90's and the 2000' and even this decade are all magically the same curve, we'd just further up the incline, the question is will it continue another 10+ years, where the growth rate is nearing straight up :) I think sometimes folks have the challenge with how to deal with aggregate scale and growth vs what happens in a pure linear model with subscribers. The first 75 users look a lot different than the next 900. You get different population scale and average usage. I could roughly estimate some high numbers for population of earth internet usage at peak for maximum, but in most cases if you have a 1G connection you can support 500-800 subscribers these days. Ideally you can get a 10G link for a reasonable price. Your scale looks different as well as you can work with “the content guys” once you get far enough. Thursdays are still the peak because date night is still generally Friday. - Jared From louiel at google.com Tue Apr 2 18:52:10 2019 From: louiel at google.com (Louie Lee) Date: Tue, 2 Apr 2019 11:52:10 -0700 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: +1 Also on this. >From my viewpoint, the game is roughly the same for the last 20+ years. You might want to validate that your per-customer bandwidth use across your markets is roughly the same for the same service/speeds/product. If you have that data over time, then you can extrapolate what each market's bandwidth use would be when you lay on a customer growth forecast. But for something that's simpler and actionable now, yeah, just make sure that your upstream and peering(!!) links are not congested. I agree that the 50-75% is a good target not only for the lead time to bring up more capacity, but also to allow for spikes in traffic for various events throughout the year. Louie Google Fiber On Tue, Apr 2, 2019 at 11:36 AM jim deleskie wrote: > +1 on this. its been more than 10 years since I've been responsible for a > broadband network but have friends that still play in that world and do > some very good work on making sure their models are very well managed, with > more math than I ever bothered with, That being said, If had used the > methods I'd had used back in the 90's they would have fully predicted per > sub growth including all the FB/YoutubeNetflix traffic we have today. The > "rapid" growth we say in the 90's and the 2000' and even this decade are > all magically the same curve, we'd just further up the incline, the > question is will it continue another 10+ years, where the growth rate is > nearing straight up :) > > -jim > > On Tue, Apr 2, 2019 at 3:26 PM Mikael Abrahamsson > wrote: > >> On Tue, 2 Apr 2019, Tom Ammon wrote: >> >> > Netflow for historical data is great, but I guess what I am really >> > asking is - how do you anticipate the load that your eyeballs are going >> > to bring to your network, especially in the face of transport tweaks >> > such as QUIC and TCP BBR? >> >> I don't see how QUIC and BBR is going to change how much bandwidth is >> flowing. >> >> If you want to make your eyeballs happy then make sure you're not >> congesting your upstream links. Aim for max 50-75% utilization in 5 >> minute >> average at peak hour (graph by polling interface counters every 5 >> minutes). Depending on your growth curve you might need to initiate >> upgrades to make sure they're complete before utilization hits 75%. >> >> If you have thousands of users then typically just look at the statistics >> per user and extrapolate. I don't believe this has fundamentally changed >> in the past 20 years, this is still best common practice. >> >> If you go into the game of running your links full parts of the day then >> you're into the game of trying to figure out QoE values which might mean >> you spend more time doing that than the upgrade would cost. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louiel at google.com Tue Apr 2 19:21:27 2019 From: louiel at google.com (Louie Lee) Date: Tue, 2 Apr 2019 12:21:27 -0700 Subject: modeling residential subscriber bandwidth demand In-Reply-To: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> Message-ID: Certainly. Projecting demand is one thing. Figuring out what to buy for your backbone, edge (uplink & peer), and colo (for CDN caches too!), for which scale+growth is quite another. And yeah, Jim, overall, things have stayed the same. There are just the nuances added with caches, gaming, OTT streaming, some IoT (like always-on home security cams) plus better tools now for network management and network analysis. Louie Google Fiber. On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch wrote: > > > > On Apr 2, 2019, at 2:35 PM, jim deleskie wrote: > > > > +1 on this. its been more than 10 years since I've been responsible for > a broadband network but have friends that still play in that world and do > some very good work on making sure their models are very well managed, with > more math than I ever bothered with, That being said, If had used the > methods I'd had used back in the 90's they would have fully predicted per > sub growth including all the FB/YoutubeNetflix traffic we have today. The > "rapid" growth we say in the 90's and the 2000' and even this decade are > all magically the same curve, we'd just further up the incline, the > question is will it continue another 10+ years, where the growth rate is > nearing straight up :) > > > I think sometimes folks have the challenge with how to deal with aggregate > scale and growth vs what happens in a pure linear model with subscribers. > > The first 75 users look a lot different than the next 900. You get > different population scale and average usage. > > I could roughly estimate some high numbers for population of earth > internet usage at peak for maximum, but in most cases if you have a 1G > connection you can support 500-800 subscribers these days. Ideally you can > get a 10G link for a reasonable price. Your scale looks different as well > as you can work with “the content guys” once you get far enough. > > Thursdays are still the peak because date night is still generally Friday. > > - Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nashnetworks.ca Tue Apr 2 21:21:58 2019 From: paul at nashnetworks.ca (Paul Nash) Date: Tue, 2 Apr 2019 17:21:58 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> Message-ID: <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I have had no complains about speed in 4 1/2 years. I have been planning to bump them to 1G for the last 4 years, but there is currently no economic justification. paul > On Apr 2, 2019, at 3:21 PM, Louie Lee via NANOG wrote: > > Certainly. > > Projecting demand is one thing. Figuring out what to buy for your backbone, edge (uplink & peer), and colo (for CDN caches too!), for which scale+growth is quite another. > > And yeah, Jim, overall, things have stayed the same. There are just the nuances added with caches, gaming, OTT streaming, some IoT (like always-on home security cams) plus better tools now for network management and network analysis. > > Louie > Google Fiber. > > > > On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch wrote: > > > > On Apr 2, 2019, at 2:35 PM, jim deleskie wrote: > > > > +1 on this. its been more than 10 years since I've been responsible for a broadband network but have friends that still play in that world and do some very good work on making sure their models are very well managed, with more math than I ever bothered with, That being said, If had used the methods I'd had used back in the 90's they would have fully predicted per sub growth including all the FB/YoutubeNetflix traffic we have today. The "rapid" growth we say in the 90's and the 2000' and even this decade are all magically the same curve, we'd just further up the incline, the question is will it continue another 10+ years, where the growth rate is nearing straight up :) > > > I think sometimes folks have the challenge with how to deal with aggregate scale and growth vs what happens in a pure linear model with subscribers. > > The first 75 users look a lot different than the next 900. You get different population scale and average usage. > > I could roughly estimate some high numbers for population of earth internet usage at peak for maximum, but in most cases if you have a 1G connection you can support 500-800 subscribers these days. Ideally you can get a 10G link for a reasonable price. Your scale looks different as well as you can work with “the content guys” once you get far enough. > > Thursdays are still the peak because date night is still generally Friday. > > - Jared From jared at puck.nether.net Tue Apr 2 21:44:09 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 2 Apr 2019 17:44:09 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> Message-ID: I would say this is perhaps atypical but may depend on the customer type(s). If they’re residential and use OTT data then sure. If it’s SMB you’re likely in better shape. - Jared > On Apr 2, 2019, at 5:21 PM, Paul Nash wrote: > > FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I have had no complains about speed in 4 1/2 years. I have been planning to bump them to 1G for the last 4 years, but there is currently no economic justification. > > paul > > >> On Apr 2, 2019, at 3:21 PM, Louie Lee via NANOG wrote: >> >> Certainly. >> >> Projecting demand is one thing. Figuring out what to buy for your backbone, edge (uplink & peer), and colo (for CDN caches too!), for which scale+growth is quite another. >> >> And yeah, Jim, overall, things have stayed the same. There are just the nuances added with caches, gaming, OTT streaming, some IoT (like always-on home security cams) plus better tools now for network management and network analysis. >> >> Louie >> Google Fiber. >> >> >> >> On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch wrote: >> >> >>> On Apr 2, 2019, at 2:35 PM, jim deleskie wrote: >>> >>> +1 on this. its been more than 10 years since I've been responsible for a broadband network but have friends that still play in that world and do some very good work on making sure their models are very well managed, with more math than I ever bothered with, That being said, If had used the methods I'd had used back in the 90's they would have fully predicted per sub growth including all the FB/YoutubeNetflix traffic we have today. The "rapid" growth we say in the 90's and the 2000' and even this decade are all magically the same curve, we'd just further up the incline, the question is will it continue another 10+ years, where the growth rate is nearing straight up :) >> >> >> I think sometimes folks have the challenge with how to deal with aggregate scale and growth vs what happens in a pure linear model with subscribers. >> >> The first 75 users look a lot different than the next 900. You get different population scale and average usage. >> >> I could roughly estimate some high numbers for population of earth internet usage at peak for maximum, but in most cases if you have a 1G connection you can support 500-800 subscribers these days. Ideally you can get a 10G link for a reasonable price. Your scale looks different as well as you can work with “the content guys” once you get far enough. >> >> Thursdays are still the peak because date night is still generally Friday. >> >> - Jared From paul at nashnetworks.ca Tue Apr 2 21:49:21 2019 From: paul at nashnetworks.ca (Paul Nash) Date: Tue, 2 Apr 2019 17:49:21 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> Message-ID: <6E132ECB-A2B4-4799-98CA-3ED7BA9BB36D@nashnetworks.ca> Mixed residential (ages 25 - 75, 1 - 6 people per unit), group who worked together to keep costs down. Works well for them. Friday nights we get to about 85% utilization (Netflix), other than that, usually sits between 25 - 45% paul > On Apr 2, 2019, at 5:44 PM, Jared Mauch wrote: > > I would say this is perhaps atypical but may depend on the customer type(s). > > If they’re residential and use OTT data then sure. If it’s SMB you’re likely in better shape. > > - Jared > > >> On Apr 2, 2019, at 5:21 PM, Paul Nash wrote: >> >> FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I have had no complains about speed in 4 1/2 years. I have been planning to bump them to 1G for the last 4 years, but there is currently no economic justification. >> >> paul >> >> >>> On Apr 2, 2019, at 3:21 PM, Louie Lee via NANOG wrote: >>> >>> Certainly. >>> >>> Projecting demand is one thing. Figuring out what to buy for your backbone, edge (uplink & peer), and colo (for CDN caches too!), for which scale+growth is quite another. >>> >>> And yeah, Jim, overall, things have stayed the same. There are just the nuances added with caches, gaming, OTT streaming, some IoT (like always-on home security cams) plus better tools now for network management and network analysis. >>> >>> Louie >>> Google Fiber. >>> >>> >>> >>> On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch wrote: >>> >>> >>>> On Apr 2, 2019, at 2:35 PM, jim deleskie wrote: >>>> >>>> +1 on this. its been more than 10 years since I've been responsible for a broadband network but have friends that still play in that world and do some very good work on making sure their models are very well managed, with more math than I ever bothered with, That being said, If had used the methods I'd had used back in the 90's they would have fully predicted per sub growth including all the FB/YoutubeNetflix traffic we have today. The "rapid" growth we say in the 90's and the 2000' and even this decade are all magically the same curve, we'd just further up the incline, the question is will it continue another 10+ years, where the growth rate is nearing straight up :) >>> >>> >>> I think sometimes folks have the challenge with how to deal with aggregate scale and growth vs what happens in a pure linear model with subscribers. >>> >>> The first 75 users look a lot different than the next 900. You get different population scale and average usage. >>> >>> I could roughly estimate some high numbers for population of earth internet usage at peak for maximum, but in most cases if you have a 1G connection you can support 500-800 subscribers these days. Ideally you can get a 10G link for a reasonable price. Your scale looks different as well as you can work with “the content guys” once you get far enough. >>> >>> Thursdays are still the peak because date night is still generally Friday. >>> >>> - Jared > From thomasammon at gmail.com Wed Apr 3 02:01:01 2019 From: thomasammon at gmail.com (Tom Ammon) Date: Tue, 2 Apr 2019 22:01:01 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: <001c01d4e980$13aa98a0$3affc9e0$@gvtc.com> Message-ID: On Tue, Apr 2, 2019 at 2:20 PM Josh Luthman wrote: > We have GB/mo figures for our customers for every month for the last ~10 > years. Is there some simple figure you're looking for? I can tell you off > hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500 > GB/mo at similar rates per month. > > I'm mostly just wondering what others do for this kind of planning - trying to look outside of my own experience, so I don't miss something obvious. That growth in total transfer that you mention is interesting. I always wonder what the value of trying to predict utilization is anyway, especially since bandwidth is so cheap. But I figure it can't hurt to ask a group of people where I am highly likely to find somebody smarter than I am :-) -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Wed Apr 3 05:35:21 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 3 Apr 2019 07:35:21 +0200 (CEST) Subject: modeling residential subscriber bandwidth demand In-Reply-To: <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> Message-ID: On Tue, 2 Apr 2019, Paul Nash wrote: > FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I > have had no complains about speed in 4 1/2 years. I have been planning > to bump them to 1G for the last 4 years, but there is currently no > economic justification. I know FTTH footprints where peak evening average per customer is 3-5 megabit/s. I know others who claim their customers only average equivalent 5-10% of that. It all depends on what services you offer. Considering my household has 250/100 for 40 USD a month I'd say your above solution wouldn't even be enough to deliver an acceptable service to even 10 households. -- Mikael Abrahamsson email: swmike at swm.pp.se From ben at 6by7.net Wed Apr 3 06:53:06 2019 From: ben at 6by7.net (Ben Cannon) Date: Tue, 2 Apr 2019 23:53:06 -0700 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> Message-ID: <3ED0E6F2-60FB-4CF0-94B0-A976E7E43BC4@6by7.net> A 100/100 enterprise connection can easily support hundreds of desktop users if not more. It’s a lot of bandwidth even today. -Ben > On Apr 2, 2019, at 10:35 PM, Mikael Abrahamsson wrote: > >> On Tue, 2 Apr 2019, Paul Nash wrote: >> >> FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I have had no complains about speed in 4 1/2 years. I have been planning to bump them to 1G for the last 4 years, but there is currently no economic justification. > > I know FTTH footprints where peak evening average per customer is 3-5 megabit/s. I know others who claim their customers only average equivalent 5-10% of that. > > It all depends on what services you offer. Considering my household has 250/100 for 40 USD a month I'd say your above solution wouldn't even be enough to deliver an acceptable service to even 10 households. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From valdis.kletnieks at vt.edu Wed Apr 3 07:45:17 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 03 Apr 2019 03:45:17 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: <3ED0E6F2-60FB-4CF0-94B0-A976E7E43BC4@6by7.net> References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> <3ED0E6F2-60FB-4CF0-94B0-A976E7E43BC4@6by7.net> Message-ID: <8066.1554277517@turing-police> On Tue, 02 Apr 2019 23:53:06 -0700, Ben Cannon said: > A 100/100 enterprise connection can easily support hundreds of desktop users > if not more. It’s a lot of bandwidth even today. And what happens when a significant fraction of those users fire up Netflix with an HD stream? We're discussing residential not corporate connections, I thought.... From darin.steffl at mnwifi.com Wed Apr 3 12:41:16 2019 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Wed, 3 Apr 2019 07:41:16 -0500 Subject: modeling residential subscriber bandwidth demand In-Reply-To: <8066.1554277517@turing-police> References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> <3ED0E6F2-60FB-4CF0-94B0-A976E7E43BC4@6by7.net> <8066.1554277517@turing-police> Message-ID: Paul, I have hard time seeing how you aren't maxing out that circuit. We see about 2.3 mbps average per customer at peak with a primarily residential user base. That would about 575 mbps average at peak for 250 users on our network so how do we use 575 but you say your users don't even top 100 mbps at peak? It doesn't make sense that our customers use 6 times as much bandwidth at peak than yours do. We're a rural and small town mix in Minnesota, no urban areas in our coverage. 90% of our customers are on a plan 22 mbps or less and the other 10% are on a 100 mbps plan but their average usage isn't really much higher. Enterprise environments can easily handle many more users on a 100 meg circuit because they aren't typically streaming video like they would be at home. Residential will always be much higher usage per person than most enterprise users. On Wed, Apr 3, 2019, 2:46 AM Valdis Klētnieks wrote: > On Tue, 02 Apr 2019 23:53:06 -0700, Ben Cannon said: > > A 100/100 enterprise connection can easily support hundreds of desktop > users > > if not more. It’s a lot of bandwidth even today. > > And what happens when a significant fraction of those users fire up > Netflix with > an HD stream? > > We're discussing residential not corporate connections, I thought.... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ed.whitesell at gmail.com Wed Apr 3 12:59:36 2019 From: ed.whitesell at gmail.com (Ed Whitesell) Date: Wed, 3 Apr 2019 07:59:36 -0500 Subject: Contact Request: Gannett Message-ID: Greetings - If there is anyone from Gannett on the list, I'd appreciate it if you would reach out. You've got some Route53 monitoring traffic directed at one of our AWS ELBs. Thanks, Ed From paul at nashnetworks.ca Wed Apr 3 14:07:27 2019 From: paul at nashnetworks.ca (Paul Nash) Date: Wed, 3 Apr 2019 10:07:27 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> <3ED0E6F2-60FB-4CF0-94B0-A976E7E43BC4@6by7.net> <8066.1554277517@turing-police> Message-ID: I am also surprised. However, we have had a total of 5 complaints about network speed over a 3 year period. One possible reason is that because they own the infrastructure collectively and pay for the bandwidth directly (I just manage everything for them), they are prepared to put up with the odd slowdown to avoid the expense of an upgrade. Our original plan was to start with the 100M circuit so that they could make sure that everything would work, that we had reliable wifi delivery (about 95% of users only use a wifi connection to their computers/iDevices/whatever), and then to upgrade to 1G as soon as the dust started settling. They have postponed the upgrade for 3 years now, with no complaints. I guess that if they will be directly impacted by higher bandwidth costs, some people can make do with slower service (or something). paul > On Apr 3, 2019, at 8:41 AM, Darin Steffl wrote: > > Paul, > > I have hard time seeing how you aren't maxing out that circuit. We see about 2.3 mbps average per customer at peak with a primarily residential user base. That would about 575 mbps average at peak for 250 users on our network so how do we use 575 but you say your users don't even top 100 mbps at peak? It doesn't make sense that our customers use 6 times as much bandwidth at peak than yours do. > > We're a rural and small town mix in Minnesota, no urban areas in our coverage. 90% of our customers are on a plan 22 mbps or less and the other 10% are on a 100 mbps plan but their average usage isn't really much higher. > > > Enterprise environments can easily handle many more users on a 100 meg circuit because they aren't typically streaming video like they would be at home. Residential will always be much higher usage per person than most enterprise users. > > On Wed, Apr 3, 2019, 2:46 AM Valdis Klētnieks wrote: > On Tue, 02 Apr 2019 23:53:06 -0700, Ben Cannon said: > > A 100/100 enterprise connection can easily support hundreds of desktop users > > if not more. It’s a lot of bandwidth even today. > > And what happens when a significant fraction of those users fire up Netflix with > an HD stream? > > We're discussing residential not corporate connections, I thought.... > From jayb at braeburn.org Wed Apr 3 14:59:18 2019 From: jayb at braeburn.org (Jay Borkenhagen) Date: Wed, 3 Apr 2019 10:59:18 -0400 Subject: SOLVED (was Re: request for help: 192.139.135.0/24) In-Reply-To: <77BF56D8-998F-4718-B353-FAB8392B3C19@Cable.Comcast.com> References: <23714.18850.7120.200041@oz.mt.att.com> <77BF56D8-998F-4718-B353-FAB8392B3C19@Cable.Comcast.com> Message-ID: <23716.51782.126890.78437@oz.mt.att.com> Hi nanog, With help from China Unicom (as4837) and from folks in other key places around the 'net, I am happy to report that this route mis-origination has now been successfully resolved. Thanks, all! I urge folks facing similar problems to publish RPKI ROAs for their IP resources. I started on this mission after I noticed a discrepancy regarding the validation state of this prefix in the as7018 network. Someday when more networks perform RPKI route origin validation more broadly this kind of issue will be addressed automatically, but even prior to that happening, the verifiable statements in RPKI ROAs can be attributed to you as the actual resource holder, thus helping folks base their response actions on your intent. If you are not facing similar problems today, you could be tomorrow: so publish your ROAs now! Thanks. Jay B. Smith, Courtney writes: > Any luck reaching AS4837? > > route-views>show ip bgp 192.139.135.0/24 longer-prefixes > BGP table version is 103101215, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, > r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, > x best-external, a additional-path, c RIB-compressed, > Origin codes: i - IGP, e - EGP, ? - incomplete > RPKI validation codes: V valid, I invalid, N Not found > > Network Next Hop Metric LocPrf Weight Path > * 192.139.135.0 208.51.134.254 0 0 3549 3356 4837 4808 i > * 194.85.40.15 0 0 3267 3356 4837 4808 i > * 193.0.0.56 0 3333 1273 4837 4808 i > * 37.139.139.0 0 57866 6762 4837 4808 i > * 12.0.1.63 0 7018 1299 53292 63251 ? > * 140.192.8.16 0 54728 20130 6939 4837 4808 i > * 91.218.184.60 0 49788 1299 53292 63251 ? > * 203.181.248.168 0 7660 2516 4837 4808 i > * 154.11.12.212 0 0 852 4837 4808 i > * 134.222.87.1 700 0 286 1299 53292 63251 ? > * 209.124.176.223 0 101 101 3356 4837 4808 i > * 137.39.3.55 0 701 3356 4837 4808 i > * 94.142.247.3 0 0 8283 1299 53292 63251 ? > * 162.251.163.2 0 53767 3257 1299 53292 63251 ? > * 212.66.96.126 0 20912 1267 3356 4837 4808 i > * 198.58.198.255 0 1403 6461 4837 4808 i > * 198.58.198.254 0 1403 6461 4837 4808 i > *> 202.232.0.2 0 2497 4837 4808 i > * 203.62.252.83 0 1221 4637 4837 4808 i > * 132.198.255.253 0 1351 6939 4837 4808 i > * 206.24.210.80 0 3561 209 4837 4808 i > * 195.208.112.161 0 3277 39710 9002 3356 4837 4808 i > * 217.192.89.50 0 3303 4837 4808 i > * 173.205.57.234 0 53364 3257 1299 53292 63251 ? > * 207.172.6.20 0 0 6079 3356 4837 4808 i > * 207.172.6.1 0 0 6079 3356 4837 4808 i > * 208.74.64.40 0 19214 174 3356 4837 4808 i > * 144.228.241.130 240 0 1239 4837 4808 i > * 162.250.137.254 0 4901 6079 3356 4837 4808 i > * 114.31.199.1 0 4826 1299 53292 63251 i > * 64.71.137.241 0 6939 4837 4808 i > route-views> > > On 4/1/19, 1:30 PM, "NANOG on behalf of Jay Borkenhagen" wrote: > > [No attempts at 01-April humor will be attempted in this message.] > > > Seeking help from routing engineers around the 'net: > > > ARIN documents that 192.139.135.0/24 has been allocated to Metro > Wireless International: > > https://whois.arin.net/rest/net/NET-192-139-135-0-1 > > Further, the party to whom 192.139.135.0/24 has been allocated has > published a ROA in ARIN's hosted RPKI asserting that bgp announcements > for that prefix are valid only when originating in AS63251. To view > this, go to your favorite RPKI vantage point that uses ARIN's TAL. If > you don't yet have a favorite, feel free to telnet to > route-server.ip.att.net and run: > > show validation database record 192.139.135.0/24 > > > Unfortunately, as may be seen at route-views, etc, most of the > Internet now prefers an invalid path that's mis-originated in as4808: > > > Network Next Hop Path > * 192.139.135.0 208.51.134.254 3549 3356 4837 4808 i > * 194.85.40.15 3267 3356 4837 4808 i > * 193.0.0.56 3333 1273 4837 4808 i > * 37.139.139.0 57866 6762 4837 4808 i > * 12.0.1.63 7018 1299 53292 63251 ? > * 140.192.8.16 54728 20130 6939 4837 4808 i > * 91.218.184.60 49788 1299 53292 63251 ? > * 203.181.248.168 7660 2516 4837 4808 i > * 154.11.12.212 852 4837 4808 i > * 134.222.87.1 286 1299 53292 63251 ? > * 209.124.176.223 101 101 3356 4837 4808 i > * 137.39.3.55 701 4837 4808 i > * 94.142.247.3 8283 1239 4837 4808 i > * 162.251.163.2 53767 3257 1299 53292 63251 ? > * 212.66.96.126 20912 1267 3356 4837 4808 i > * 198.58.198.255 1403 6461 4837 4808 i > * 198.58.198.254 1403 6461 4837 4808 i > *> 202.232.0.2 2497 4837 4808 i > * 203.62.252.83 1221 4637 4837 4808 i > * 132.198.255.253 1351 6939 4837 4808 i > * 206.24.210.80 3561 209 4837 4808 i > * 195.208.112.161 3277 39710 9002 3356 4837 4808 i > * 217.192.89.50 3303 4837 4808 i > * 173.205.57.234 53364 3257 1299 53292 63251 ? > * 207.172.6.20 6079 3356 4837 4808 i > * 207.172.6.1 6079 3356 4837 4808 i > * 208.74.64.40 19214 174 4837 4837 4808 i > * 144.228.241.130 1239 4837 4808 i > * 162.250.137.254 4901 6079 3356 4837 4808 i > * 114.31.199.1 4826 1299 53292 63251 i > * 64.71.137.241 6939 4837 4808 i > > > Please help the Metro Wireless International folks get this cleared up > so their 192.139.135.0/24 can once again be usable. In particular, > help is sought from 4837 and their transit providers: > > 1239 > 701 > 3356 > > (Yes, I am trying to reach folks at those networks in other ways, too.) > > > Thanks. > > Jay B. > > > > From Matt.Torres at state.or.us Wed Apr 3 15:20:17 2019 From: Matt.Torres at state.or.us (Torres, Matt) Date: Wed, 3 Apr 2019 15:20:17 +0000 Subject: Purchasing IPv4 space - due diligence homework Message-ID: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> All, Side stepping a migration to IPv6 debate.... I'd like to hear advise from the group about performing due diligence research on an IPv4 block before purchasing it on the secondary market (on behalf of an end-user company). My research has branched into two questions: a) What 'checks' should I perform?, and b) what results from those checks should cause us to walk away? My current list is: 1. Check BGP looking glass for route. It should not show up in the Internet routing table. If it does, walk away. 2. Check the ARIN registry. The longer history without recent transfers or changes is better. I don't know what explicit results should cause me to walk away here. 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. Anything else? Advise? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed Apr 3 15:22:33 2019 From: job at ntt.net (Job Snijders) Date: Wed, 3 Apr 2019 15:22:33 +0000 Subject: SOLVED (was Re: request for help: 192.139.135.0/24) In-Reply-To: <23716.51782.126890.78437@oz.mt.att.com> References: <23714.18850.7120.200041@oz.mt.att.com> <77BF56D8-998F-4718-B353-FAB8392B3C19@Cable.Comcast.com> <23716.51782.126890.78437@oz.mt.att.com> Message-ID: <20190403152233.GC57635@vurt.meerval.net> Hi all, On Wed, Apr 03, 2019 at 10:59:18AM -0400, Jay Borkenhagen wrote: > I urge folks facing similar problems to publish RPKI ROAs for their IP > resources. [snip] the verifiable statements in RPKI ROAs can be > attributed to you as the actual resource holder, thus helping folks > base their response actions on your intent. > > If you are not facing similar problems today, you could be tomorrow: > so publish your ROAs now! Jay is touching upon a very important aspect here: without the RPKI ROA it would've taken NTT significantly more effort to decide whether removal of the erroneous IRR route object would've been appropriate or not. We consider RPKI ROAs a higher source of truth, so drawing conclusions when faced with unvalidated IRR data is a breeze. RPKI ROAs can be instrumental in resolving issues of administrative nature. Keep in mind that ROAs are not just for BGP Origin Validation but serve other useful purposes too. Publish your ROAs today! Kind regards, Job ps. Usual caveats apply to IP resources managed through ARIN; the ARIN TAL is not as well distributed as RPKI TALs from other RIRs; this essentially has lead to a degradation of the quality of ARIN's RPKI service. This policy proposal may help address operational issues: https://www.arin.net/participate/policy/drafts/2019_4/ From john at alcock.org Wed Apr 3 15:34:25 2019 From: john at alcock.org (John Alcock) Date: Wed, 3 Apr 2019 11:34:25 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: Well, I did all three above and still had issues. I am still having issues. I had to contact many people to get off of various blacklists, etc. These are lists that are not publish and you will not know until you start using the space. Luckily, I have had great help from the list here in getting support and in some cases back-channel support. The hard part is getting a hold of the right people. For example: Softlayer/IBM was initially blocking my ip space. But, it was not really them. It was NTT on behalf of Softlayer. The request has to come from Softlayer. That has been resolved. I honestly do not even know who to thank. I am currently fighting the same issue with playstation.com. Akami is blocking access on behalf of Sony. The request has to come from Sony. After many emails with abuse at playstation, I am making headway. Problem is not solved yet, but I believe they are making headway. Luckly Akami open a ticket and told me what to tell the Sony NOC. Right now, I am fighting some odd ball blocks. Several mobile banking sites. There is not even a support number. I am having to try and use the NOC/Abuse contacts via ARIN first and not having any luck. Try calling a bank and telling them that your are a network engineer and can not access their sites. That goes downhill pretty quick. If you can get past the first line of tech support it is a challenge. "Have you cleared your cookies? You need to call your ISP", then you get a 2nd line person who basically blows you off. Here is the thing. You will have problems. Just be prepared to make lots of phone calls and send lots of emails. Once you get to the right person, things can get a moving. John On Wed, Apr 3, 2019 at 11:20 AM Torres, Matt via NANOG wrote: > All, > > Side stepping a migration to IPv6 debate…. I’d like to hear advise from > the group about performing due diligence research on an IPv4 block before > purchasing it on the secondary market (on behalf of an end-user company). > My research has branched into two questions: a) What ‘checks’ should I > perform?, and b) what results from those checks should cause us to walk > away? > > > > My current list is: > > 1. Check BGP looking glass for route. It should not show up in the > Internet routing table. If it does, walk away. > 2. Check the ARIN registry. The longer history without recent > transfers or changes is better. I don’t know what explicit results should > cause me to walk away here. > 3. Check SORBS blacklisting. It should not show up except maybe the > DUHL list(?). If it does, walk away. > > > > Anything else? Advise? > > Thanks, > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Wed Apr 3 15:41:59 2019 From: matt at netfire.net (Matt Harris) Date: Wed, 3 Apr 2019 10:41:59 -0500 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: On Wed, Apr 3, 2019 at 10:34 AM John Alcock wrote: > Well, > > I did all three above and still had issues. I am still having issues. I > had to contact many people to get off of various blacklists, etc. These > are lists that are not publish and you will not know until you start using > the space. > > Here is the thing. You will have problems. Just be prepared to make lots > of phone calls and send lots of emails. Once you get to the right person, > things can get a moving. > > John > My experience has been quite different and quite a bit better. One of the things I paid attention to was whom the previous owner of the block was, what sort of company they were, and hence what their likely use case was. I have purchased/deployed a few /23s so far and have yet to run into any issues with blacklists. Some of the space I've purchased came from a small-town ISP which was acquired, and some came from newly-defunct retail-sector organizations. I stayed away from anything that had been associated with any sort of hosting, or that seemed to have been leased out in the past, etc. You can often check historical routing tables to see if more than one AS has announced the space in the past X number of years to identify blocks that have been leased around, and that's one other component you might want to consider looking at. But ultimately I think my best tactic has been to just check out the organization I'm acquiring it from and make sure they've owned it since the beginning via ARIN records. Dealing with a reputable broker is probably a good start, too. I've had no issues working with Hilco. Good luck! -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Apr 3 15:46:38 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 03 Apr 2019 11:46:38 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: <4308.1554306398@turing-police> On Wed, 03 Apr 2019 15:20:17 -0000, "Torres, Matt via NANOG" said: > 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. SORBS isn't the only place to check. As an example, if Spamhaus doesn't have nice things to say about the block, it's time to start asking questions.... http://www.anti-abuse.org/multi-rbl-check/ has a fairly good list of places that could give your customer a bad time (whether or not the listing is deserved - the point is that being listed anywhere there will probably mean problems that have to be cleaned up) You may all now begin the religious war over where else to check. From sroche at lakelandnetworks.com Wed Apr 3 15:48:38 2019 From: sroche at lakelandnetworks.com (Sam Roche) Date: Wed, 3 Apr 2019 15:48:38 +0000 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: I used this gentleman’s Powershell script and modified it slightly to check a block last summer. The broker we were using said that they also did their due diligence on the addresses, but I wanted to do our own because of the cost of the IPs. https://www.saotn.org/powershell-blacklist-check-script/ We worked with the Brander Group as a broker. They were great and have since launched a portal/storefront I believe. Kind regards, Sam. From: NANOG On Behalf Of John Alcock Sent: Wednesday, April 3, 2019 11:34 AM To: Torres, Matt Cc: nanog at nanog.org Subject: Re: Purchasing IPv4 space - due diligence homework Well, I did all three above and still had issues. I am still having issues. I had to contact many people to get off of various blacklists, etc. These are lists that are not publish and you will not know until you start using the space. Luckily, I have had great help from the list here in getting support and in some cases back-channel support. The hard part is getting a hold of the right people. For example: Softlayer/IBM was initially blocking my ip space. But, it was not really them. It was NTT on behalf of Softlayer. The request has to come from Softlayer. That has been resolved. I honestly do not even know who to thank. I am currently fighting the same issue with playstation.com. Akami is blocking access on behalf of Sony. The request has to come from Sony. After many emails with abuse at playstation, I am making headway. Problem is not solved yet, but I believe they are making headway. Luckly Akami open a ticket and told me what to tell the Sony NOC. Right now, I am fighting some odd ball blocks. Several mobile banking sites. There is not even a support number. I am having to try and use the NOC/Abuse contacts via ARIN first and not having any luck. Try calling a bank and telling them that your are a network engineer and can not access their sites. That goes downhill pretty quick. If you can get past the first line of tech support it is a challenge. "Have you cleared your cookies? You need to call your ISP", then you get a 2nd line person who basically blows you off. Here is the thing. You will have problems. Just be prepared to make lots of phone calls and send lots of emails. Once you get to the right person, things can get a moving. John On Wed, Apr 3, 2019 at 11:20 AM Torres, Matt via NANOG > wrote: All, Side stepping a migration to IPv6 debate…. I’d like to hear advise from the group about performing due diligence research on an IPv4 block before purchasing it on the secondary market (on behalf of an end-user company). My research has branched into two questions: a) What ‘checks’ should I perform?, and b) what results from those checks should cause us to walk away? My current list is: 1. Check BGP looking glass for route. It should not show up in the Internet routing table. If it does, walk away. 2. Check the ARIN registry. The longer history without recent transfers or changes is better. I don’t know what explicit results should cause me to walk away here. 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. Anything else? Advise? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Apr 3 15:58:23 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 Apr 2019 11:58:23 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: > On Apr 3, 2019, at 11:20 AM, Torres, Matt via NANOG wrote: > > All, > Side stepping a migration to IPv6 debate…. I’d like to hear advise from the group about performing due diligence research on an IPv4 block before purchasing it on the secondary market (on behalf of an end-user company). My research has branched into two questions: a) What ‘checks’ should I perform?, and b) what results from those checks should cause us to walk away? > > My current list is: > • Check BGP looking glass for route. It should not show up in the Internet routing table. If it does, walk away. > • Check the ARIN registry. The longer history without recent transfers or changes is better. I don’t know what explicit results should cause me to walk away here. > • Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. > > Anything else? Advise? I’d like to ask a related question (I’m not questioning why you need IPv4 space) but are you also deploying IPv6 as well? If not, is there a reason? In my copious spare time I’m doing a small FTTH network and many services do work well with IPv6 while others (banks are a an example) perhaps don’t. We have T-Mobile USA saying with their network most bits go out as v6, so I’m guessing there’s that 5-10% you need v4 for if you deploy as aggressively as they do. Mostly curious if you are doing IPv6 if you see that slowing your need for v4 or if they are growing at the same rate. - Jared From rvandolson at esri.com Wed Apr 3 16:03:17 2019 From: rvandolson at esri.com (Ray Van Dolson) Date: Wed, 3 Apr 2019 09:03:17 -0700 Subject: modeling residential subscriber bandwidth demand In-Reply-To: <8066.1554277517@turing-police> References: <65C46416-08D3-4D2E-8DD9-1B037C9B718E@puck.nether.net> <8AF96A82-7BFC-40A6-905B-5B300F6D5DE3@nashnetworks.ca> <3ED0E6F2-60FB-4CF0-94B0-A976E7E43BC4@6by7.net> <8066.1554277517@turing-police> Message-ID: <20190403160316.GA10773@esri.com> On Wed, Apr 03, 2019 at 03:45:17AM -0400, Valdis Klētnieks wrote: > On Tue, 02 Apr 2019 23:53:06 -0700, Ben Cannon said: > > A 100/100 enterprise connection can easily support hundreds of desktop users > > if not more. It???s a lot of bandwidth even today. > > And what happens when a significant fraction of those users fire up Netflix with > an HD stream? > > We're discussing residential not corporate connections, I thought.... > Yes, Enterprise requirements are certainly different, though inching upwards with the prevalance of SaaS services like Salesforce, O365 and file sharing services (the latter are a growing % of our traffic at branch offices). I feel like our rule of thumb on the Enterprise side is in the 1.5-2Mbps per user range these days (for Internet). Ray From valdis.kletnieks at vt.edu Wed Apr 3 16:04:36 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 03 Apr 2019 12:04:36 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: <5976.1554307476@turing-police> On Wed, 03 Apr 2019 11:58:23 -0400, Jared Mauch said: > Mostly curious if you are doing IPv6 if you see that slowing your need for v4 > or if they are growing at the same rate. And remember kids - the more you can push off to native IPv6, the longer you can push off an upgrade to your CGNAT box. ;) From jared at puck.nether.net Wed Apr 3 16:12:59 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 Apr 2019 12:12:59 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <5976.1554307476@turing-police> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> <5976.1554307476@turing-police> Message-ID: > On Apr 3, 2019, at 12:04 PM, Valdis Klētnieks wrote: > > On Wed, 03 Apr 2019 11:58:23 -0400, Jared Mauch said: > >> Mostly curious if you are doing IPv6 if you see that slowing your need for v4 >> or if they are growing at the same rate. > > And remember kids - the more you can push off to native IPv6, the longer you can > push off an upgrade to your CGNAT box. ;) For me, this is a big reason why if you’re doing CGNAT you want to compliment it with IPv6. At IETF last week there was an interesting discussion about the fact that things like DHCPv6-PD does not explicitly say that a DHCPv6-PD prefix should be inserted into the routing table (!), and you may not have the tools you need to mange these prefixes as a result. In DHCPv4 land of course you give out prefixes that are connected, but in DHCPv6-PD you may get something from a /56 to a /64 which may mean that route needs to go into your IGP. - Jared From nik at neko.id.au Wed Apr 3 17:20:34 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Wed, 3 Apr 2019 17:20:34 +0000 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <4308.1554306398@turing-police> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us>, <4308.1554306398@turing-police> Message-ID: <29702692-8054-4EF0-8BC5-D8633CBC9238@neko.id.au> A big +1 to checking Spamhaus, specifically their DROP and EDROP lists. These two lists are what causes us most pain when acquiring IPv4 space as a lot of providers put auto blocking in place based on these two which can be difficult to get removed. I won’t even contemplate prefixes on either of these lists unless the seller knocks $5/IP off the purchase price because of the associated time and pain trying to clean it up. Sent from my iPhone > On Apr 3, 2019, at 11:49 AM, Valdis Klētnieks wrote: > > On Wed, 03 Apr 2019 15:20:17 -0000, "Torres, Matt via NANOG" said: > >> 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. > > SORBS isn't the only place to check. As an example, if Spamhaus doesn't have > nice things to say about the block, it's time to start asking questions.... > > http://www.anti-abuse.org/multi-rbl-check/ has a fairly good list of > places that could give your customer a bad time (whether or not the > listing is deserved - the point is that being listed anywhere there will > probably mean problems that have to be cleaned up) > > You may all now begin the religious war over where else to check. > > From edugas at unknowndevice.ca Wed Apr 3 17:40:30 2019 From: edugas at unknowndevice.ca (Eric Dugas) Date: Wed, 3 Apr 2019 13:40:30 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <29702692-8054-4EF0-8BC5-D8633CBC9238@neko.id.au> References: <29702692-8054-4EF0-8BC5-D8633CBC9238@neko.id.au> Message-ID: <15322FD4-8230-4A48-A327-8B460A87E262@getmailspring.com> I cleaned two blocks last year with Spamhaus and others. Took me less than two weeks and Spamhaus were the quickest of the bunch (we're talking about a full or two business days). PSN can be tricky, same for Netflix and whatnot but I always put these new blocks in "quarantine" for a couple of weeks by using these services with random IPs in a new block. In order, I began to announce the prefixes right after the transfers were approved by ARIN. I then contacted Spamhaus and the others roughly a week later. As I mentioned, Spamhaus were really reactive. The others responded in about 2 weeks. What helped us (I think) is that we're a listed MANRS participant (so filtering, BCP38, proper NOC/Ops contacts). We also sign all of our routes with ROAs, proper route objects in an IRR and PTRs generated for every IPs. On Apr 3 2019, at 1:20 pm, Nikolas Geyer wrote: > A big +1 to checking Spamhaus, specifically their DROP and EDROP lists. These two lists are what causes us most pain when acquiring IPv4 space as a lot of providers put auto blocking in place based on these two which can be difficult to get removed. > > I won’t even contemplate prefixes on either of these lists unless the seller knocks $5/IP off the purchase price because of the associated time and pain trying to clean it up. > Sent from my iPhone > > On Apr 3, 2019, at 11:49 AM, Valdis Klētnieks wrote: > > On Wed, 03 Apr 2019 15:20:17 -0000, "Torres, Matt via NANOG" said: > > > 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. > > SORBS isn't the only place to check. As an example, if Spamhaus doesn't have > > nice things to say about the block, it's time to start asking questions.... > > > > http://www.anti-abuse.org/multi-rbl-check/ has a fairly good list of > > places that could give your customer a bad time (whether or not the > > listing is deserved - the point is that being listed anywhere there will > > probably mean problems that have to be cleaned up) > > > > You may all now begin the religious war over where else to check. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik at neko.id.au Wed Apr 3 18:03:19 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Wed, 3 Apr 2019 18:03:19 +0000 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <15322FD4-8230-4A48-A327-8B460A87E262@getmailspring.com> References: <29702692-8054-4EF0-8BC5-D8633CBC9238@neko.id.au>, <15322FD4-8230-4A48-A327-8B460A87E262@getmailspring.com> Message-ID: <2E71C4D9-49A2-4EDD-93C7-8837CF616ADD@neko.id.au> The issue isn’t with Spamhaus itself per se, more providers who implement automated edge filters based on those lists and then take a long time to get removed manually. Sent from my iPhone On Apr 3, 2019, at 1:40 PM, Eric Dugas > wrote: I cleaned two blocks last year with Spamhaus and others. Took me less than two weeks and Spamhaus were the quickest of the bunch (we're talking about a full or two business days). PSN can be tricky, same for Netflix and whatnot but I always put these new blocks in "quarantine" for a couple of weeks by using these services with random IPs in a new block. In order, I began to announce the prefixes right after the transfers were approved by ARIN. I then contacted Spamhaus and the others roughly a week later. As I mentioned, Spamhaus were really reactive. The others responded in about 2 weeks. What helped us (I think) is that we're a listed MANRS participant (so filtering, BCP38, proper NOC/Ops contacts). We also sign all of our routes with ROAs, proper route objects in an IRR and PTRs generated for every IPs. On Apr 3 2019, at 1:20 pm, Nikolas Geyer > wrote: A big +1 to checking Spamhaus, specifically their DROP and EDROP lists. These two lists are what causes us most pain when acquiring IPv4 space as a lot of providers put auto blocking in place based on these two which can be difficult to get removed. I won’t even contemplate prefixes on either of these lists unless the seller knocks $5/IP off the purchase price because of the associated time and pain trying to clean it up. Sent from my iPhone On Apr 3, 2019, at 11:49 AM, Valdis Klētnieks > wrote: On Wed, 03 Apr 2019 15:20:17 -0000, "Torres, Matt via NANOG" said: 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. SORBS isn't the only place to check. As an example, if Spamhaus doesn't have nice things to say about the block, it's time to start asking questions.... http://www.anti-abuse.org/multi-rbl-check/ has a fairly good list of places that could give your customer a bad time (whether or not the listing is deserved - the point is that being listed anywhere there will probably mean problems that have to be cleaned up) You may all now begin the religious war over where else to check. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ankost at podolsk.ru Wed Apr 3 14:20:12 2019 From: ankost at podolsk.ru (Andrey Kostin) Date: Wed, 03 Apr 2019 10:20:12 -0400 Subject: Deutsche Telecom AS3320 contact Message-ID: <91c2d6954e993882c0d9e5eab0cdde0d@podolsk.ru> Hi NANOG, Looking for a contact from AS3320 Deutsche Telekom to ask a question about their routing policy/filtering causing that some globally routed prefixes aren't seen in AS3320. Kind regards, Andrey Kostin From JHathaway at howardcenter.org Wed Apr 3 15:25:15 2019 From: JHathaway at howardcenter.org (Jeffrey Hathaway) Date: Wed, 3 Apr 2019 15:25:15 +0000 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: Hi, While I think #3 is important, it depends on your use of the end-block, and those entries can sometimes be cleaned up with some work. If the block is listed, that would certainly lower my buying price I am willing to pay for the block. I did buy a block once in the ARIN region which showed up in IP geolocation databases as Russian (no idea why), but it took me quite a while to get it fixed. Sincerely, Jeffrey Hathaway Information Technology * Howard Center Inc. From: NANOG On Behalf Of Torres, Matt via NANOG Sent: Wednesday, April 3, 2019 11:20 AM To: nanog at nanog.org Subject: Purchasing IPv4 space - due diligence homework All, Side stepping a migration to IPv6 debate.... I'd like to hear advise from the group about performing due diligence research on an IPv4 block before purchasing it on the secondary market (on behalf of an end-user company). My research has branched into two questions: a) What 'checks' should I perform?, and b) what results from those checks should cause us to walk away? My current list is: 1. Check BGP looking glass for route. It should not show up in the Internet routing table. If it does, walk away. 2. Check the ARIN registry. The longer history without recent transfers or changes is better. I don't know what explicit results should cause me to walk away here. 3. Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. Anything else? Advise? Thanks, Matt ________________________________ HowardCenter.org [http://howardcenter.org/assets/design/Facebook.jpg] [http://howardcenter.org/assets/design/Twitter.jpg] [http://howardcenter.org/assets/design/LinkedIn.jpg] CONFIDENTIALITY NOTICE: This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is patient protected health information, privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. Please notify the sender by reply e-mail and delete the original message immediately, or notify Howard Center, Inc. immediately by forwarded e-mail to our Privacy Officer, DaveK at howardcenter.org. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfawcett at corp.mtco.com Wed Apr 3 16:21:49 2019 From: nfawcett at corp.mtco.com (Fawcett, Nick) Date: Wed, 3 Apr 2019 16:21:49 +0000 Subject: DirecTV Streaming Message-ID: Does anyone know what IP to Geo database provider DirectTV uses for their streaming platform? Nick -- Checked by SOPHOS http://www.sophos.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Apr 3 21:47:53 2019 From: bill at herrin.us (William Herrin) Date: Wed, 3 Apr 2019 14:47:53 -0700 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: On Wed, Apr 3, 2019 at 8:20 AM Torres, Matt via NANOG wrote: > due diligence research on an IPv4 block [...] what results from those checks should cause us to walk away? Hi Matt, I think it also depends on your intended use. If you want a flawlessly clean block you can use for anything, you'll spend more time and money than if it just has to accommodate a particular use case. Run a mail server? Better be clean as a whistle. Geolocation only moderately important. Eyeball source? Past mail abuse may not be an issue but past DOS source could be and woe betide those who don't pay attention to where in the world Maxmind thinks the block is located. We, DNS or game servers? It almost doesn't matter. Unless past abuse was so bad that folks straight-up black holed it in the network, users will be able to connect to you. It's also worth considering whether you can move non-sensitive services from older known-clean addresses to the new blocks, freeing those older addresses for use in the more challenging application. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Wed Apr 3 23:02:10 2019 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 3 Apr 2019 19:02:10 -0400 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: Jeffrey, Thanks. A good start, but under-scoped. When you are purchasing IP number blocks whatever source you use; a marketplace, a broker, a single source should provide you with a compelling history on a number block REPUTATION that includes all the attributes listed below and then some. Some of the blocks I’ve seen being discussed lately appear notorious. In one case I counted 17 difffernt RBL’s being attributed to it. Checking Spamhaus is good, but then there are many others and some not so well known. There are many embedded in devices (remember auto config) that will never be updated. For most, do not buy v4 numbers blocks without a pro and you’ll sorta know when they talk about everything but price. Price matters, but if its unusable or you need to spend a month cleaning it up, no income = more cost. Best, -M< On Wed, Apr 3, 2019 at 15:38 Jeffrey Hathaway via NANOG wrote: > Hi, > > > > While I think #3 is important, it depends on your use of the end-block, > and those entries can sometimes be cleaned up with some work. If the block > is listed, that would certainly lower my buying price I am willing to pay > for the block. I did buy a block once in the ARIN region which showed up > in IP geolocation databases as Russian (no idea why), but it took me quite > a while to get it fixed. > > > > > > *Sincerely,* > > *Jeffrey Hathaway* > > Information Technology • Howard Center Inc. > > > > > > *From:* NANOG *On Behalf Of *Torres, Matt via > NANOG > *Sent:* Wednesday, April 3, 2019 11:20 AM > *To:* nanog at nanog.org > *Subject:* Purchasing IPv4 space - due diligence homework > > > > All, > > Side stepping a migration to IPv6 debate…. I’d like to hear advise from > the group about performing due diligence research on an IPv4 block before > purchasing it on the secondary market (on behalf of an end-user company). > My research has branched into two questions: a) What ‘checks’ should I > perform?, and b) what results from those checks should cause us to walk > away? > > > > My current list is: > > 1. Check BGP looking glass for route. It should not show up in the > Internet routing table. If it does, walk away. > 2. Check the ARIN registry. The longer history without recent > transfers or changes is better. I don’t know what explicit results should > cause me to walk away here. > 3. Check SORBS blacklisting. It should not show up except maybe the > DUHL list(?). If it does, walk away. > > > > Anything else? Advise? > > Thanks, > > Matt > > > ------------------------------ > > *HowardCenter.org* > > > > CONFIDENTIALITY NOTICE: This e-mail is intended only for the use of the > individual or entity to which it is addressed and may contain information > that is patient protected health information, privileged, confidential and > exempt from disclosure under applicable law. If you have received this > communication in error, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. > Please notify the sender by reply e-mail and delete the original message > immediately, or notify Howard Center, Inc. immediately by forwarded e-mail > to our Privacy Officer, DaveK at howardcenter.org. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Apr 3 23:14:06 2019 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 3 Apr 2019 18:14:06 -0500 (CDT) Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> Message-ID: <1661253369.1058.1554333244544.JavaMail.mhammett@ThunderFuck> Do you have sources for the ~90% T-Mobile IPv6? Not arguing, but to use that as a source myself when spreading the IPv6 good word. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" To: "Matt Torres" Cc: nanog at nanog.org Sent: Wednesday, April 3, 2019 10:58:23 AM Subject: Re: Purchasing IPv4 space - due diligence homework > On Apr 3, 2019, at 11:20 AM, Torres, Matt via NANOG wrote: > > All, > Side stepping a migration to IPv6 debate…. I’d like to hear advise from the group about performing due diligence research on an IPv4 block before purchasing it on the secondary market (on behalf of an end-user company). My research has branched into two questions: a) What ‘checks’ should I perform?, and b) what results from those checks should cause us to walk away? > > My current list is: > • Check BGP looking glass for route. It should not show up in the Internet routing table. If it does, walk away. > • Check the ARIN registry. The longer history without recent transfers or changes is better. I don’t know what explicit results should cause me to walk away here. > • Check SORBS blacklisting. It should not show up except maybe the DUHL list(?). If it does, walk away. > > Anything else? Advise? I’d like to ask a related question (I’m not questioning why you need IPv4 space) but are you also deploying IPv6 as well? If not, is there a reason? In my copious spare time I’m doing a small FTTH network and many services do work well with IPv6 while others (banks are a an example) perhaps don’t. We have T-Mobile USA saying with their network most bits go out as v6, so I’m guessing there’s that 5-10% you need v4 for if you deploy as aggressively as they do. Mostly curious if you are doing IPv6 if you see that slowing your need for v4 or if they are growing at the same rate. - Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdavids at forfun.net Thu Apr 4 07:28:14 2019 From: mdavids at forfun.net (Marco Davids) Date: Thu, 4 Apr 2019 09:28:14 +0200 Subject: Purchasing IPv4 space - due diligence homework In-Reply-To: <1661253369.1058.1554333244544.JavaMail.mhammett@ThunderFuck> References: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BD836@ExchMBXProd02.win.lottery.state.or.us> <1661253369.1058.1554333244544.JavaMail.mhammett@ThunderFuck> Message-ID: Op 04-04-19 om 01:14 schreef Mike Hammett: > Do you have sources for the ~90% T-Mobile IPv6? Not arguing, but to use > that as a source myself when spreading the IPv6 good word. > https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png https://stats.labs.apnic.net/ipv6/US (a bit slow, but informative) -- Marco From jwbensley at gmail.com Thu Apr 4 08:40:41 2019 From: jwbensley at gmail.com (James Bensley) Date: Thu, 4 Apr 2019 09:40:41 +0100 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: On Tue, 2 Apr 2019 at 17:57, Tom Ammon wrote: > > How do people model and try to project residential subscriber bandwidth demands into the future? Do you base it primarily on historical data? Are there more sophisticated approaches that you use to figure out how much backbone bandwidth you need to build to keep your eyeballs happy? > > Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? > > Tom Hi Tom, Historical data is definitely the way to predict a trend, you can’t call something a trend if it only started today IMO, something (e.g. bandwidth profiling) needs to have been recorded for a while before you can say that you are trying to predict the trend. Without historical data you're just making predications without any direction, which I don't think you want J Assuming you have a good mixture of subs, i.e. adults, children, male, female, different regions etc. and 100% of your subs aren't a single demographic like university campuses for example; then I don't think you need to worry about specifics like the adoption of QUIC or BBR. You will never see a permeant AND massive increase in your total aggregate network utilisation from one day to the next. If for example, a large CDN makes a change that increases per-user bandwidth requirements, it's unlikely they are going to deploy it globally in one single big-bang change. This would also be just one of your major bandwidth sources/destinations, of which you'll likely have several big-hitters that make up the bulk of your traffic. If you have planned well so far, and have plenty of spare capacity (as others have mentioned, in the 50-70% range and your backhaul/peering/transit links are of a reasonable size ratio to your subs, e.g. subs get 10-20Mbps services and your links are 1Gbps) there should be no persisting risk to your network capacity as long as you keep following the same upgrade trajectory. Major social events like the Super Bowl where you are (or here in England, sunshine) will cause exceptional traffic increases, but only for brief periods. You haven't mentioned exactly what you're doing for modelling capacity demand (assuming that you wanted feedback on it)? Assuming all the above is true for you, to give us a reasonable foundation to build on; In my experience the standard method is to record your ingress traffic rate at all your PEs or P&T nodes, and essentially divide this by the number of subs you have (egress is important too, it's just usually negligible in comparison). For example, if your ASN has a total average ingress traffic rate of 1Gbps at during peak hours and, you have 10,000 subs, you can model on say 0.1Mbps per sub. That’s actually a crazily low figure these days but, it’s just a fictional example to demonstrate the calculation. The ideal scenario is that you have this info for as long as you can. Also, the more subs you have the better it all averages out. For business ISPs, bringing on 1 new customer can make a major difference, if it’s a 100Gbps end-site site and your backbone is a single 100Gbps link you could be in trouble. For residential services, subs almost always have slower links than your backbone/P&T/PE nodes. If you have different types of subs it’s also worth breaking down the stats by sub type. For example; we have ADSL subs and VDSL subs. We record the egress traffic rate on the BNGs towards each type of sub separately and then aggregate across all BNGs. For example, today peak inbound for our ASN was X, of that X, Y went to ADSL subs and Z when to VDSL subs. Y / $number_of_adsl_subs == peak average for an ADSL line and, Z / $number_of_vdsl_subs == peak average for a VDSL line. It’s good to know this difference because a sub migrating from ADSL to VDSL is not the same as getting a new sub in terms of additional traffic growth. We have a lot of users upgrading to VDSL which makes a difference at scale, e.g 10K upgrades is less additional traffic than 10k new subs. Rinse and repeat for you other customer types (FTTP/H, wireless etc.) > On Tue, Apr 2, 2019 at 2:20 PM Josh Luthman wrote: >> >> We have GB/mo figures for our customers for every month for the last ~10 years. Is there some simple figure you're looking for? I can tell you off hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500 GB/mo at similar rates per month. >> > > I'm mostly just wondering what others do for this kind of planning - trying to look outside of my own experience, so I don't miss something obvious. That growth in total transfer that you mention is interesting. You need to be careful with volumetric based usage figures. As links continuously increase in speed over the years, users can transfer the same amount of data in less bit-time. The problem with polling at any interval (be it 1 seconds or 15 minutes) is that you miss bursts in between the polls. Volumetric based accounting misses the link utilisation which is how congestion is identified. You must measure utilisation and divide that by $number_of_subs. Your links can be congested and if you only measure by data volume transferred, you’ll see month by month subs transferred the same amount of data overall but day by day, hour by hour, it took longer because a link somewhere is congested, and everyone is pissed off. So with faster end-user speeds, one may have shorter but high core link utilisation. > I always wonder what the value of trying to predict utilization is anyway, especially since bandwidth is so cheap. But I figure it can't hurt to ask a group of people where I am highly likely to find somebody smarter than I am :-) The main requirement in my opinion is upgrades. You need to know how long a link upgrade takes for your operational teams, or a device upgrade etc. If it takes 2 months to deliver a new backhaul link to a regional PoP, call it 3 months to allow for wayleaves, sick engineers, DC access failures, etc. Then make sure you trigger a backhaul upgrade when your growth model says you’re 3-4 months away from 70% utilisation (or whatever figure suites your operations and customers). Cheers, James. P.S. Sorry for the epistle. From brutal8z at verizon.net Wed Apr 3 22:32:56 2019 From: brutal8z at verizon.net (brutal8z) Date: Wed, 3 Apr 2019 18:32:56 -0400 Subject: GPS WNRO April 6th at GPS Midnight Message-ID: I've not seen any mention of this here, so it might be off-topic, if so, sorry in advance. If you use GPS for time synchronization, this might be important.The Juniper ACX500 series and the Cisco 819 both have an embedded GPS receivers, for example. At 23:59:42 UTC on 4/6/2019 (Midnight GPS time, which differs by 18 leap-seconds  from UTC) , the 10-bit GPS Week Number broadcast by the constellation will reset to zero for the second time since the beginning of GPS on 1/6/1980. Ken -- GPS Week Number Rollover (WNRO) -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Thu Apr 4 12:16:24 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 4 Apr 2019 05:16:24 -0700 Subject: GPS WNRO April 6th at GPS Midnight In-Reply-To: References: Message-ID: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> On 4/3/19 3:32 PM, brutal8z via NANOG wrote: > I've not seen any mention of this here, so it might be off-topic, if so, > sorry in advance. If you use GPS for time synchronization, this might be > important.The Juniper ACX500 series and the Cisco 819 both have an > embedded GPS receivers, for example. > > At 23:59:42 UTC on 4/6/2019 (Midnight GPS time, which differs by 18 > leap-seconds  from UTC) , the > 10-bit GPS Week Number broadcast by the constellation will reset to zero > for the second time since the beginning of GPS on 1/6/1980. There was a mention of this a couple of weeks ago, as a "heads-up". When it first appeared up here, I checked with the vendor of my GPS time appliances. The vendor told me that the testing they did of their product showed no issues with the roll-over for specific ranges of serial numbers. Mine is within one of the ranges. The proof of the pudding will be what happens at 5pm PDT on my birthday, April 6, and what ntpq reports on my edge server. From jdambrosia at gmail.com Thu Apr 4 12:43:04 2019 From: jdambrosia at gmail.com (John DAmbrosia) Date: Thu, 4 Apr 2019 08:43:04 -0400 Subject: modeling residential subscriber bandwidth demand In-Reply-To: References: Message-ID: <028b01d4eae3$f411f3c0$dc35db40$@gmail.com> All, I am chairing an effort in the IEEE 802.3 Ethernet Working Group to understand bandwidth demand and how it will impact future Ethernet needs. This is exactly the type of discussion i would like to get shared with this activity. I would appreciate follow-on conversations with anyone wishing to share their observations. Regards, John D'Ambrosia Chair, IEEE 802.3 New Ethernet Applications Ad hoc -----Original Message----- From: NANOG On Behalf Of James Bensley Sent: Thursday, April 4, 2019 4:41 AM To: Tom Ammon ; NANOG Subject: Re: modeling residential subscriber bandwidth demand On Tue, 2 Apr 2019 at 17:57, Tom Ammon wrote: > > How do people model and try to project residential subscriber bandwidth demands into the future? Do you base it primarily on historical data? Are there more sophisticated approaches that you use to figure out how much backbone bandwidth you need to build to keep your eyeballs happy? > > Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? > > Tom Hi Tom, Historical data is definitely the way to predict a trend, you can’t call something a trend if it only started today IMO, something (e.g. bandwidth profiling) needs to have been recorded for a while before you can say that you are trying to predict the trend. Without historical data you're just making predications without any direction, which I don't think you want J Assuming you have a good mixture of subs, i.e. adults, children, male, female, different regions etc. and 100% of your subs aren't a single demographic like university campuses for example; then I don't think you need to worry about specifics like the adoption of QUIC or BBR. You will never see a permeant AND massive increase in your total aggregate network utilisation from one day to the next. If for example, a large CDN makes a change that increases per-user bandwidth requirements, it's unlikely they are going to deploy it globally in one single big-bang change. This would also be just one of your major bandwidth sources/destinations, of which you'll likely have several big-hitters that make up the bulk of your traffic. If you have planned well so far, and have plenty of spare capacity (as others have mentioned, in the 50-70% range and your backhaul/peering/transit links are of a reasonable size ratio to your subs, e.g. subs get 10-20Mbps services and your links are 1Gbps) there should be no persisting risk to your network capacity as long as you keep following the same upgrade trajectory. Major social events like the Super Bowl where you are (or here in England, sunshine) will cause exceptional traffic increases, but only for brief periods. You haven't mentioned exactly what you're doing for modelling capacity demand (assuming that you wanted feedback on it)? Assuming all the above is true for you, to give us a reasonable foundation to build on; In my experience the standard method is to record your ingress traffic rate at all your PEs or P&T nodes, and essentially divide this by the number of subs you have (egress is important too, it's just usually negligible in comparison). For example, if your ASN has a total average ingress traffic rate of 1Gbps at during peak hours and, you have 10,000 subs, you can model on say 0.1Mbps per sub. That’s actually a crazily low figure these days but, it’s just a fictional example to demonstrate the calculation. The ideal scenario is that you have this info for as long as you can. Also, the more subs you have the better it all averages out. For business ISPs, bringing on 1 new customer can make a major difference, if it’s a 100Gbps end-site site and your backbone is a single 100Gbps link you could be in trouble. For residential services, subs almost always have slower links than your backbone/P&T/PE nodes. If you have different types of subs it’s also worth breaking down the stats by sub type. For example; we have ADSL subs and VDSL subs. We record the egress traffic rate on the BNGs towards each type of sub separately and then aggregate across all BNGs. For example, today peak inbound for our ASN was X, of that X, Y went to ADSL subs and Z when to VDSL subs. Y / $number_of_adsl_subs == peak average for an ADSL line and, Z / $number_of_vdsl_subs == peak average for a VDSL line. It’s good to know this difference because a sub migrating from ADSL to VDSL is not the same as getting a new sub in terms of additional traffic growth. We have a lot of users upgrading to VDSL which makes a difference at scale, e.g 10K upgrades is less additional traffic than 10k new subs. Rinse and repeat for you other customer types (FTTP/H, wireless etc.) > On Tue, Apr 2, 2019 at 2:20 PM Josh Luthman wrote: >> >> We have GB/mo figures for our customers for every month for the last ~10 years. Is there some simple figure you're looking for? I can tell you off hand that I remember we had accounts doing ~15 GB/mo and now we've got 1500 GB/mo at similar rates per month. >> > > I'm mostly just wondering what others do for this kind of planning - trying to look outside of my own experience, so I don't miss something obvious. That growth in total transfer that you mention is interesting. You need to be careful with volumetric based usage figures. As links continuously increase in speed over the years, users can transfer the same amount of data in less bit-time. The problem with polling at any interval (be it 1 seconds or 15 minutes) is that you miss bursts in between the polls. Volumetric based accounting misses the link utilisation which is how congestion is identified. You must measure utilisation and divide that by $number_of_subs. Your links can be congested and if you only measure by data volume transferred, you’ll see month by month subs transferred the same amount of data overall but day by day, hour by hour, it took longer because a link somewhere is congested, and everyone is pissed off. So with faster end-user speeds, one may have shorter but high core link utilisation. > I always wonder what the value of trying to predict utilization is > anyway, especially since bandwidth is so cheap. But I figure it can't > hurt to ask a group of people where I am highly likely to find > somebody smarter than I am :-) The main requirement in my opinion is upgrades. You need to know how long a link upgrade takes for your operational teams, or a device upgrade etc. If it takes 2 months to deliver a new backhaul link to a regional PoP, call it 3 months to allow for wayleaves, sick engineers, DC access failures, etc. Then make sure you trigger a backhaul upgrade when your growth model says you’re 3-4 months away from 70% utilisation (or whatever figure suites your operations and customers). Cheers, James. P.S. Sorry for the epistle. From phillipc at phmgmt.com Thu Apr 4 20:04:31 2019 From: phillipc at phmgmt.com (Phillip Carroll) Date: Thu, 4 Apr 2019 20:04:31 +0000 Subject: DNS Qtypes and class values are a social construct In-Reply-To: References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> Message-ID: <6bf215f2dbdd4b3c90e4c4a154203d98@phmgmt.com> #Alfie-is-triggered From: NANOG On Behalf Of Alfie Pates Sent: Monday, April 1, 2019 11:08 AM To: Mankamana Mishra (mankamis) via NANOG Subject: Re: DNS Qtypes and class values are a social construct I feel this comes off as poking fun at trans people, women, and earnest attempts to combat what are actual problems in our industry, more than it pokes fun at the industry itself which is what a good April Fool should do - this feels more like laughing at "outsiders" more than laughing at ourselves. I think this is pretty tone-deaf, in my opinion. ~a -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-isp at mail.com Thu Apr 4 20:09:15 2019 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Thu, 4 Apr 2019 22:09:15 +0200 Subject: SFP supplier in Europe? Message-ID: Hello NANOG, Could somebody recommend an SFP supplier in Europe with a warehouse in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use a supplier has and will keep stock locally. Jared From dhubbard at dino.hostasaurus.com Thu Apr 4 20:12:12 2019 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 4 Apr 2019 20:12:12 +0000 Subject: SFP supplier in Europe? In-Reply-To: References: Message-ID: <528B2A78-A360-4ACB-B3D5-6D92558939B3@dino.hostasaurus.com> Flexoptix may be an option; they're Germany. Even US shipping is typically two day. On 4/4/19, 4:10 PM, "NANOG on behalf of nanog-isp at mail.com" wrote: Hello NANOG, Could somebody recommend an SFP supplier in Europe with a warehouse in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use a supplier has and will keep stock locally. Jared From alfie at fdx.services Thu Apr 4 20:14:35 2019 From: alfie at fdx.services (Alfie Pates) Date: Thu, 04 Apr 2019 16:14:35 -0400 Subject: SFP supplier in Europe? In-Reply-To: References: Message-ID: Can't reccomend Flexoptix[1] enough. Great service, fast shipping, and you only need to maintain one stock of optics even if you use kit from different vendors. FS.com are the go-to for bulk purchases of pre-coded optics on a budget: a few more cot deaths than most, but they're cheap and in my experience work reliably enough. [1] https://www.flexoptix.net/en/ ~a From martijnschmidt at i3d.net Thu Apr 4 20:19:07 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Thu, 4 Apr 2019 20:19:07 +0000 Subject: SFP supplier in Europe? In-Reply-To: References: Message-ID: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> You'll want to have a talk with FlexOptix, they're based in Germany and you can live view the stock in their local warehouse on the website, without even logging in. They've got a great team too! On 4 April 2019 23:09:15 EEST, nanog-isp at mail.com wrote: Hello NANOG, Could somebody recommend an SFP supplier in Europe with a warehouse in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use a supplier has and will keep stock locally. Jared -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Thu Apr 4 20:38:07 2019 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Thu, 4 Apr 2019 13:38:07 -0700 Subject: SFP supplier in Europe? In-Reply-To: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> Message-ID: <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> May want to try fs.com. https://www.fs.com/company/about_us.html I use their optics and am quite happy with them. -Mike > On Apr 4, 2019, at 13:19, i3D.net - Martijn Schmidt wrote: > > You'll want to have a talk with FlexOptix, they're based in Germany and you can live view the stock in their local warehouse on the website, without even logging in. They've got a great team too! > >> On 4 April 2019 23:09:15 EEST, nanog-isp at mail.com wrote: >> Hello NANOG, >> >> Could somebody recommend an SFP supplier in Europe with a warehouse in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use a supplier has and will keep stock locally. >> >> Jared > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at jack.fr.eu.org Thu Apr 4 20:38:50 2019 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Thu, 4 Apr 2019 22:38:50 +0200 Subject: SFP supplier in Europe? In-Reply-To: References: Message-ID: <5CA66B5A.1000303@jack.fr.eu.org> I highly recommends https://www.alturnanetworks.com/ They sell solid optics, all are tested Quick shipping, competitive price I have never been even remotely disappointed with those guys On 04/04/2019 10:09 PM, nanog-isp at mail.com wrote: > Hello NANOG, > > Could somebody recommend an SFP supplier in Europe with a warehouse in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use a supplier has and will keep stock locally. > > Jared > From nanog-isp at mail.com Thu Apr 4 20:50:52 2019 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Thu, 4 Apr 2019 22:50:52 +0200 Subject: SFP supplier in Europe? In-Reply-To: <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> Message-ID: Thanks to everybody that recommended Fiberstore and Flexoptics. Unfortunately Fiberstore is what led me to ask about alternative suppliers. Fiberstore actually ships in their Bidi SFPs from Asia and lead times are one to two weeks. Flexoptics is actually worse with 4-6 weeks after ordering. Jared > Sent: Thursday, April 04, 2019 > From: fwessling at succinctsystems.com > To: nanog at nanog.org, mike.lyon at gmail.com, "i3D.net - Martijn Schmidt" > Cc: "nanog at nanog.org" , "nanog-isp at mail.com" > Subject: Re: SFP supplier in Europe? > > fs.com for sure > > On April 4, 2019 4:38:07 PM EDT, mike.lyon at gmail.com wrote: > >May want to try fs.com. > > > >https://www.fs.com/company/about_us.html > > > >I use their optics and am quite happy with them. > > > >-Mike > > > >> On Apr 4, 2019, at 13:19, i3D.net - Martijn Schmidt > > wrote: > >> > >> You'll want to have a talk with FlexOptix, they're based in Germany > >and you can live view the stock in their local warehouse on the > >website, without even logging in. They've got a great team too! > >> > >>> On 4 April 2019 23:09:15 EEST, nanog-isp at mail.com wrote: > >>> Hello NANOG, > >>> > >>> Could somebody recommend an SFP supplier in Europe with a warehouse > >in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and > >I'd prefer to use a supplier has and will keep stock locally. > >>> > >>> Jared > >> > >> -- > >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > Frederick Wessling (CIO) > Succinct Systems LLC > Cell: +1(561) 571-2799 > Office: +1(904) 758-9915 ext. 9925 > Fax: +1(904) 758-9987 > www.SuccinctSystems.com > From Matt.Torres at state.or.us Thu Apr 4 20:56:13 2019 From: Matt.Torres at state.or.us (Torres, Matt) Date: Thu, 4 Apr 2019 20:56:13 +0000 Subject: Purchasing IPv4 space - due diligence homework Message-ID: <4E275B0B9F6F5445ACE48FBBB2AC3B14CB1BFC63@ExchMBXProd02.win.lottery.state.or.us> Thanks NANOG. For those interested, here is a summary list of due diligence tasks for purchasing IPv4 on the secondary market: 1. Check out the seller (Google search). What is their story? Generally avoid hosting companies because they may have more block/black list cleanup to do. 2. Check the BGP looking glass Internet routing table. Make sure the IPv4 address is not routed right now. 3. Check the historical Internet routing table. It is a good sign if the IPv4 network was advertised from the right company/ASN without recent changes https://stat.ripe.net/widget/routing-history# 4. Check ARIN registration. Singular, long standing registration for the IPv4 space is a good sign. 5. Check block list / black list. SORBS and Spamhaus are good resources. It is a good sign if the IPv4 network does not show up at all. http://www.anti-abuse.org/multi-rbl-check/ 6. Check geo-location. It is a good sign if the IPv4 space shows up in the right global region. Try MaxMind. 7. There is a PowerShell script (that can be expanded on) to help expedite the checking process. https://www.saotn.org/powershell-blacklist-check-script/#more-2459 Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfie at fdx.services Thu Apr 4 21:09:45 2019 From: alfie at fdx.services (Alfie Pates) Date: Thu, 04 Apr 2019 17:09:45 -0400 Subject: SFP supplier in Europe? In-Reply-To: References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> Message-ID: <2b33edae-6784-48b3-a0aa-d0701d6f7e72@www.fastmail.com> That's weird, I've never had to wait for a Flexoptix order: Are you ordering pre-coded or are you coding them yourselves. Actually, I don't remember having to wait very long the last time I ordered a bunch of fs.com optics. ~a From aled.w.morris at googlemail.com Thu Apr 4 21:11:50 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Thu, 4 Apr 2019 22:11:50 +0100 Subject: SFP supplier in Europe? In-Reply-To: References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> Message-ID: On Thu, 4 Apr 2019 at 21:52, wrote: > Thanks to everybody that recommended Fiberstore and Flexoptics. > > Unfortunately Fiberstore is what led me to ask about alternative > suppliers. Fiberstore actually ships in their Bidi SFPs from Asia and lead > times are one to two weeks. Flexoptics is actually worse with 4-6 weeks > after ordering. > That's not been my experience with either of them. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-isp at mail.com Thu Apr 4 21:17:02 2019 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Thu, 4 Apr 2019 23:17:02 +0200 Subject: SFP supplier in Europe? In-Reply-To: References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> Message-ID: I'm just quoting what they state on their web pages. Not all models are in stock at their EU warehouses. Jared Sent: Friday, April 05, 2019 From: "Aled Morris" To: nanog-isp at mail.com Cc: fwessling at succinctsystems.com, NANOG Subject: Re: SFP supplier in Europe? On Thu, 4 Apr 2019 at 21:52, wrote: Thanks to everybody that recommended Fiberstore and Flexoptics. Unfortunately Fiberstore is what led me to ask about alternative suppliers. Fiberstore actually ships in their Bidi SFPs from Asia and lead times are one to two weeks. Flexoptics is actually worse with 4-6 weeks after ordering.   That's not been my experience with either of them.     Aled From bjorn at mork.no Fri Apr 5 11:37:12 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 05 Apr 2019 13:37:12 +0200 Subject: SFP supplier in Europe? In-Reply-To: (nanog-isp's message of "Thu, 4 Apr 2019 22:50:52 +0200") References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> Message-ID: <87lg0ok7iv.fsf@miraculix.mork.no> nanog-isp at mail.com writes: > Unfortunately Fiberstore is what led me to ask about alternative > suppliers. Fiberstore actually ships in their Bidi SFPs from Asia Odd. They have lots of different BiDi SFFs "in Stock, EU Warehouse" according to https://www.fs.com/de-en/c/bidi-sfp-89 > and lead times are one to two weeks. My experience is that they ship a lot faster than that from Asia too, but I guess I've just been lucky. Bjørn From nanog-isp at mail.com Fri Apr 5 11:53:56 2019 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Fri, 5 Apr 2019 13:53:56 +0200 Subject: SFP supplier in Europe? In-Reply-To: <87lg0ok7iv.fsf@miraculix.mork.no> References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> <87lg0ok7iv.fsf@miraculix.mork.no> Message-ID: Only short haul is in stock. Jared > Sent: Friday, April 05, 2019 > From: "Bjørn Mork" > To: nanog-isp at mail.com > Cc: fwessling at succinctsystems.com, nanog at nanog.org > Subject: Re: SFP supplier in Europe? > > nanog-isp at mail.com writes: > > > Unfortunately Fiberstore is what led me to ask about alternative > > suppliers. Fiberstore actually ships in their Bidi SFPs from Asia > > > Odd. They have lots of different BiDi SFFs "in Stock, EU Warehouse" > according to https://www.fs.com/de-en/c/bidi-sfp-89 > > > and lead times are one to two weeks. > > My experience is that they ship a lot faster than that from Asia too, > but I guess I've just been lucky. > > > Bjørn > From me at cynthia.re Thu Apr 4 18:18:23 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=c3=b6m?=) Date: Thu, 4 Apr 2019 20:18:23 +0200 Subject: DNS Qtypes and class values are a social construct In-Reply-To: <6bf215f2dbdd4b3c90e4c4a154203d98@phmgmt.com> References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> <6bf215f2dbdd4b3c90e4c4a154203d98@phmgmt.com> Message-ID: <1739974e-4345-67d8-d2ff-73e723e6f016@cynthia.re> Hello Phillip, I feel like I have to say this, saying stuff like that "#triggered" is insensitive and as Alfie said, pretty tone deaf. You are pretty much proving Alfie's point by being like that. (I am transgender, so I do feel quite strongly about this) - Cynthia On 2019-04-04 22:04, Phillip Carroll wrote: > > #Alfie-is-triggered > > *From:* NANOG *On Behalf Of *Alfie Pates > *Sent:* Monday, April 1, 2019 11:08 AM > *To:* Mankamana Mishra (mankamis) via NANOG > *Subject:* Re: DNS Qtypes and class values are a social construct > > I feel this comes off as poking fun at trans people, women, and > earnest attempts to combat what are actual problems in our industry, > more than it pokes fun at the industry itself which is what a good > April Fool should do - this feels more like laughing at "outsiders" > more than laughing at ourselves. > > I think this is pretty tone-deaf, in my opinion. > > ~a > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at nanocat.net Thu Apr 4 20:31:06 2019 From: nick at nanocat.net (Nick Morrison) Date: Thu, 4 Apr 2019 22:31:06 +0200 Subject: DNS Qtypes and class values are a social construct In-Reply-To: References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> Message-ID: On Mon, 1 Apr 2019 at 18:09, Alfie Pates wrote: > I feel this comes off as poking fun at trans people, women, and earnest > attempts to combat what are actual problems in our industry, more than it > pokes fun at the industry itself which is what a good April Fool should do > - this feels more like laughing at "outsiders" more than laughing at > ourselves. > > I think this is pretty tone-deaf, in my opinion. > Completely agree, Alfie. (And hi, nanog, I'm Nick. Do we do introduction rounds here?) Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From fwessling at succinctsystems.com Thu Apr 4 20:41:42 2019 From: fwessling at succinctsystems.com (fwessling at succinctsystems.com) Date: Thu, 04 Apr 2019 16:41:42 -0400 Subject: SFP supplier in Europe? In-Reply-To: <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> <8B55A74E-F7C2-439E-8B4E-78831105AB70@gmail.com> Message-ID: <5F672350-64FE-418A-B7A4-99000BF0065C@succinctsystems.com> fs.com for sure On April 4, 2019 4:38:07 PM EDT, mike.lyon at gmail.com wrote: >May want to try fs.com. > >https://www.fs.com/company/about_us.html > >I use their optics and am quite happy with them. > >-Mike > >> On Apr 4, 2019, at 13:19, i3D.net - Martijn Schmidt > wrote: >> >> You'll want to have a talk with FlexOptix, they're based in Germany >and you can live view the stock in their local warehouse on the >website, without even logging in. They've got a great team too! >> >>> On 4 April 2019 23:09:15 EEST, nanog-isp at mail.com wrote: >>> Hello NANOG, >>> >>> Could somebody recommend an SFP supplier in Europe with a warehouse >in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and >I'd prefer to use a supplier has and will keep stock locally. >>> >>> Jared >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. Frederick Wessling (CIO) Succinct Systems LLC Cell: +1(561) 571-2799 Office: +1(904) 758-9915 ext. 9925 Fax: +1(904) 758-9987 www.SuccinctSystems.com From daniel.melzer at de-cix.net Thu Apr 4 20:51:31 2019 From: daniel.melzer at de-cix.net (Daniel Melzer) Date: Thu, 4 Apr 2019 20:51:31 +0000 Subject: SFP supplier in Europe? In-Reply-To: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> Message-ID: > Am 04.04.2019 um 22:19 schrieb i3D.net - Martijn Schmidt : > > You'll want to have a talk with FlexOptix, they're based in Germany and you can live view the stock in their local warehouse on the website, without even logging in. They've got a great team too! +1 Best regards, Daniel -- Daniel Melzer Chief Network Architect ------------------------- DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt am Main (Germany) mobile +49-173-3683197 e-mail daniel.melzer at de-cix.net web www.de-cix.net ------------------------- DE-CIX Management GmbH Executive Directors: Harald A. Summa and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP URL: From morrowc.lists at gmail.com Fri Apr 5 15:02:56 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Apr 2019 11:02:56 -0400 Subject: AS4134/AS4847 - Appear to be hijacking some ip space. Message-ID: Howdy gentle folks: It looks like AS4847 - "China Networks Inter-Exchange" Is taking some time to announce reachability for at least: 136.38.33.0/24 which they ought not, given that this /24 is part of a /11 assigned to AS16591 (google fiber)... Looking at routeviews data, I see the following as-paths for this one /24: $ grep -A1 Refresh /tmp/x | grep 4847 1239 174 4134 4847 3549 3356 174 4134 4847 701 174 4134 4847 4901 6079 3257 4134 4847 20912 174 4134 4847 1221 4637 4134 4847 1351 11164 4134 4847 6079 1299 4134 4847 6079 3257 4134 4847 7018 4134 4847 6939 1299 4134 4847 3561 209 4134 4847 3303 4134 4847 3277 39710 9002 4134 4847 2497 4134 4847 4826 1299 4134 4847 54728 20130 23352 2914 4134 4847 19214 3257 4134 4847 101 101 11164 4134 4847 1403 6453 4134 4847 852 6453 4134 4847 1403 6453 4134 4847 286 4134 4847 3333 1273 4134 4847 57866 3491 4134 4847 3267 1299 4134 4847 49788 174 4134 4847 53767 3257 4134 4847 53364 3257 4134 4847 8283 57866 3491 4134 4847 7660 2516 4134 4847 >From that I think the following AS should have filtered this prefix and are not: $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk '{print $NF}' | sort -n | uniq 174 - Cogent 209 - Qwest 286 - KPN 1273 - Vodafone 1299 - Telia 2497 - IIJ 2516 - KDDI 2914 - NTT 3257 - GTT 3303 - Swisscom 3491 - PCCW 4637 - Telstra 6453 - TATA 7018 - ATT 9002 - RETN 11164 - Internet2 It'd be great if the listed folk could filter AS4134 :) -Chris From nanog at radu-adrian.feurdean.net Fri Apr 5 15:58:27 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 05 Apr 2019 11:58:27 -0400 Subject: SFP supplier in Europe? In-Reply-To: <5CA66B5A.1000303@jack.fr.eu.org> References: <5CA66B5A.1000303@jack.fr.eu.org> Message-ID: <839ba8b4-bad0-478e-a933-7f9315400968@www.fastmail.com> On Thu, Apr 4, 2019, at 22:42, nanog at jack.fr.eu.org wrote: > I highly recommends https://www.alturnanetworks.com/ > > They sell solid optics, all are tested > Quick shipping, competitive price > > I have never been even remotely disappointed with those guys +1 They ship from the Netherlands, and delivery for France is 1-2 days (because we usually send them orders after 17h00 CET/CEST). From me at shawnritchie.com Fri Apr 5 16:03:59 2019 From: me at shawnritchie.com (Shawn Ritchie) Date: Fri, 5 Apr 2019 11:03:59 -0500 Subject: DNS Qtypes and class values are a social construct In-Reply-To: References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> Message-ID: Nick Morrison wrote on 4/4/2019 3:31 PM: > On Mon, 1 Apr 2019 at 18:09, Alfie Pates wrote: > > > I think this is pretty tone-deaf, in my opinion. > > > Completely agree, Alfie. > > (And hi, nanog, I'm Nick. Do we do introduction rounds here?) > > Nick I'll third this. And to note that that use of "triggered" is a good way to figure out that a person should just be ignored overall. Childish and lacking in empathy. "Ha ha, you CARE about something!" Christ. Grow up. -- Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayb at att.com Fri Apr 5 16:23:35 2019 From: jayb at att.com (Jay Borkenhagen) Date: Fri, 5 Apr 2019 12:23:35 -0400 Subject: AS4134/AS4847 - Appear to be hijacking some ip space. In-Reply-To: References: Message-ID: <23719.33031.457826.949262@oz.mt.att.com> Hi Chris, It would be great if the Google Fiber / AS16591 folks could publish a ROA in ARIN's hosted RPKI authorizing exactly 136.32.0.0/11 to be originated only in AS16591. That ROA would have addressed this matter from AS7018's point of view. In the interim, I have added a temporary whitelist (slurm) entry into our RPKI caches, causing the AS7018 network to disregard the more-specific /24s under 136.32.0.0/11. Good luck. Jay B. Christopher Morrow writes: > Howdy gentle folks: > > It looks like AS4847 - "China Networks Inter-Exchange" > > Is taking some time to announce reachability for at least: > 136.38.33.0/24 > > which they ought not, given that this /24 is part of a /11 assigned to > AS16591 (google fiber)... Looking at routeviews data, I see the > following as-paths for this one /24: > $ grep -A1 Refresh /tmp/x | grep 4847 > 1239 174 4134 4847 > 3549 3356 174 4134 4847 > 701 174 4134 4847 > 4901 6079 3257 4134 4847 > 20912 174 4134 4847 > 1221 4637 4134 4847 > 1351 11164 4134 4847 > 6079 1299 4134 4847 > 6079 3257 4134 4847 > 7018 4134 4847 > 6939 1299 4134 4847 > 3561 209 4134 4847 > 3303 4134 4847 > 3277 39710 9002 4134 4847 > 2497 4134 4847 > 4826 1299 4134 4847 > 54728 20130 23352 2914 4134 4847 > 19214 3257 4134 4847 > 101 101 11164 4134 4847 > 1403 6453 4134 4847 > 852 6453 4134 4847 > 1403 6453 4134 4847 > 286 4134 4847 > 3333 1273 4134 4847 > 57866 3491 4134 4847 > 3267 1299 4134 4847 > 49788 174 4134 4847 > 53767 3257 4134 4847 > 53364 3257 4134 4847 > 8283 57866 3491 4134 4847 > 7660 2516 4134 4847 > > >From that I think the following AS should have filtered this prefix and are not: > $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk > '{print $NF}' | sort -n | uniq > > 174 - Cogent > 209 - Qwest > 286 - KPN > 1273 - Vodafone > 1299 - Telia > 2497 - IIJ > 2516 - KDDI > 2914 - NTT > 3257 - GTT > 3303 - Swisscom > 3491 - PCCW > 4637 - Telstra > 6453 - TATA > 7018 - ATT > 9002 - RETN > 11164 - Internet2 > > It'd be great if the listed folk could filter AS4134 :) > > -Chris From cscora at apnic.net Fri Apr 5 18:03:22 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Apr 2019 04:03:22 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190405180322.46BCDC55B5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Apr, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 743761 Prefixes after maximum aggregation (per Origin AS): 285554 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 358387 Total ASes present in the Internet Routing Table: 63839 Prefixes per ASN: 11.65 Origin-only ASes present in the Internet Routing Table: 54939 Origin ASes announcing only one prefix: 23724 Transit ASes present in the Internet Routing Table: 8900 Transit-only ASes present in the Internet Routing Table: 274 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 28 Number of instances of unregistered ASNs: 35 Number of 32-bit ASNs allocated by the RIRs: 26474 Number of 32-bit ASNs visible in the Routing Table: 21592 Prefixes from 32-bit ASNs in the Routing Table: 94741 Number of bogon 32-bit ASNs visible in the Routing Table: 29 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 251 Number of addresses announced to Internet: 2844502144 Equivalent to 169 /8s, 139 /16s and 168 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 249042 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200892 Total APNIC prefixes after maximum aggregation: 57957 APNIC Deaggregation factor: 3.47 Prefixes being announced from the APNIC address blocks: 197778 Unique aggregates announced from the APNIC address blocks: 82200 APNIC Region origin ASes present in the Internet Routing Table: 9644 APNIC Prefixes per ASN: 20.51 APNIC Region origin ASes announcing only one prefix: 2700 APNIC Region transit ASes present in the Internet Routing Table: 1432 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4630 Number of APNIC addresses announced to Internet: 769411456 Equivalent to 45 /8s, 220 /16s and 73 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 219668 Total ARIN prefixes after maximum aggregation: 103931 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 218709 Unique aggregates announced from the ARIN address blocks: 105006 ARIN Region origin ASes present in the Internet Routing Table: 18426 ARIN Prefixes per ASN: 11.87 ARIN Region origin ASes announcing only one prefix: 6859 ARIN Region transit ASes present in the Internet Routing Table: 1889 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2645 Number of ARIN addresses announced to Internet: 1079698560 Equivalent to 64 /8s, 90 /16s and 228 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 205325 Total RIPE prefixes after maximum aggregation: 97761 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 201667 Unique aggregates announced from the RIPE address blocks: 119689 RIPE Region origin ASes present in the Internet Routing Table: 25968 RIPE Prefixes per ASN: 7.77 RIPE Region origin ASes announcing only one prefix: 11541 RIPE Region transit ASes present in the Internet Routing Table: 3692 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7985 Number of RIPE addresses announced to Internet: 718206336 Equivalent to 42 /8s, 206 /16s and 245 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 96613 Total LACNIC prefixes after maximum aggregation: 21614 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 97958 Unique aggregates announced from the LACNIC address blocks: 42031 LACNIC Region origin ASes present in the Internet Routing Table: 8247 LACNIC Prefixes per ASN: 11.88 LACNIC Region origin ASes announcing only one prefix: 2188 LACNIC Region transit ASes present in the Internet Routing Table: 1528 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5794 Number of LACNIC addresses announced to Internet: 172779008 Equivalent to 10 /8s, 76 /16s and 102 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 21234 Total AfriNIC prefixes after maximum aggregation: 4269 AfriNIC Deaggregation factor: 4.97 Prefixes being announced from the AfriNIC address blocks: 27398 Unique aggregates announced from the AfriNIC address blocks: 9229 AfriNIC Region origin ASes present in the Internet Routing Table: 1261 AfriNIC Prefixes per ASN: 21.73 AfriNIC Region origin ASes announcing only one prefix: 436 AfriNIC Region transit ASes present in the Internet Routing Table: 243 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 538 Number of AfriNIC addresses announced to Internet: 104150016 Equivalent to 6 /8s, 53 /16s and 52 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4728 546 549 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4706 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3131 1313 54 VIETEL-AS-AP Viettel Group, VN 45899 3038 1734 111 VNPT-AS-VN VNPT Corp, VN 9829 2748 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2613 11120 761 KIXS-AS-KR Korea Telecom, KR 9808 2435 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2180 4906 29 CTTNET China TieTong Telecommunications 4755 2149 429 186 TATACOMM-AS TATA Communications formerl 9498 2032 426 167 BBIL-AP BHARTI Airtel Ltd., 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 11492 3642 238 588 CABLEONE - CABLE ONE, INC., US 6327 3600 1325 94 SHAW - Shaw Communications Inc., CA 22773 3388 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2606 5902 1078 AMAZON-02 - Amazon.com, Inc., US 16625 2348 1294 1791 AKAMAI-AS - Akamai Technologies, Inc., 30036 2152 355 130 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2751 532 CHARTER-20115 - Charter Communications, 18566 2109 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2056 5103 577 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5430 1628 139 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3254 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2644 539 1919 AKAMAI-ASN1, US 12389 2225 2221 636 ROSTELECOM-AS, RU 34984 2081 342 535 TELLCOM-AS, TR 9121 1683 1693 19 TTNET, TR 13188 1605 100 47 TRIOLAN, UA 9009 1409 147 767 M247, GB 8402 1259 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5663 3338 592 Uninet S.A. de C.V., MX 10620 3476 537 375 Telmex Colombia S.A., CO 11830 2706 384 34 Instituto Costarricense de Electricidad 7303 1454 992 247 Telecom Argentina S.A., AR 6503 1354 433 53 Axtel, S.A.B. de C.V., MX 28573 1348 2249 187 CLARO S.A., BR 6147 1259 374 25 Telefonica del Peru S.A.A., PE 3816 1023 505 113 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 962 524 248 Mega Cable, S.A. de C.V., MX 11172 955 144 63 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1204 393 21 LINKdotNET-AS, EG 37611 892 107 9 Afrihost, ZA 24835 883 646 21 RAYA-AS, EG 36903 827 416 126 MT-MPLS, MA 36992 816 1531 71 ETISALAT-MISR, EG 8452 706 1731 19 TE-AS TE-AS, EG 29571 495 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 420 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5663 3338 592 Uninet S.A. de C.V., MX 12479 5430 1628 139 UNI2-AS, ES 7545 4728 546 549 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4706 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3642 238 588 CABLEONE - CABLE ONE, INC., US 6327 3600 1325 94 SHAW - Shaw Communications Inc., CA 10620 3476 537 375 Telmex Colombia S.A., CO 22773 3388 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3254 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5430 5291 UNI2-AS, ES 4538 4706 4632 ERX-CERNET-BKB China Education and Research Net 7545 4728 4179 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3600 3506 SHAW - Shaw Communications Inc., CA 22773 3388 3227 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3254 3209 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 10620 3476 3101 Telmex Colombia S.A., CO 7552 3131 3077 VIETEL-AS-AP Viettel Group, VN 11492 3642 3054 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 66087 UNALLOCATED 103.136.231.0/24 138903 KHILGAON-AS-AP KHILGAON DOT NE 651315 UNALLOCATED 103.137.6.0/24 17806 MANGOTELESERVICE-AS-BD Tire-1 651315 UNALLOCATED 103.137.7.0/24 17806 MANGOTELESERVICE-AS-BD Tire-1 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 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 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 43.255.80.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:36 /11:100 /12:291 /13:567 /14:1136 /15:1909 /16:13351 /17:7968 /18:13896 /19:25599 /20:39974 /21:46167 /22:93269 /23:75655 /24:422757 /25:1064 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4343 5430 UNI2-AS, ES 6327 3374 3600 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2848 3642 CABLEONE - CABLE ONE, INC., US 8551 2707 3254 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2627 3388 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2051 2706 Instituto Costarricense de Electricidad y Telec 18566 2004 2109 MEGAPATH5-US - MegaPath Corporation, US 30036 1899 2152 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1754 2086 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1601 2:952 4:22 5:3025 6:45 7:1 8:1286 9:1 11:3 12:1806 13:324 14:1991 15:36 16:4 17:241 18:58 20:49 23:2657 24:2516 25:2 27:2496 31:1977 32:97 35:36 36:841 37:3048 38:1715 39:294 40:119 41:3280 42:768 43:2026 44:149 45:7147 46:3248 47:257 49:1356 50:1104 51:322 52:1016 54:285 55:2 56:9 57:42 58:1786 59:1080 60:506 61:2125 62:2124 63:1813 64:4961 65:2214 66:4843 67:2715 68:1168 69:3529 70:1329 71:599 72:2448 74:2764 75:514 76:548 77:1731 78:1766 79:2321 80:1811 81:1507 82:1134 83:907 84:1116 85:2303 86:528 87:1552 88:1053 89:2605 90:220 91:6555 92:1366 93:2437 94:2551 95:3228 96:927 97:343 98:948 99:210 100:87 101:1153 102:516 103:20878 104:3521 105:252 106:811 107:1779 108:692 109:3731 110:1649 111:1905 112:1487 113:1395 114:1139 115:1722 116:1720 117:1900 118:2186 119:1644 120:1025 121:1043 122:2341 123:1644 124:1472 125:1978 128:1265 129:822 130:531 131:1652 132:742 133:219 134:1052 135:242 136:573 137:718 138:2058 139:850 140:580 141:858 142:793 143:1068 144:859 145:494 146:1263 147:835 148:1723 149:821 150:783 151:1012 152:1053 153:323 154:2778 155:903 156:1619 157:952 158:640 159:1929 160:1529 161:919 162:2714 163:798 164:1188 165:1564 166:445 167:1392 168:3292 169:868 170:4142 171:574 172:1136 173:2204 174:1038 175:910 176:2354 177:4221 178:2528 179:1460 180:2181 181:2404 182:2665 183:1073 184:1207 185:14941 186:3664 187:2479 188:2893 189:1967 190:8316 191:1570 192:10052 193:6662 194:5413 195:4100 196:3089 197:1772 198:5839 199:5987 200:7214 201:5127 202:10407 203:10113 204:4544 205:3022 206:3220 207:3248 208:3967 209:4242 210:3936 211:2001 212:3158 213:2929 214:1093 215:54 216:5940 217:2235 218:880 219:580 220:1860 221:968 222:987 223:1363 End of report From morrowc.lists at gmail.com Fri Apr 5 18:16:36 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Apr 2019 14:16:36 -0400 Subject: AS4134/AS4847 - Appear to be hijacking some ip space. In-Reply-To: <23719.33031.457826.949262@oz.mt.att.com> References: <23719.33031.457826.949262@oz.mt.att.com> Message-ID: On Fri, Apr 5, 2019 at 12:29 PM Jay Borkenhagen wrote: > > Hi Chris, yes! > It would be great if the Google Fiber / AS16591 folks could publish a > ROA in ARIN's hosted RPKI authorizing exactly 136.32.0.0/11 to be > originated only in AS16591. That ROA would have addressed this matter > from AS7018's point of view. > ok, cool. This is sort of on my plate, at least from the internal viz/evangelizing perspective, and I'll go spend time chatting up the folk in fiber-land. having a: "See, doing this would prevent this" is helpful. > In the interim, I have added a temporary whitelist (slurm) entry into > our RPKI caches, causing the AS7018 network to disregard the > more-specific /24s under 136.32.0.0/11. thanks! > Good luck. > Jay B. > > > Christopher Morrow writes: > > Howdy gentle folks: > > > > It looks like AS4847 - "China Networks Inter-Exchange" > > > > Is taking some time to announce reachability for at least: > > 136.38.33.0/24 > > > > which they ought not, given that this /24 is part of a /11 assigned to > > AS16591 (google fiber)... Looking at routeviews data, I see the > > following as-paths for this one /24: > > $ grep -A1 Refresh /tmp/x | grep 4847 > > 1239 174 4134 4847 > > 3549 3356 174 4134 4847 > > 701 174 4134 4847 > > 4901 6079 3257 4134 4847 > > 20912 174 4134 4847 > > 1221 4637 4134 4847 > > 1351 11164 4134 4847 > > 6079 1299 4134 4847 > > 6079 3257 4134 4847 > > 7018 4134 4847 > > 6939 1299 4134 4847 > > 3561 209 4134 4847 > > 3303 4134 4847 > > 3277 39710 9002 4134 4847 > > 2497 4134 4847 > > 4826 1299 4134 4847 > > 54728 20130 23352 2914 4134 4847 > > 19214 3257 4134 4847 > > 101 101 11164 4134 4847 > > 1403 6453 4134 4847 > > 852 6453 4134 4847 > > 1403 6453 4134 4847 > > 286 4134 4847 > > 3333 1273 4134 4847 > > 57866 3491 4134 4847 > > 3267 1299 4134 4847 > > 49788 174 4134 4847 > > 53767 3257 4134 4847 > > 53364 3257 4134 4847 > > 8283 57866 3491 4134 4847 > > 7660 2516 4134 4847 > > > > >From that I think the following AS should have filtered this prefix and are not: > > $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk > > '{print $NF}' | sort -n | uniq > > > > 174 - Cogent > > 209 - Qwest > > 286 - KPN > > 1273 - Vodafone > > 1299 - Telia > > 2497 - IIJ > > 2516 - KDDI > > 2914 - NTT > > 3257 - GTT > > 3303 - Swisscom > > 3491 - PCCW > > 4637 - Telstra > > 6453 - TATA > > 7018 - ATT > > 9002 - RETN > > 11164 - Internet2 > > > > It'd be great if the listed folk could filter AS4134 :) > > > > -Chris From louiel at google.com Fri Apr 5 18:44:31 2019 From: louiel at google.com (Louie Lee) Date: Fri, 5 Apr 2019 11:44:31 -0700 Subject: AS4134/AS4847 - Appear to be hijacking some ip space. In-Reply-To: References: <23719.33031.457826.949262@oz.mt.att.com> Message-ID: Hey folks, I'm on it for solving both immediate issue and long term "fix". Louie -- Louie Lee, 李景雲 Peering Coordinator (AS16591 ) Network Capacity Manager IP Numbers Administrator Google Fiber louiel at google.com (650) 253-2847 *There are 10 types of people in the world: Those who understand binary, and those who don't.* On Fri, Apr 5, 2019 at 11:17 AM Christopher Morrow wrote: > On Fri, Apr 5, 2019 at 12:29 PM Jay Borkenhagen wrote: > > > > Hi Chris, > > yes! > > > It would be great if the Google Fiber / AS16591 folks could publish a > > ROA in ARIN's hosted RPKI authorizing exactly 136.32.0.0/11 to be > > originated only in AS16591. That ROA would have addressed this matter > > from AS7018's point of view. > > > > ok, cool. This is sort of on my plate, at least from the internal > viz/evangelizing perspective, and I'll go spend time chatting up the > folk in fiber-land. > having a: "See, doing this would prevent this" is helpful. > > > In the interim, I have added a temporary whitelist (slurm) entry into > > our RPKI caches, causing the AS7018 network to disregard the > > more-specific /24s under 136.32.0.0/11. > > thanks! > > > Good luck. > > Jay B. > > > > > > Christopher Morrow writes: > > > Howdy gentle folks: > > > > > > It looks like AS4847 - "China Networks Inter-Exchange" > > > > > > Is taking some time to announce reachability for at least: > > > 136.38.33.0/24 > > > > > > which they ought not, given that this /24 is part of a /11 assigned to > > > AS16591 (google fiber)... Looking at routeviews data, I see the > > > following as-paths for this one /24: > > > $ grep -A1 Refresh /tmp/x | grep 4847 > > > 1239 174 4134 4847 > > > 3549 3356 174 4134 4847 > > > 701 174 4134 4847 > > > 4901 6079 3257 4134 4847 > > > 20912 174 4134 4847 > > > 1221 4637 4134 4847 > > > 1351 11164 4134 4847 > > > 6079 1299 4134 4847 > > > 6079 3257 4134 4847 > > > 7018 4134 4847 > > > 6939 1299 4134 4847 > > > 3561 209 4134 4847 > > > 3303 4134 4847 > > > 3277 39710 9002 4134 4847 > > > 2497 4134 4847 > > > 4826 1299 4134 4847 > > > 54728 20130 23352 2914 4134 4847 > > > 19214 3257 4134 4847 > > > 101 101 11164 4134 4847 > > > 1403 6453 4134 4847 > > > 852 6453 4134 4847 > > > 1403 6453 4134 4847 > > > 286 4134 4847 > > > 3333 1273 4134 4847 > > > 57866 3491 4134 4847 > > > 3267 1299 4134 4847 > > > 49788 174 4134 4847 > > > 53767 3257 4134 4847 > > > 53364 3257 4134 4847 > > > 8283 57866 3491 4134 4847 > > > 7660 2516 4134 4847 > > > > > > >From that I think the following AS should have filtered this prefix > and are not: > > > $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk > > > '{print $NF}' | sort -n | uniq > > > > > > 174 - Cogent > > > 209 - Qwest > > > 286 - KPN > > > 1273 - Vodafone > > > 1299 - Telia > > > 2497 - IIJ > > > 2516 - KDDI > > > 2914 - NTT > > > 3257 - GTT > > > 3303 - Swisscom > > > 3491 - PCCW > > > 4637 - Telstra > > > 6453 - TATA > > > 7018 - ATT > > > 9002 - RETN > > > 11164 - Internet2 > > > > > > It'd be great if the listed folk could filter AS4134 :) > > > > > > -Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmorizot at gmail.com Fri Apr 5 20:01:33 2019 From: tmorizot at gmail.com (Scott Morizot) Date: Fri, 5 Apr 2019 15:01:33 -0500 Subject: DNS Qtypes and class values are a social construct In-Reply-To: <1739974e-4345-67d8-d2ff-73e723e6f016@cynthia.re> References: <71b739ef-98e4-64b3-5e33-50a64d8d9395@easydns.com> <6bf215f2dbdd4b3c90e4c4a154203d98@phmgmt.com> <1739974e-4345-67d8-d2ff-73e723e6f016@cynthia.re> Message-ID: On Fri, Apr 5, 2019 at 8:34 AM Cynthia Revström wrote: Hello Phillip, I feel like I have to say this, saying stuff like that "#triggered" is insensitive and as Alfie said, pretty tone deaf. Some of us live with and are working to better manage PTSD from complex trauma. I agree with Cynthia and can assure you "triggered" is not a joke or laughing matter for us. I also agree with Alfie and Cynthia regarding the original content. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncariaga at gmail.com Fri Apr 5 20:50:01 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Sat, 6 Apr 2019 04:50:01 +0800 Subject: Centurylink-MSN issue in Dallas area? Message-ID: Dear Nanog, Anyone here having problems with Centurylink and MSN? I hope Centurylink - MSN engineers here who can reach back to me off the list? I'm noticing high latency between the 2 in Dallas area (>180ms). Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From manager at monmouth.com Fri Apr 5 21:07:03 2019 From: manager at monmouth.com (Mark Stevens) Date: Fri, 5 Apr 2019 17:07:03 -0400 Subject: Microsoft Message-ID: <1ffb6ec9-1ba3-ac74-09b8-80eb7b3c57b3@monmouth.com> Good afternoon, If a network engineer from Microsoft could contact me offline it would be great. Reason: Attacks to my an IP on my network udp port 20480 from Microsoft IPs in the USA and the UK. Thanks Mark From ashley.kitto at nominum.com Sat Apr 6 00:27:10 2019 From: ashley.kitto at nominum.com (Ashley Kitto) Date: Fri, 5 Apr 2019 17:27:10 -0700 Subject: SFP supplier in Europe? In-Reply-To: References: <5EE0D88F-B5E3-4987-85F5-55965E1CB8D6@i3d.net> Message-ID: <5DB1A22F-7013-402F-80C8-71C166CA9B60@nominum.com> Same, they’ve been great for me, even when I dropped in on them unexpectedly when I needed an optic in Frankfurt.. Ashley > On Apr 4, 2019, at 1:51 PM, Daniel Melzer wrote: > > > >> Am 04.04.2019 um 22:19 schrieb i3D.net - Martijn Schmidt : >> >> You'll want to have a talk with FlexOptix, they're based in Germany and you can live view the stock in their local warehouse on the website, without even logging in. They've got a great team too! > > +1 > > > Best regards, > Daniel > > -- > Daniel Melzer > Chief Network Architect > ------------------------- > DE-CIX Management GmbH > Lindleystr. 12, 60314 Frankfurt am Main (Germany) > mobile +49-173-3683197 > e-mail daniel.melzer at de-cix.net > web www.de-cix.net > ------------------------- > DE-CIX Management GmbH > Executive Directors: Harald A. Summa and Sebastian Seifert > Trade registry: District court (Amtsgericht) Cologne, HRB 51135 > Registered office: Lichtstr. 43i, 50825 Cologne > From eric at eparsonage.com Fri Apr 5 23:47:44 2019 From: eric at eparsonage.com (Eric Parsonage) Date: Sat, 6 Apr 2019 10:17:44 +1030 Subject: GPS rollover In-Reply-To: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> References: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> Message-ID: <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> I personally fell foul of this last night. My CPAP machine switched itself off. It has an internal cellular modem which it uses to exchange usage data but since I never have to set the date and time I assume it gets this from my cellular network. Its hardly a graceful fail when the air supply turns itself off. From marka at isc.org Sat Apr 6 00:38:53 2019 From: marka at isc.org (Mark Andrews) Date: Sat, 6 Apr 2019 11:38:53 +1100 Subject: GPS rollover In-Reply-To: <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> References: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> Message-ID: Sounds like something that should be reported to the FDA. -- Mark Andrews > On 6 Apr 2019, at 10:47, Eric Parsonage wrote: > > > I personally fell foul of this last night. My CPAP machine switched itself off. It has an internal cellular modem which it uses to exchange usage data but since I never have to set the date and time I assume it gets this from my cellular network. Its hardly a graceful fail when the air supply turns itself off. > > > > > > From pf at tippete.net Sat Apr 6 06:39:38 2019 From: pf at tippete.net (Pierfrancesco Caci) Date: Sat, 06 Apr 2019 08:39:38 +0200 Subject: AS4134/AS4847 - Appear to be hijacking some ip space. In-Reply-To: (Christopher Morrow's message of "Fri, 5 Apr 2019 11:02:56 -0400") References: Message-ID: <87mul3k579.fsf@snoopy.tippete.net> Looks like they stopped already, I'm not seeing this on 3491 nor on routeviews anymore. Pf >>>>> "Christopher" == Christopher Morrow writes: Christopher> Howdy gentle folks: Christopher> It looks like AS4847 - "China Networks Inter-Exchange" Christopher> Is taking some time to announce reachability for at least: Christopher> 136.38.33.0/24 Christopher> which they ought not, given that this /24 is part of a /11 assigned to Christopher> AS16591 (google fiber)... Looking at routeviews data, I see the Christopher> following as-paths for this one /24: Christopher> $ grep -A1 Refresh /tmp/x | grep 4847 Christopher> 1239 174 4134 4847 Christopher> 3549 3356 174 4134 4847 Christopher> 701 174 4134 4847 Christopher> 4901 6079 3257 4134 4847 Christopher> 20912 174 4134 4847 Christopher> 1221 4637 4134 4847 Christopher> 1351 11164 4134 4847 Christopher> 6079 1299 4134 4847 Christopher> 6079 3257 4134 4847 Christopher> 7018 4134 4847 Christopher> 6939 1299 4134 4847 Christopher> 3561 209 4134 4847 Christopher> 3303 4134 4847 Christopher> 3277 39710 9002 4134 4847 Christopher> 2497 4134 4847 Christopher> 4826 1299 4134 4847 Christopher> 54728 20130 23352 2914 4134 4847 Christopher> 19214 3257 4134 4847 Christopher> 101 101 11164 4134 4847 Christopher> 1403 6453 4134 4847 Christopher> 852 6453 4134 4847 Christopher> 1403 6453 4134 4847 Christopher> 286 4134 4847 Christopher> 3333 1273 4134 4847 Christopher> 57866 3491 4134 4847 Christopher> 3267 1299 4134 4847 Christopher> 49788 174 4134 4847 Christopher> 53767 3257 4134 4847 Christopher> 53364 3257 4134 4847 Christopher> 8283 57866 3491 4134 4847 Christopher> 7660 2516 4134 4847 Christopher> From that I think the following AS should have filtered this prefix and are not: Christopher> $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk Christopher> '{print $NF}' | sort -n | uniq Christopher> 174 - Cogent Christopher> 209 - Qwest Christopher> 286 - KPN Christopher> 1273 - Vodafone Christopher> 1299 - Telia Christopher> 2497 - IIJ Christopher> 2516 - KDDI Christopher> 2914 - NTT Christopher> 3257 - GTT Christopher> 3303 - Swisscom Christopher> 3491 - PCCW Christopher> 4637 - Telstra Christopher> 6453 - TATA Christopher> 7018 - ATT Christopher> 9002 - RETN Christopher> 11164 - Internet2 Christopher> It'd be great if the listed folk could filter AS4134 :) Christopher> -Chris -- Pierfrancesco Caci, ik5pvx From jared at puck.nether.net Sat Apr 6 11:28:37 2019 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 6 Apr 2019 07:28:37 -0400 Subject: GPS rollover In-Reply-To: <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> References: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> Message-ID: <130D5950-54FD-4101-A57C-F025B1C82262@puck.nether.net> I keep mine in airplane mode and use SleepyHead to read the SD card. (I see it was shut down by the developer, but it should still work for you). - jared > On Apr 5, 2019, at 7:47 PM, Eric Parsonage wrote: > > > I personally fell foul of this last night. My CPAP machine switched itself off. It has an internal cellular modem which it uses to exchange usage data but since I never have to set the date and time I assume it gets this from my cellular network. Its hardly a graceful fail when the air supply turns itself off. > > > > > From lists at packetflux.com Sat Apr 6 12:17:55 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Sat, 6 Apr 2019 06:17:55 -0600 Subject: GPS rollover In-Reply-To: <130D5950-54FD-4101-A57C-F025B1C82262@puck.nether.net> References: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> <130D5950-54FD-4101-A57C-F025B1C82262@puck.nether.net> Message-ID: Still being maintained. .. https://www.apneaboard.com/sleepyhead/ On Sat, Apr 6, 2019, 5:30 AM Jared Mauch wrote: > I keep mine in airplane mode and use SleepyHead to read the SD card. (I > see it was shut down by the developer, but it should still work for you). > > - jared > > > On Apr 5, 2019, at 7:47 PM, Eric Parsonage wrote: > > > > > > I personally fell foul of this last night. My CPAP machine switched > itself off. It has an internal cellular modem which it uses to exchange > usage data but since I never have to set the date and time I assume it gets > this from my cellular network. Its hardly a graceful fail when the air > supply turns itself off. > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at packetflux.com Sat Apr 6 12:36:26 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Sat, 6 Apr 2019 06:36:26 -0600 Subject: GPS rollover In-Reply-To: References: <5d13e2c6-7bd6-6b5d-2231-ae3d00d524dd@satchell.net> <71FE6328-BA38-4D3C-ADF7-F52CC9E932BD@eparsonage.com> <130D5950-54FD-4101-A57C-F025B1C82262@puck.nether.net> Message-ID: oops, I guess I was wrong, missed the drama somehow. Ignore my previous comment. On Sat, Apr 6, 2019, 6:17 AM Forrest Christian (List Account) < lists at packetflux.com> wrote: > Still being maintained. .. https://www.apneaboard.com/sleepyhead/ > > On Sat, Apr 6, 2019, 5:30 AM Jared Mauch wrote: > >> I keep mine in airplane mode and use SleepyHead to read the SD card. (I >> see it was shut down by the developer, but it should still work for you). >> >> - jared >> >> > On Apr 5, 2019, at 7:47 PM, Eric Parsonage wrote: >> > >> > >> > I personally fell foul of this last night. My CPAP machine switched >> itself off. It has an internal cellular modem which it uses to exchange >> usage data but since I never have to set the date and time I assume it gets >> this from my cellular network. Its hardly a graceful fail when the air >> supply turns itself off. >> > >> > >> > >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Sat Apr 6 17:29:07 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 6 Apr 2019 13:29:07 -0400 Subject: AS4134/AS4847 - Appear to be hijacking some ip space. In-Reply-To: <87mul3k579.fsf@snoopy.tippete.net> References: <87mul3k579.fsf@snoopy.tippete.net> Message-ID: On Sat, Apr 6, 2019 at 2:40 AM Pierfrancesco Caci wrote: > > > Looks like they stopped already, I'm not seeing this on 3491 nor on > routeviews anymore. > About ~10 or so hours back Louie's request to CT got some action, yes. Thanks! -chris From john at essenz.com Sun Apr 7 21:41:22 2019 From: john at essenz.com (John Von Essen) Date: Sun, 7 Apr 2019 17:41:22 -0400 Subject: Amazon AS16509 peering... how long to wait? Message-ID: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> I applied for peering, received an email, setup the BGP session, waited about a month. Then 3 weeks ago my BGP session with Amazom came up, but with zero routes. I assume I am in some kind of test/waiting period, but after three weeks, I thought I would be getting routes by now. Emails to the peeringdb POC have not returned anything. Anyone here from AS16509, can this be bumped? We are AS17185, and peering is on DE-CIX NYC. Thanks John From mehmet at akcin.net Sun Apr 7 22:13:42 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 7 Apr 2019 16:13:42 -0600 Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> Message-ID: I will connect you to right people offlist I am surprised its taking that long On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: > I applied for peering, received an email, setup the BGP session, waited > about a month. Then 3 weeks ago my BGP session with Amazom came up, but > with zero routes. I assume I am in some kind of test/waiting period, but > after three weeks, I thought I would be getting routes by now. Emails to > the peeringdb POC have not returned anything. Anyone here from AS16509, > can this be bumped? We are AS17185, and peering is on DE-CIX NYC. > > > Thanks > > John > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sun Apr 7 22:35:49 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 7 Apr 2019 18:35:49 -0400 Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> Message-ID: >From what I've heard, their peering department is really behind on processing new peer turn-ups. On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: > I will connect you to right people offlist > > I am surprised its taking that long > > On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: > >> I applied for peering, received an email, setup the BGP session, waited >> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >> with zero routes. I assume I am in some kind of test/waiting period, but >> after three weeks, I thought I would be getting routes by now. Emails to >> the peeringdb POC have not returned anything. Anyone here from AS16509, >> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >> >> >> Thanks >> >> John >> >> -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Mon Apr 8 02:35:47 2019 From: aveline at misaka.io (Siyuan Miao) Date: Mon, 8 Apr 2019 10:35:47 +0800 Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> Message-ID: Same here. We've received configuration details in Mar 12 and we've completed the configuration on the same day. Then we didn't hear any news from them. On Mon, Apr 8, 2019 at 6:37 AM Ross Tajvar wrote: > From what I've heard, their peering department is really behind on > processing new peer turn-ups. > > On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: > >> I will connect you to right people offlist >> >> I am surprised its taking that long >> >> On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: >> >>> I applied for peering, received an email, setup the BGP session, waited >>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >>> with zero routes. I assume I am in some kind of test/waiting period, but >>> after three weeks, I thought I would be getting routes by now. Emails to >>> the peeringdb POC have not returned anything. Anyone here from AS16509, >>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >>> >>> >>> Thanks >>> >>> John >>> >>> -- >> Mehmet >> +1-424-298-1903 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daffy at daffy.za.net Mon Apr 8 00:40:07 2019 From: daffy at daffy.za.net (Kieran Murphy) Date: Mon, 8 Apr 2019 10:40:07 +1000 Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> Message-ID: Yeah, it takes a while. My peering request turned 1 year old on Friday. There was cake. On Mon, 8 Apr 2019 at 08:36, Ross Tajvar wrote: > From what I've heard, their peering department is really behind on > processing new peer turn-ups. > > On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: > >> I will connect you to right people offlist >> >> I am surprised its taking that long >> >> On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: >> >>> I applied for peering, received an email, setup the BGP session, waited >>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >>> with zero routes. I assume I am in some kind of test/waiting period, but >>> after three weeks, I thought I would be getting routes by now. Emails to >>> the peeringdb POC have not returned anything. Anyone here from AS16509, >>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >>> >>> >>> Thanks >>> >>> John >>> >>> -- >> Mehmet >> +1-424-298-1903 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bblackford at gmail.com Mon Apr 8 04:01:26 2019 From: bblackford at gmail.com (Bill Blackford) Date: Sun, 7 Apr 2019 21:01:26 -0700 Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> Message-ID: <7CA9348B-0A17-4CFF-9302-E13C31F647CB@gmail.com> 😳🤣 Sent from my iPhone > On Apr 7, 2019, at 17:40, Kieran Murphy wrote: > > Yeah, it takes a while. > > My peering request turned 1 year old on Friday. > There was cake. > >> On Mon, 8 Apr 2019 at 08:36, Ross Tajvar wrote: >> From what I've heard, their peering department is really behind on processing new peer turn-ups. >> >>> On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: >>> I will connect you to right people offlist >>> >>> I am surprised its taking that long >>> >>>> On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: >>>> I applied for peering, received an email, setup the BGP session, waited >>>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >>>> with zero routes. I assume I am in some kind of test/waiting period, but >>>> after three weeks, I thought I would be getting routes by now. Emails to >>>> the peeringdb POC have not returned anything. Anyone here from AS16509, >>>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >>>> >>>> >>>> Thanks >>>> >>>> John >>>> >>> -- >>> Mehmet >>> +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Mon Apr 8 13:02:26 2019 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 8 Apr 2019 08:02:26 -0500 (CDT) Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> Message-ID: <997293972.776.1554728544374.JavaMail.mhammett@ThunderFuck> I submitted requests for multiple networks over the course of a year. One got acknowledged and had a few week wait from when the session came up to routes\traffic passing. The others have been ignored. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "John Von Essen" To: nanog at nanog.org Sent: Sunday, April 7, 2019 4:41:22 PM Subject: Amazon AS16509 peering... how long to wait? I applied for peering, received an email, setup the BGP session, waited about a month. Then 3 weeks ago my BGP session with Amazom came up, but with zero routes. I assume I am in some kind of test/waiting period, but after three weeks, I thought I would be getting routes by now. Emails to the peeringdb POC have not returned anything. Anyone here from AS16509, can this be bumped? We are AS17185, and peering is on DE-CIX NYC. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mansaxel at besserwisser.org Mon Apr 8 13:49:26 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 8 Apr 2019 15:49:26 +0200 Subject: SFP supplier in Europe? In-Reply-To: References: Message-ID: <20190408134925.GA26037@besserwisser.org> Subject: SFP supplier in Europe? Date: Thu, Apr 04, 2019 at 10:09:15PM +0200 Quoting nanog-isp at mail.com (nanog-isp at mail.com): > Hello NANOG, > > Could somebody recommend an SFP supplier in Europe with a warehouse in the EU and fast shipping? I need to pick up some 80km Bidi SFPs and I'd prefer to use a supplier has and will keep stock locally. With the caveats discussed in the thread taken into consideration, I'd pitch in that both FS and FlexOptix have proven useful to me. Flex got me a very specific coding (Siemens SDH gear compatible) in no time, and FS are -- for stocked items -- hard to beat on price and shipping time. Both being inside EU means zero hassle with customs which is important. (Poor Brits, what have they done to themselves?) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Are we on STRIKE yet? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dp at datasoftcomnet.com Mon Apr 8 13:55:50 2019 From: dp at datasoftcomnet.com (DurgaPrasad - DatasoftComnet) Date: Mon, 8 Apr 2019 19:25:50 +0530 Subject: NANOG Digest, Vol 135, Issue 8 [EXTERNAL MAIL] In-Reply-To: References: Message-ID: <004e01d4ee12$c6960710$53c21530$@datasoftcomnet.com> Same problem in India connecting at Extreme IX peering in Mumbai. The session is up since months. Receiving no prefixes yet - followed up many times. We are having ASN 133593 Regards DP -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of nanog-request at nanog.org Sent: 08 April 2019 17:30 To: nanog at nanog.org Subject: NANOG Digest, Vol 135, Issue 8 [EXTERNAL MAIL] Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Amazon AS16509 peering... how long to wait? (John Von Essen) 2. Re: Amazon AS16509 peering... how long to wait? (Mehmet Akcin) 3. Re: Amazon AS16509 peering... how long to wait? (Ross Tajvar) 4. Re: Amazon AS16509 peering... how long to wait? (Siyuan Miao) 5. Re: Amazon AS16509 peering... how long to wait? (Kieran Murphy) 6. Re: Amazon AS16509 peering... how long to wait? (Bill Blackford) ---------------------------------------------------------------------- Message: 1 Date: Sun, 7 Apr 2019 17:41:22 -0400 From: John Von Essen To: nanog at nanog.org Subject: Amazon AS16509 peering... how long to wait? Message-ID: <346afcfa-a2b3-883d-67b6-470ce1e2c96c at essenz.com> Content-Type: text/plain; charset=utf-8; format=flowed I applied for peering, received an email, setup the BGP session, waited about a month. Then 3 weeks ago my BGP session with Amazom came up, but with zero routes. I assume I am in some kind of test/waiting period, but after three weeks, I thought I would be getting routes by now. Emails to the peeringdb POC have not returned anything. Anyone here from AS16509, can this be bumped? We are AS17185, and peering is on DE-CIX NYC. Thanks John ------------------------------ Message: 2 Date: Sun, 7 Apr 2019 16:13:42 -0600 From: Mehmet Akcin To: John Von Essen Cc: nanog at nanog.org Subject: Re: Amazon AS16509 peering... how long to wait? Message-ID: Content-Type: text/plain; charset="utf-8" I will connect you to right people offlist I am surprised its taking that long On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: > I applied for peering, received an email, setup the BGP session, waited > about a month. Then 3 weeks ago my BGP session with Amazom came up, but > with zero routes. I assume I am in some kind of test/waiting period, but > after three weeks, I thought I would be getting routes by now. Emails to > the peeringdb POC have not returned anything. Anyone here from AS16509, > can this be bumped? We are AS17185, and peering is on DE-CIX NYC. > > > Thanks > > John > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Sun, 7 Apr 2019 18:35:49 -0400 From: Ross Tajvar To: Mehmet Akcin Cc: John Von Essen , "North American Network Operators' Group" Subject: Re: Amazon AS16509 peering... how long to wait? Message-ID: Content-Type: text/plain; charset="utf-8" >From what I've heard, their peering department is really behind on processing new peer turn-ups. On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: > I will connect you to right people offlist > > I am surprised its taking that long > > On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: > >> I applied for peering, received an email, setup the BGP session, waited >> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >> with zero routes. I assume I am in some kind of test/waiting period, but >> after three weeks, I thought I would be getting routes by now. Emails to >> the peeringdb POC have not returned anything. Anyone here from AS16509, >> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >> >> >> Thanks >> >> John >> >> -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Mon, 8 Apr 2019 10:35:47 +0800 From: Siyuan Miao To: Ross Tajvar Cc: Mehmet Akcin , "North American Network Operators' Group" Subject: Re: Amazon AS16509 peering... how long to wait? Message-ID: Content-Type: text/plain; charset="utf-8" Same here. We've received configuration details in Mar 12 and we've completed the configuration on the same day. Then we didn't hear any news from them. On Mon, Apr 8, 2019 at 6:37 AM Ross Tajvar wrote: > From what I've heard, their peering department is really behind on > processing new peer turn-ups. > > On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: > >> I will connect you to right people offlist >> >> I am surprised its taking that long >> >> On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: >> >>> I applied for peering, received an email, setup the BGP session, waited >>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >>> with zero routes. I assume I am in some kind of test/waiting period, but >>> after three weeks, I thought I would be getting routes by now. Emails to >>> the peeringdb POC have not returned anything. Anyone here from AS16509, >>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >>> >>> >>> Thanks >>> >>> John >>> >>> -- >> Mehmet >> +1-424-298-1903 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 8 Apr 2019 10:40:07 +1000 From: Kieran Murphy To: Ross Tajvar Cc: Mehmet Akcin , "North American Network Operators' Group" Subject: Re: Amazon AS16509 peering... how long to wait? Message-ID: Content-Type: text/plain; charset="utf-8" Yeah, it takes a while. My peering request turned 1 year old on Friday. There was cake. On Mon, 8 Apr 2019 at 08:36, Ross Tajvar wrote: > From what I've heard, their peering department is really behind on > processing new peer turn-ups. > > On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: > >> I will connect you to right people offlist >> >> I am surprised its taking that long >> >> On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: >> >>> I applied for peering, received an email, setup the BGP session, waited >>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >>> with zero routes. I assume I am in some kind of test/waiting period, but >>> after three weeks, I thought I would be getting routes by now. Emails to >>> the peeringdb POC have not returned anything. Anyone here from AS16509, >>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >>> >>> >>> Thanks >>> >>> John >>> >>> -- >> Mehmet >> +1-424-298-1903 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Sun, 7 Apr 2019 21:01:26 -0700 From: Bill Blackford To: Kieran Murphy Cc: Ross Tajvar , North American Network Operators' Group Subject: Re: Amazon AS16509 peering... how long to wait? Message-ID: <7CA9348B-0A17-4CFF-9302-E13C31F647CB at gmail.com> Content-Type: text/plain; charset="utf-8" 😳🤣 Sent from my iPhone > On Apr 7, 2019, at 17:40, Kieran Murphy wrote: > > Yeah, it takes a while. > > My peering request turned 1 year old on Friday. > There was cake. > >> On Mon, 8 Apr 2019 at 08:36, Ross Tajvar wrote: >> From what I've heard, their peering department is really behind on processing new peer turn-ups. >> >>> On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin wrote: >>> I will connect you to right people offlist >>> >>> I am surprised its taking that long >>> >>>> On Sun, Apr 7, 2019 at 16:41 John Von Essen wrote: >>>> I applied for peering, received an email, setup the BGP session, waited >>>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but >>>> with zero routes. I assume I am in some kind of test/waiting period, but >>>> after three weeks, I thought I would be getting routes by now. Emails to >>>> the peeringdb POC have not returned anything. Anyone here from AS16509, >>>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC. >>>> >>>> >>>> Thanks >>>> >>>> John >>>> >>> -- >>> Mehmet >>> +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: End of NANOG Digest, Vol 135, Issue 8 ************************************* --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From spoofer-info at caida.org Mon Apr 8 17:00:05 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Mon, 8 Apr 2019 10:00:05 -0700 Subject: Spoofer Report for NANOG for Mar 2019 Message-ID: <201904081700.x38H059H003751@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Mar 2019: ASN Name Fixed-By 2828 XO-AS15 2019-03-06 33523 ROWANUNIVERSITY 2019-03-25 5050 PSC-EXT 2019-03-26 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Mar 2019: ASN Name First-Spoofed Last-Spoofed 577 BACOM 2016-03-09 2019-03-22 7029 WINDSTREAM 2016-06-21 2019-03-29 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-03-26 6128 CABLE-NET-1 2016-09-03 2019-03-30 18530 ISOMEDIA-1 2016-09-27 2019-03-26 20412 CLARITY-TELECOM 2016-09-30 2019-03-29 6181 FUSE-NET 2016-10-10 2019-03-29 25787 ROWE-NETWORKS 2016-10-21 2019-03-28 174 COGENT-174 2016-10-21 2019-03-22 11537 ABILENE 2016-10-24 2019-03-04 31857 PRIORITY-TERABIT 2016-10-25 2019-03-29 30341 SCTA-ASN 2016-10-31 2019-03-25 32440 LONI 2016-11-03 2019-03-26 12083 WOW-INTERNET 2016-11-09 2019-03-31 1403 EBOX 2016-11-12 2019-03-08 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-03-26 3549 LVLT-3549 2016-11-16 2019-03-07 21832 KELLINCOM-1 2017-02-03 2019-03-31 18451 LESNET 2017-02-22 2019-03-07 53597 HOYOS-CONSULTING-LLC 2017-03-24 2019-03-09 23314 ORLANDOTELCO 2017-04-14 2019-03-09 19624 SERVERROOM 2017-06-02 2019-03-25 701 UUNET 2017-06-14 2019-03-09 6461 ZAYO-6461 2017-06-21 2019-03-06 63296 AMARILLO-WIRELESS 2017-09-01 2019-03-27 7233 YAHOO-US 2017-09-07 2019-03-05 33523 ROWANUNIVERSITY 2017-10-29 2019-03-25 546 PARSONS-PGS-1 2017-11-20 2019-03-25 12222 AKAMAI 2018-02-14 2019-03-26 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2019-03-07 4201 ORST 2018-04-19 2019-03-27 12028 MMINTERNET 2018-06-14 2019-03-26 225 VIRGINIA 2018-06-18 2019-03-26 40911 L2NC 2018-08-31 2019-03-29 33452 RW 2018-09-19 2019-03-26 20448 VPNTRANET-LLC 2018-09-20 2019-03-26 11215 LOGIXCOMM 2018-09-20 2019-03-11 11996 LOBOIS 2018-09-24 2019-03-26 13825 TROYCABLE-NET 2018-11-21 2019-03-26 32329 MONKEYBRAINS 2018-11-28 2019-03-22 4943 NOL 2019-03-04 2019-03-12 20278 NEXEON 2019-03-05 2019-03-05 395565 MIEMX 2019-03-08 2019-03-08 19531 NODESDIRECT 2019-03-14 2019-03-28 44685 ShatelNet 2019-03-23 2019-03-23 11297 LIPSCOMB 2019-03-29 2019-03-29 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From ESundberg at nitelusa.com Mon Apr 8 21:43:39 2019 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Mon, 8 Apr 2019 21:43:39 +0000 Subject: Amazon AS16509 peering... how long to wait? In-Reply-To: <997293972.776.1554728544374.JavaMail.mhammett@ThunderFuck> References: <346afcfa-a2b3-883d-67b6-470ce1e2c96c@essenz.com> <997293972.776.1554728544374.JavaMail.mhammett@ThunderFuck> Message-ID: Chase them down at the next Nanog… I had to do that for two large content providers. From: NANOG On Behalf Of Mike Hammett Sent: Monday, April 8, 2019 8:02 AM To: John Von Essen Cc: nanog at nanog.org Subject: Re: Amazon AS16509 peering... how long to wait? I submitted requests for multiple networks over the course of a year. One got acknowledged and had a few week wait from when the session came up to routes\traffic passing. The others have been ignored. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "John Von Essen" > To: nanog at nanog.org Sent: Sunday, April 7, 2019 4:41:22 PM Subject: Amazon AS16509 peering... how long to wait? I applied for peering, received an email, setup the BGP session, waited about a month. Then 3 weeks ago my BGP session with Amazom came up, but with zero routes. I assume I am in some kind of test/waiting period, but after three weeks, I thought I would be getting routes by now. Emails to the peeringdb POC have not returned anything. Anyone here from AS16509, can this be bumped? We are AS17185, and peering is on DE-CIX NYC. Thanks John ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Apr 9 01:20:39 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 8 Apr 2019 21:20:39 -0400 (EDT) Subject: IIJ demonstrating emergency information for broadband and smart TVs Message-ID: Internet Initiative Japan (IIJ) and T-NET Japan are demonstrating a hybrid integration of emergency alerts for broadcasting and broadband smart TVs at this week's National Association of Broadcasters convention. A consortium of Korean broadcasters and manufacturers is also demonstrating UHD. In addition to the gorgeous video, the Korean UHD consortium has a very nice emergency alert demostration. Korea and Japan seem to be the leaders. The U.S. smart assistant companies (Amazon and Google) have very large booths on the NAB show floor, but their products don't have emergency alerts. From benm at workonline.africa Tue Apr 9 11:51:42 2019 From: benm at workonline.africa (Ben Maddison) Date: Tue, 9 Apr 2019 11:51:42 +0000 Subject: RPKI Route Origin Validation - Africa Message-ID: Hello all. In November 2018 during the ZAPF (South African Peering Forum) meeting in Cape Town, 3 major African ISP's announced that they would enable RPKI-based ROV (Route Origin Validation), including dropping Invalid routes as part of efforts to improve Internet routing security, on the 1st April, 2019. On the 1st of April, Workonline Communications (AS37271) enabled ROV and began dropping Invalid routes. This applies to all eBGP sessions, both IPv4 and IPv6. On the 5th of April, SEACOM (AS37100) enabled ROV and began dropping Invalid routes. This applies to eBGP sessions with public peers, private peers and transit providers, both for IPv4 and IPv6. eBGP sessions toward downstream customers will follow in 3 months time. Implementation at the third ISP has yet to be completed. We are sure they will communicate with the community when they are ready to do so. Please note that for the legal reasons previously discussed in various fora, neither Workonline nor SEACOM are utilising the ARIN TAL. As a result, any routes covered only by a ROA issued under the ARIN TAL will fall back to a status of Not Found. Unfortunately, this means that ARIN members will not see any improved routing security for their prefixes on our networks until this is resolved. We will each re-evaluate this decision if and when ARIN's policy changes. We are hopeful that this will happen sooner rather than later. If you interconnect with either of us and believe that you are experiencing any routing issues potentially related to this new policy, please feel free to reach out to either: - noc at workonline.africa - peering at seacom.mu Workonline Communications and SEACOM hope that this move encourages the rest of the ISP community around the world to ramp up their deployment of RPKI ROV and begin dropping Invalid routes. We appreciate the work that AT&T and others have carried out in the same vein. In the mean time, we are happy to answer any questions you may have about our deployments. Thanks, Mark Tinka (SEACOM) & Ben Maddison (Workonline Communications). -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathana at fsr.com Wed Apr 10 02:05:17 2019 From: nathana at fsr.com (Nathan Anderson) Date: Wed, 10 Apr 2019 02:05:17 +0000 Subject: Facebook (account) Message-ID: Fellow NetOps, I realize this is an unorthodox / off-topic request, but I've been trying to help a friend out and don't know how to advise her next. If there is someone from FB here who has connections to someone in account security and is willing to contact me off-list, I'd really appreciate it. A friend had her FB account of many years hijacked and then held for ransom by a random dude. When she asked FB to intercede, she appeared to have her account back for a short time (< 24 hrs) before FB themselves blocked the account, and that's where we are now. It's been over 2 weeks and she has been going round and round with "CS" and getting nowhere...whoever these robots are keep repeating requests for her to send in ID, which she does, and then they repeat the request again and it just goes in a circle. I have a feeling that I know what's going on behind-the-scenes, but we can't seem to get a living, breathing human over there who isn't just reading a script to actually listen to her. Seriously, what is the average person supposed to do under these circumstances? If this was just the story of a lone FB account I'm not sure I would bother and I'd just tell her to get a new one. But she runs a business (popular local coffee shop) with a FB page that this account of hers was apparently the only admin for. Thanks in advance for any leads, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From jhellenthal at dataix.net Wed Apr 10 02:16:50 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Tue, 9 Apr 2019 21:16:50 -0500 Subject: Facebook (account) In-Reply-To: References: Message-ID: <27B45E04-BD9E-4DED-A8B6-79208C591965@dataix.net> Delete fB account ... -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Apr 9, 2019, at 21:05, Nathan Anderson wrote: > > Fellow NetOps, > > I realize this is an unorthodox / off-topic request, but I've been trying to help a friend out and don't know how to advise her next. > > If there is someone from FB here who has connections to someone in account security and is willing to contact me off-list, I'd really appreciate it. A friend had her FB account of many years hijacked and then held for ransom by a random dude. When she asked FB to intercede, she appeared to have her account back for a short time (< 24 hrs) before FB themselves blocked the account, and that's where we are now. It's been over 2 weeks and she has been going round and round with "CS" and getting nowhere...whoever these robots are keep repeating requests for her to send in ID, which she does, and then they repeat the request again and it just goes in a circle. I have a feeling that I know what's going on behind-the-scenes, but we can't seem to get a living, breathing human over there who isn't just reading a script to actually listen to her. Seriously, what is the average person supposed to do under these circumstances? > > If this was just the story of a lone FB account I'm not sure I would bother and I'd just tell her to get a new one. But she runs a business (popular local coffee shop) with a FB page that this account of hers was apparently the only admin for. > > Thanks in advance for any leads, > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available URL: From matt at netfire.net Wed Apr 10 04:00:20 2019 From: matt at netfire.net (Matt Harris) Date: Tue, 9 Apr 2019 23:00:20 -0500 Subject: Facebook (account) In-Reply-To: <27B45E04-BD9E-4DED-A8B6-79208C591965@dataix.net> References: <27B45E04-BD9E-4DED-A8B6-79208C591965@dataix.net> Message-ID: > > On Apr 9, 2019, at 21:05, Nathan Anderson wrote: > > a FB page that this account of hers was apparently the only admin for. > > > Redundancy: it's not just a concept to be applied to devices and wiring. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos at oasis-tech.net Tue Apr 9 18:01:03 2019 From: amos at oasis-tech.net (Amos Rosenboim) Date: Tue, 09 Apr 2019 18:01:03 +0000 Subject: Gi Firewall for mobile subscribers Message-ID: Hello NANOG, We are discussing internally and wanted to get more opinions and especially more data on what are people actually doing. We are running an ISP network with about 150K fixed broadband users, running dual stack (IPv4 behind CGNAT). On the ISP network IPv6 is simply routed, and is firewalled on the CPE. This network added mobile services about a year ago, also dual stack (we have no control on the mobile devices so we were too concerned to choose IPv6 only access). We have an ongoing discussion about Gi firewall (adding a firewall between the subscribers and the internet, allowing only subscriber initiated connections), for the IPv6 traffic. The firewall is doing very little security, the ruleset is very basic, allowing anything from subscribers to the internet and blocking all traffic from the internet towards the subscribers. We have a few rules to limit the number of connections per subscriber (to a relatively high number) and that is it. One of the arguments in favor of having the firewall is that unsolicited traffic from the internet can “wake” idle mobile devices, and create signaling (paging) storms as well as drain user batteries. On the other hand, allowing only subscriber initiated traffic is mostly achievable using ACLs on the mobile core facing routers, or is it with the growing percentage of UDP traffic ? BTW – I don’t mention IPv4 traffic on the mobile network as it’s all behind CGNAT which don’t allow internet initiated connections. Anyway, we are very interested to know hear more opinions, and especially to hear what are other mobile operators do. Regards Amos -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Wed Apr 10 13:48:10 2019 From: cb.list6 at gmail.com (Ca By) Date: Wed, 10 Apr 2019 06:48:10 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: Message-ID: On Wed, Apr 10, 2019 at 6:23 AM Amos Rosenboim wrote: > Hello NANOG, > > > > We are discussing internally and wanted to get more opinions and > especially more data on what are people actually doing. > > We are running an ISP network with about 150K fixed broadband users, > running dual stack (IPv4 behind CGNAT). > > On the ISP network IPv6 is simply routed, and is firewalled on the CPE. > > > > This network added mobile services about a year ago, also dual stack (we > have no control on the mobile devices so we were too concerned to choose > IPv6 only access). > > We have an ongoing discussion about Gi firewall (adding a firewall between > the subscribers and the internet, allowing only subscriber initiated > connections), for the IPv6 traffic. > > > > The firewall is doing very little security, the ruleset is very basic, > allowing anything from subscribers to the internet and blocking all traffic > from the internet towards the subscribers. > > We have a few rules to limit the number of connections per subscriber (to > a relatively high number) and that is it. > > > > One of the arguments in favor of having the firewall is that unsolicited > traffic from the internet can “wake” idle mobile devices, and create > signaling (paging) storms as well as drain user batteries. > > > > On the other hand, allowing only subscriber initiated traffic is mostly > achievable using ACLs on the mobile core facing routers, or is it with the > growing percentage of UDP traffic ? > > > > BTW – I don’t mention IPv4 traffic on the mobile network as it’s all > behind CGNAT which don’t allow internet initiated connections. > > > > Anyway, we are very interested to know hear more opinions, and especially > to hear what are other mobile operators do. > > > > Regards > > > > Amos > > > Step outside the theoretical and model your real threats. Attack yourself of pay someone to do a real pentest. 1. Does a hacker know the ipv6 of your subs? How frequently does the sub get a new 128 bit address? 2. What does the hacker get from a paging storm? Economic benefit ? Lolz? Has a malicious paging storm ever happened in the real world? What level of effort would be required to trigger that? Is that level of effort more or less than it would take to tip over a stateful firewall (session exhaustion, pps attack, alg bugs, vulns in the fw https://www.zdnet.com/article/cisco-removed-its-seventh-backdoor-account-this-year-and-thats-a-good-thing/ ) 3. Assuming the hacker gleans the address of the sub, what ports are open in the real world? What can a hacker connect to and accomplish? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Wed Apr 10 14:06:45 2019 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 10 Apr 2019 10:06:45 -0400 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: Message-ID: I think the traffic Amos is referring to is random traffic hitting the devices causing them to "wake up". Everyone here knows a simple dump on port 22 will show traffic. We have a /22 that gets an avg of 1-2 mbit of random traffic (mainly 22 and 3389). On Wed, Apr 10, 2019 at 9:49 AM Ca By wrote: > > > On Wed, Apr 10, 2019 at 6:23 AM Amos Rosenboim > wrote: > >> Hello NANOG, >> >> >> >> We are discussing internally and wanted to get more opinions and >> especially more data on what are people actually doing. >> >> We are running an ISP network with about 150K fixed broadband users, >> running dual stack (IPv4 behind CGNAT). >> >> On the ISP network IPv6 is simply routed, and is firewalled on the CPE. >> >> >> >> This network added mobile services about a year ago, also dual stack (we >> have no control on the mobile devices so we were too concerned to choose >> IPv6 only access). >> >> We have an ongoing discussion about Gi firewall (adding a firewall >> between the subscribers and the internet, allowing only subscriber >> initiated connections), for the IPv6 traffic. >> >> >> >> The firewall is doing very little security, the ruleset is very basic, >> allowing anything from subscribers to the internet and blocking all traffic >> from the internet towards the subscribers. >> >> We have a few rules to limit the number of connections per subscriber (to >> a relatively high number) and that is it. >> >> >> >> One of the arguments in favor of having the firewall is that unsolicited >> traffic from the internet can “wake” idle mobile devices, and create >> signaling (paging) storms as well as drain user batteries. >> >> >> >> On the other hand, allowing only subscriber initiated traffic is mostly >> achievable using ACLs on the mobile core facing routers, or is it with the >> growing percentage of UDP traffic ? >> >> >> >> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all >> behind CGNAT which don’t allow internet initiated connections. >> >> >> >> Anyway, we are very interested to know hear more opinions, and >> especially to hear what are other mobile operators do. >> >> >> >> Regards >> >> >> >> Amos >> >> >> > > Step outside the theoretical and model your real threats. Attack yourself > of pay someone to do a real pentest. > > 1. Does a hacker know the ipv6 of your subs? How frequently does the sub > get a new 128 bit address? > > 2. What does the hacker get from a paging storm? Economic benefit ? > Lolz? Has a malicious paging storm ever happened in the real world? What > level of effort would be required to trigger that? Is that level of effort > more or less than it would take to tip over a stateful firewall (session > exhaustion, pps attack, alg bugs, vulns in the fw > > https://www.zdnet.com/article/cisco-removed-its-seventh-backdoor-account-this-year-and-thats-a-good-thing/ > ) > > 3. Assuming the hacker gleans the address of the sub, what ports are open > in the real world? What can a hacker connect to and accomplish? > > > >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Wed Apr 10 14:12:04 2019 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 10 Apr 2019 10:12:04 -0400 Subject: SNMP via proxy Message-ID: Hi, A bit off topic. One of my early mistakes in my 9-5 was hard coding the IP's of our SNMP box in all of our gear (networking equipment, Servers etc,). The box is at its limit and increasing its capacity will be nearly impossible. We mainly use Nagios and Cacti to monitor our network. Going forward I was thinking of setting up a few hosts whose job would be to simply relay SNMP traffic. This way moving forward we could hard code several IP's and bounce all traffic through one of these IP's. TIA for your advice. Regards, Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at packetflux.com Wed Apr 10 14:30:40 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Wed, 10 Apr 2019 08:30:40 -0600 Subject: SNMP via proxy In-Reply-To: References: Message-ID: Cacti and Nagios generally poll via SNMP. This means the traffic is generally NAT'able. If I really needed multiple polling SNMP servers at the same address, I'd just throw them behind some sort of NAT device. On Wed, Apr 10, 2019 at 8:13 AM Dovid Bender wrote: > > Hi, > > A bit off topic. One of my early mistakes in my 9-5 was hard coding the IP's of our SNMP box in all of our gear (networking equipment, Servers etc,). The box is at its limit and increasing its capacity will be nearly impossible. We mainly use Nagios and Cacti to monitor our network. Going forward I was thinking of setting up a few hosts whose job would be to simply relay SNMP traffic. This way moving forward we could hard code several IP's and bounce all traffic through one of these IP's. > > TIA for your advice. > > Regards, > > Dovid > -- - Forrest From phil.lavin at cloudcall.com Wed Apr 10 14:33:12 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 10 Apr 2019 14:33:12 +0000 Subject: SNMP via proxy In-Reply-To: References: Message-ID: > Going forward I was thinking of setting up a few hosts whose job would be to simply relay SNMP traffic. This way moving forward we could hard code several IP's and bounce all traffic through one of these IP's. You can Source NAT your monitoring servers through a single IP/pool of IPs on a NAT enabled router. We do something similar with RADIUS where the RADIUS server requires a single source IP for each client but the clients don't have fixed IPs (containers in AWS) From cb.list6 at gmail.com Wed Apr 10 14:42:56 2019 From: cb.list6 at gmail.com (Ca By) Date: Wed, 10 Apr 2019 07:42:56 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: Message-ID: On Wed, Apr 10, 2019 at 7:06 AM Dovid Bender wrote: > I think the traffic Amos is referring to is random traffic hitting the > devices causing them to "wake up". Everyone here knows a simple dump on > port 22 will show traffic. We have a /22 that gets an avg of 1-2 mbit of > random traffic (mainly 22 and 3389). > I believe he was talking about ipv6. Does this backscatter happen in ipv6 given how impractical scanning ipv6 is ? > On Wed, Apr 10, 2019 at 9:49 AM Ca By wrote: > >> >> >> On Wed, Apr 10, 2019 at 6:23 AM Amos Rosenboim >> wrote: >> >>> Hello NANOG, >>> >>> >>> >>> We are discussing internally and wanted to get more opinions and >>> especially more data on what are people actually doing. >>> >>> We are running an ISP network with about 150K fixed broadband users, >>> running dual stack (IPv4 behind CGNAT). >>> >>> On the ISP network IPv6 is simply routed, and is firewalled on the CPE. >>> >>> >>> >>> This network added mobile services about a year ago, also dual stack (we >>> have no control on the mobile devices so we were too concerned to choose >>> IPv6 only access). >>> >>> We have an ongoing discussion about Gi firewall (adding a firewall >>> between the subscribers and the internet, allowing only subscriber >>> initiated connections), for the IPv6 traffic. >>> >>> >>> >>> The firewall is doing very little security, the ruleset is very basic, >>> allowing anything from subscribers to the internet and blocking all traffic >>> from the internet towards the subscribers. >>> >>> We have a few rules to limit the number of connections per subscriber >>> (to a relatively high number) and that is it. >>> >>> >>> >>> One of the arguments in favor of having the firewall is that unsolicited >>> traffic from the internet can “wake” idle mobile devices, and create >>> signaling (paging) storms as well as drain user batteries. >>> >>> >>> >>> On the other hand, allowing only subscriber initiated traffic is mostly >>> achievable using ACLs on the mobile core facing routers, or is it with the >>> growing percentage of UDP traffic ? >>> >>> >>> >>> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all >>> behind CGNAT which don’t allow internet initiated connections. >>> >>> >>> >>> Anyway, we are very interested to know hear more opinions, and >>> especially to hear what are other mobile operators do. >>> >>> >>> >>> Regards >>> >>> >>> >>> Amos >>> >>> >>> >> >> Step outside the theoretical and model your real threats. Attack yourself >> of pay someone to do a real pentest. >> >> 1. Does a hacker know the ipv6 of your subs? How frequently does the sub >> get a new 128 bit address? >> >> 2. What does the hacker get from a paging storm? Economic benefit ? >> Lolz? Has a malicious paging storm ever happened in the real world? What >> level of effort would be required to trigger that? Is that level of effort >> more or less than it would take to tip over a stateful firewall (session >> exhaustion, pps attack, alg bugs, vulns in the fw >> >> https://www.zdnet.com/article/cisco-removed-its-seventh-backdoor-account-this-year-and-thats-a-good-thing/ >> ) >> >> 3. Assuming the hacker gleans the address of the sub, what ports are open >> in the real world? What can a hacker connect to and accomplish? >> >> >> >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Wed Apr 10 15:22:14 2019 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 10 Apr 2019 11:22:14 -0400 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: Message-ID: I don't v6 stats yet but it would be interesting to see. I did a tcpdump on one v6 IP and saw hundreds of requests to port 25. On Wed, Apr 10, 2019 at 10:43 AM Ca By wrote: > > > On Wed, Apr 10, 2019 at 7:06 AM Dovid Bender wrote: > >> I think the traffic Amos is referring to is random traffic hitting the >> devices causing them to "wake up". Everyone here knows a simple dump on >> port 22 will show traffic. We have a /22 that gets an avg of 1-2 mbit of >> random traffic (mainly 22 and 3389). >> > > I believe he was talking about ipv6. > > Does this backscatter happen in ipv6 given how impractical scanning ipv6 > is ? > > > >> On Wed, Apr 10, 2019 at 9:49 AM Ca By wrote: >> >>> >>> >>> On Wed, Apr 10, 2019 at 6:23 AM Amos Rosenboim >>> wrote: >>> >>>> Hello NANOG, >>>> >>>> >>>> >>>> We are discussing internally and wanted to get more opinions and >>>> especially more data on what are people actually doing. >>>> >>>> We are running an ISP network with about 150K fixed broadband users, >>>> running dual stack (IPv4 behind CGNAT). >>>> >>>> On the ISP network IPv6 is simply routed, and is firewalled on the CPE. >>>> >>>> >>>> >>>> This network added mobile services about a year ago, also dual stack >>>> (we have no control on the mobile devices so we were too concerned to >>>> choose IPv6 only access). >>>> >>>> We have an ongoing discussion about Gi firewall (adding a firewall >>>> between the subscribers and the internet, allowing only subscriber >>>> initiated connections), for the IPv6 traffic. >>>> >>>> >>>> >>>> The firewall is doing very little security, the ruleset is very basic, >>>> allowing anything from subscribers to the internet and blocking all traffic >>>> from the internet towards the subscribers. >>>> >>>> We have a few rules to limit the number of connections per subscriber >>>> (to a relatively high number) and that is it. >>>> >>>> >>>> >>>> One of the arguments in favor of having the firewall is that >>>> unsolicited traffic from the internet can “wake” idle mobile devices, and >>>> create signaling (paging) storms as well as drain user batteries. >>>> >>>> >>>> >>>> On the other hand, allowing only subscriber initiated traffic is mostly >>>> achievable using ACLs on the mobile core facing routers, or is it with the >>>> growing percentage of UDP traffic ? >>>> >>>> >>>> >>>> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all >>>> behind CGNAT which don’t allow internet initiated connections. >>>> >>>> >>>> >>>> Anyway, we are very interested to know hear more opinions, and >>>> especially to hear what are other mobile operators do. >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> Amos >>>> >>>> >>>> >>> >>> Step outside the theoretical and model your real threats. Attack >>> yourself of pay someone to do a real pentest. >>> >>> 1. Does a hacker know the ipv6 of your subs? How frequently does the sub >>> get a new 128 bit address? >>> >>> 2. What does the hacker get from a paging storm? Economic benefit ? >>> Lolz? Has a malicious paging storm ever happened in the real world? What >>> level of effort would be required to trigger that? Is that level of effort >>> more or less than it would take to tip over a stateful firewall (session >>> exhaustion, pps attack, alg bugs, vulns in the fw >>> >>> https://www.zdnet.com/article/cisco-removed-its-seventh-backdoor-account-this-year-and-thats-a-good-thing/ >>> ) >>> >>> 3. Assuming the hacker gleans the address of the sub, what ports are >>> open in the real world? What can a hacker connect to and accomplish? >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tippenring at gmail.com Wed Apr 10 14:15:35 2019 From: tippenring at gmail.com (Dave Phelps) Date: Wed, 10 Apr 2019 09:15:35 -0500 Subject: SNMP via proxy In-Reply-To: References: Message-ID: Some devices only accept IP addresses as destinations, or resolve a FQDN to an IP and that goes in the config. I add secondary IPs to servers for these functions. Then I can simply move the IP to a new host whenever the role moves. On Wed, Apr 10, 2019 at 9:13 AM Dovid Bender wrote: > Hi, > > A bit off topic. One of my early mistakes in my 9-5 was hard coding the > IP's of our SNMP box in all of our gear (networking equipment, Servers > etc,). The box is at its limit and increasing its capacity will be > nearly impossible. We mainly use Nagios and Cacti to monitor our network. > Going forward I was thinking of setting up a few hosts whose job would be > to simply relay SNMP traffic. This way moving forward we could hard code > several IP's and bounce all traffic through one of these IP's. > > TIA for your advice. > > Regards, > > Dovid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Apr 10 16:50:58 2019 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Apr 2019 12:50:58 -0400 Subject: SNMP via proxy In-Reply-To: References: Message-ID: <2C857378-21C7-4255-854F-EB772B8C8D0D@puck.nether.net> This is one of (many) reasons why a number of people have been converting to a streaming telemetry model of getting data out of devices. You can send it to a relay host and visualize in your favorite magic (eg: grafana w/ influx or some other storage). - Jared > On Apr 10, 2019, at 10:15 AM, Dave Phelps wrote: > > Some devices only accept IP addresses as destinations, or resolve a FQDN to an IP and that goes in the config. > > I add secondary IPs to servers for these functions. Then I can simply move the IP to a new host whenever the role moves. > > On Wed, Apr 10, 2019 at 9:13 AM Dovid Bender wrote: > Hi, > > A bit off topic. One of my early mistakes in my 9-5 was hard coding the IP's of our SNMP box in all of our gear (networking equipment, Servers etc,). The box is at its limit and increasing its capacity will be nearly impossible. We mainly use Nagios and Cacti to monitor our network. Going forward I was thinking of setting up a few hosts whose job would be to simply relay SNMP traffic. This way moving forward we could hard code several IP's and bounce all traffic through one of these IP's. > > TIA for your advice. > > Regards, > > Dovid > From branto at branto.com Wed Apr 10 17:18:33 2019 From: branto at branto.com (Brant Ian Stevens) Date: Wed, 10 Apr 2019 13:18:33 -0400 Subject: SNMP via proxy In-Reply-To: <2C857378-21C7-4255-854F-EB772B8C8D0D@puck.nether.net> References: <2C857378-21C7-4255-854F-EB772B8C8D0D@puck.nether.net> Message-ID: <03889647-92a3-afc3-5116-7e0a5def7632@branto.com> This might be what you're looking for... http://www.net-snmp.org/wiki/index.php/Snmpd_proxy -- Regards, Brant Ian Stevens branto at branto.com Jared Mauch wrote on 4/10/19 12:50 PM: > This is one of (many) reasons why a number of people have been converting to a streaming telemetry model of getting data out of devices. You can send it to a relay host and visualize in your favorite magic (eg: grafana w/ influx or some other storage). > > - Jared > >> On Apr 10, 2019, at 10:15 AM, Dave Phelps wrote: >> >> Some devices only accept IP addresses as destinations, or resolve a FQDN to an IP and that goes in the config. >> >> I add secondary IPs to servers for these functions. Then I can simply move the IP to a new host whenever the role moves. >> >> On Wed, Apr 10, 2019 at 9:13 AM Dovid Bender wrote: >> Hi, >> >> A bit off topic. One of my early mistakes in my 9-5 was hard coding the IP's of our SNMP box in all of our gear (networking equipment, Servers etc,). The box is at its limit and increasing its capacity will be nearly impossible. We mainly use Nagios and Cacti to monitor our network. Going forward I was thinking of setting up a few hosts whose job would be to simply relay SNMP traffic. This way moving forward we could hard code several IP's and bounce all traffic through one of these IP's. >> >> TIA for your advice. >> >> Regards, >> >> Dovid >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffshultz at sctcweb.com Wed Apr 10 17:55:12 2019 From: jeffshultz at sctcweb.com (Jeff Shultz) Date: Wed, 10 Apr 2019 10:55:12 -0700 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019 at 7:43 PM david raistrick wrote: > > folks, > > I've been away from nanog for a long time - and away from the ISP world for longer. > > Looking at a house in a new area, at&t copper splice box out front, bellsouth fiber markers as well (yes, that's usually just passing by. but it's there). Owners since '82 said the telephone company was AT&T - but the New AT&T apparently no longer offers phone or internet service there. > It seems like _someone_ has to be the CLEC and "Carrier of Last Resort" for the area. Not that that means you are going to get the service you want. Check with the Florida Public Services Commission for what you should be able to expect: http://www.psc.state.fl.us/ -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!!                      _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ From kmedcalf at dessus.com Wed Apr 10 17:58:28 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 10 Apr 2019 11:58:28 -0600 Subject: Facebook (account) In-Reply-To: Message-ID: It would depend on whether FB is being paid to provide a service or not. However, if "your friend" is not paying FB to provide a service to them then there is really nought that you can do about it. Otherwise, the course of action to be taken will be specified in the contract which was signed by both parties ... and at the very least payment for services which are not being provided should be terminated immediately. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nathan >Anderson >Sent: Tuesday, 9 April, 2019 20:05 >To: 'nanog at nanog.org' >Subject: Facebook (account) > >Fellow NetOps, > >I realize this is an unorthodox / off-topic request, but I've been >trying to help a friend out and don't know how to advise her next. > >If there is someone from FB here who has connections to someone in >account security and is willing to contact me off-list, I'd really >appreciate it. A friend had her FB account of many years hijacked >and then held for ransom by a random dude. When she asked FB to >intercede, she appeared to have her account back for a short time (< >24 hrs) before FB themselves blocked the account, and that's where we >are now. It's been over 2 weeks and she has been going round and >round with "CS" and getting nowhere...whoever these robots are keep >repeating requests for her to send in ID, which she does, and then >they repeat the request again and it just goes in a circle. I have a >feeling that I know what's going on behind-the-scenes, but we can't >seem to get a living, breathing human over there who isn't just >reading a script to actually listen to her. Seriously, what is the >average person supposed to do under these circumstances? > >If this was just the story of a lone FB account I'm not sure I would >bother and I'd just tell her to get a new one. But she runs a >business (popular local coffee shop) with a FB page that this account >of hers was apparently the only admin for. > >Thanks in advance for any leads, > >-- >Nathan Anderson >First Step Internet, LLC >nathana at fsr.com From owen at delong.com Wed Apr 10 19:52:20 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Apr 2019 12:52:20 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: Message-ID: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> > We have an ongoing discussion about Gi firewall (adding a firewall between the subscribers and the internet, allowing only subscriber initiated connections), for the IPv6 traffic. > > > > The firewall is doing very little security, the ruleset is very basic, allowing anything from subscribers to the internet and blocking all traffic from the internet towards the subscribers. > > We have a few rules to limit the number of connections per subscriber (to a relatively high number) and that is it. > What would be the process for a subscriber who wishes to allow inbound connections? If you are simply saying that as a customer of your ISP you simply can’t allow inbound IPv6 connections at all, then you are becoming a very poor substitute for an ISP IMHO. > One of the arguments in favor of having the firewall is that unsolicited traffic from the internet can “wake” idle mobile devices, and create signaling (paging) storms as well as drain user batteries. > > There are lots of ways to configure alerts and reduce this problem space. If you want to provide a checkbox on the my.t-mobile page for the user to turn this firewall on or off on a per device basis, then sure, I could see that as viable. Even if it annoyingly defaults to on. > On the other hand, allowing only subscriber initiated traffic is mostly achievable using ACLs on the mobile core facing routers, or is it with the growing percentage of UDP traffic ? > Is it even desirable to allow only subscriber initiated traffic? Case in point, I will occasionally end up tethering my laptop (mobile hot spot) and want certain authorized individuals to be able to VNC into it via that tethering connection. There have been other times when I’ve had things on the other side of a tether that I wanted to ssh into. There are also things like Particle IONs where it is desirable to be able to push firmware updates OTA. I realize that Particle is sadly lagging on IPv6 support, but it will, hopefully, one day become a valid use case as well. > BTW – I don’t mention IPv4 traffic on the mobile network as it’s all behind CGNAT which don’t allow internet initiated connections. > Yes, but IPv6 is supposed to hope us recover from this travesty. > Anyway, we are very interested to know hear more opinions, and especially to hear what are other mobile operators do. > As is tradition, most operators screw the customer in one way or another in this regard. Some haven’t thought about screwing customers in this particular way in IPv6 yet and so IPv6 sometimes works as one would hope. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos at oasis-tech.net Wed Apr 10 20:20:13 2019 From: amos at oasis-tech.net (Amos Rosenboim) Date: Wed, 10 Apr 2019 20:20:13 +0000 Subject: Gi Firewall for mobile subscribers In-Reply-To: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> References: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> Message-ID: Owen, Let me clarify a few points: 1. I am in favor of end to end connectivity and IPv6 can help restore this. 2. In the fixed broadband portion of the network this is the case. IPv6 is routed to the subscriber CPE. Firewall on the CPE is turned on by default, but can be turned off by the user. 3. In the mobile portion life are a bit more complicated. Unsolicited traffic from the internet towards an idle subscriber triggers a signaling process called paging. Extra paging is expensive in terms of signaling resource utilization, as well as on device battery. Amos Sent from my iPhone On 10 Apr 2019, at 22:52, Owen DeLong > wrote: We have an ongoing discussion about Gi firewall (adding a firewall between the subscribers and the internet, allowing only subscriber initiated connections), for the IPv6 traffic. The firewall is doing very little security, the ruleset is very basic, allowing anything from subscribers to the internet and blocking all traffic from the internet towards the subscribers. We have a few rules to limit the number of connections per subscriber (to a relatively high number) and that is it. What would be the process for a subscriber who wishes to allow inbound connections? If you are simply saying that as a customer of your ISP you simply can't allow inbound IPv6 connections at all, then you are becoming a very poor substitute for an ISP IMHO. One of the arguments in favor of having the firewall is that unsolicited traffic from the internet can "wake" idle mobile devices, and create signaling (paging) storms as well as drain user batteries. There are lots of ways to configure alerts and reduce this problem space. If you want to provide a checkbox on the my.t-mobile page for the user to turn this firewall on or off on a per device basis, then sure, I could see that as viable. Even if it annoyingly defaults to on. On the other hand, allowing only subscriber initiated traffic is mostly achievable using ACLs on the mobile core facing routers, or is it with the growing percentage of UDP traffic ? Is it even desirable to allow only subscriber initiated traffic? Case in point, I will occasionally end up tethering my laptop (mobile hot spot) and want certain authorized individuals to be able to VNC into it via that tethering connection. There have been other times when I've had things on the other side of a tether that I wanted to ssh into. There are also things like Particle IONs where it is desirable to be able to push firmware updates OTA. I realize that Particle is sadly lagging on IPv6 support, but it will, hopefully, one day become a valid use case as well. BTW - I don't mention IPv4 traffic on the mobile network as it's all behind CGNAT which don't allow internet initiated connections. Yes, but IPv6 is supposed to hope us recover from this travesty. Anyway, we are very interested to know hear more opinions, and especially to hear what are other mobile operators do. As is tradition, most operators screw the customer in one way or another in this regard. Some haven't thought about screwing customers in this particular way in IPv6 yet and so IPv6 sometimes works as one would hope. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Wed Apr 10 20:22:16 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 10 Apr 2019 16:22:16 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: <0d32ecc9-8bc4-70f2-b5d8-88e8f0817365@monmotha.net> On 4/10/19 1:55 PM, Jeff Shultz wrote: > It seems like_someone_ has to be the CLEC and "Carrier of Last > Resort" for the area. Not that that means you are going to get the > service you want. Where I live, you can get AT&T POTS from the ILEC of record. Sometimes it even works...when their cross box/remote terminal isn't full of water, has power/batteries haven't died, etc.! They really push people toward their "wireless home phone" solution which is basically an LTE radio and ATA in a box. It's somewhat significantly cheaper than their wireline POTS service. No DSL, no HFC/cable, no consumer fiber. T1 is available at full tariff rate from the 90s plus about 20 miles of line extension charges. ISDN is no longer offered (or so they say). Only wISP worth mentioning (i.e. can deliver more than 1Mbps on a good day) is myself (fiber coming this summer hopefully). Basically the entire township is a dead zone as far as wireline goes. I pay dearly for my dedicated fiber backhaul to make service worth using available. I'm about 10 minutes from the county seat which has population over 10k and about 45 minutes from downtown metro of >800k. Most gov. agencies have the entire county flagged as "not rural" and ineligible for subsidies. These areas definitely exist. -- Brandon Martin From ross at tajvar.io Wed Apr 10 20:36:01 2019 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 10 Apr 2019 16:36:01 -0400 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> Message-ID: I agree with Owen that an always-on firewall which blocks all inbound traffic would be very frustrating to some users. I do understand your need as a provider to prevent expensive signaling operations. I think the suggestion of a toggle in a web portal to disable the firewall is a good compromise. Most users will not need to make inbound connections to their cellular devices, so the impact to your network would likely be small. On Wed, Apr 10, 2019 at 4:23 PM Amos Rosenboim wrote: > Owen, > > Let me clarify a few points: > > 1. I am in favor of end to end connectivity and IPv6 can help restore this. > > 2. In the fixed broadband portion of the network this is the case. > IPv6 is routed to the subscriber CPE. > Firewall on the CPE is turned on by default, but can be turned off by the > user. > > 3. In the mobile portion life are a bit more complicated. > Unsolicited traffic from the internet towards an idle subscriber triggers > a signaling process called paging. > Extra paging is expensive in terms of signaling resource utilization, as > well as on device battery. > > > Amos > > Sent from my iPhone > > On 10 Apr 2019, at 22:52, Owen DeLong wrote: > > > We have an ongoing discussion about Gi firewall (adding a firewall between >> the subscribers and the internet, allowing only subscriber initiated >> connections), for the IPv6 traffic. >> > >> >> The firewall is doing very little security, the ruleset is very basic, >> allowing anything from subscribers to the internet and blocking all traffic >> from the internet towards the subscribers. >> >> We have a few rules to limit the number of connections per subscriber (to >> a relatively high number) and that is it. >> > > What would be the process for a subscriber who wishes to allow inbound > connections? > > If you are simply saying that as a customer of your ISP you simply can’t > allow inbound IPv6 connections at all, then you are becoming a very poor > substitute for an ISP IMHO. > > One of the arguments in favor of having the firewall is that unsolicited >> traffic from the internet can “wake” idle mobile devices, and create >> signaling (paging) storms as well as drain user batteries. >> >> > There are lots of ways to configure alerts and reduce this problem space. > If you want to provide a checkbox on the my.t-mobile page for the user to > turn this firewall on or off on a per device basis, then sure, I could see > that as viable. Even if it annoyingly defaults to on. > > > On the other hand, allowing only subscriber initiated traffic is mostly >> achievable using ACLs on the mobile core facing routers, or is it with the >> growing percentage of UDP traffic ? >> > Is it even desirable to allow only subscriber initiated traffic? > > Case in point, I will occasionally end up tethering my laptop (mobile hot > spot) and want certain authorized individuals to be able to VNC into it via > that tethering connection. > > There have been other times when I’ve had things on the other side of a > tether that I wanted to ssh into. > > There are also things like Particle IONs where it is desirable to be able > to push firmware updates OTA. I realize that Particle is sadly lagging on > IPv6 support, but it will, hopefully, one day become a valid use case as > well. > > BTW – I don’t mention IPv4 traffic on the mobile network as it’s all >> behind CGNAT which don’t allow internet initiated connections. >> > Yes, but IPv6 is supposed to hope us recover from this travesty. > > Anyway, we are very interested to know hear more opinions, and especially >> to hear what are other mobile operators do. >> > > As is tradition, most operators screw the customer in one way or another > in this regard. Some haven’t thought about screwing customers in this > particular way in IPv6 yet and so IPv6 sometimes works as one would hope. > > Owen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at chrillesen.dk Wed Apr 10 18:02:20 2019 From: jan at chrillesen.dk (Jan Chrillesen) Date: Wed, 10 Apr 2019 20:02:20 +0200 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: Message-ID: <20190410180220.GJ87786@stout2.chrillesen.dk> On tir., 09 apr. 2019, Amos Rosenboim wrote: > On the other hand, allowing only subscriber initiated traffic is mostly achievable using ACLs on the mobile core facing routers, or is it with the growing percentage of UDP traffic ? > > BTW – I don’t mention IPv4 traffic on the mobile network as it’s all behind CGNAT which don’t allow internet initiated connections. > > Anyway, we are very interested to know hear more opinions, and especially to hear what are other mobile operators do. In a previous job we did have a stateful Gi firewall and experienced first hand what backscatter does to the radio network. By accident we allowed icmp from the Internet to the subcribers and paging went up by 30%. We all agree that the average amount of backscatter on IPv6 is much less than what we see in IPv4. However active IPv6 adresses are exposed (for instance on IRC!) and will be targeted by attackers. Also half-open TCP sessions can be very long running - for instance a mobile goes offline while downloading a file. Some webservers will keep trying to send data for a long time, and having a stateful device with agressive timeouts on half open sessions will definately reduce paging Also keep in mind that most GGSN/PGW will assign a /64 (and not a /128) so if someone does a scan targeting that specific /64 you might see a lot of traffic to the device. I would strongly suggest deploying a stateful device - purely to protect the radio and signaling network - not the terminal/phone - Jan From fkittred at gwi.net Wed Apr 10 18:58:59 2019 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 10 Apr 2019 14:58:59 -0400 Subject: residential/smb internet access in 2019 - help? In-Reply-To: References: Message-ID: I believe there is no Federal requirement that there be a Provider of Last Resort (POLR). State law might require it, but in at least some states there is possible to have areas without a POLR. At the national level the regulatory theory is that when there is sufficient competition in a market, the POLR requirement is relieved. In any case, POLR refers only to phone service, not Internet. On Wed, Apr 10, 2019 at 1:56 PM Jeff Shultz wrote: > On Tue, Mar 26, 2019 at 7:43 PM david raistrick > wrote: > > > > folks, > > > > I've been away from nanog for a long time - and away from the ISP world > for longer. > > > > Looking at a house in a new area, at&t copper splice box out front, > bellsouth fiber markers as well (yes, that's usually just passing by. but > it's there). Owners since '82 said the telephone company was AT&T - but > the New AT&T apparently no longer offers phone or internet service there. > > > > It seems like _someone_ has to be the CLEC and "Carrier of Last > Resort" for the area. Not that that means you are going to get the > service you want. > > Check with the Florida Public Services Commission for what you should > be able to expect: http://www.psc.state.fl.us/ > > > -- > Jeff Shultz > > -- > Like us on Social Media for News, Promotions, and other information!! > > > > > > > > > > > > > > > > > > > > _**** This message > contains confidential information and is intended only for the individual > named. If you are not the named addressee you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, > arrive late or incomplete, or contain viruses. The sender therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. ****_ > > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathana at fsr.com Wed Apr 10 21:42:48 2019 From: nathana at fsr.com (Nathan Anderson) Date: Wed, 10 Apr 2019 21:42:48 +0000 Subject: Facebook (account) In-Reply-To: References: <27B45E04-BD9E-4DED-A8B6-79208C591965@dataix.net> Message-ID: Matt Harris wrote: > On Apr 9, 2019, at 21:05, Nathan Anderson wrote: > > > a FB page that this account of hers was apparently the only admin for. > > Redundancy: it's not just a concept to be applied to devices and wiring.    Preaching. To. The. Choir. :-) -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From mureninc at gmail.com Wed Apr 10 23:45:36 2019 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 10 Apr 2019 18:45:36 -0500 Subject: Facebook (account) In-Reply-To: <27B45E04-BD9E-4DED-A8B6-79208C591965@dataix.net> References: <27B45E04-BD9E-4DED-A8B6-79208C591965@dataix.net> Message-ID: #DeleteFacebook. On Tue, 9 Apr 2019 at 21:18, J. Hellenthal via NANOG wrote: > Delete fB account ... > > -- > J. Hellenthal > > The fact that there's a highway to Hell but only a stairway to Heaven says > a lot about anticipated traffic volume. > > > On Apr 9, 2019, at 21:05, Nathan Anderson wrote: > > > > Fellow NetOps, > > > > I realize this is an unorthodox / off-topic request, but I've been > trying to help a friend out and don't know how to advise her next. > > > > If there is someone from FB here who has connections to someone in > account security and is willing to contact me off-list, I'd really > appreciate it. A friend had her FB account of many years hijacked and then > held for ransom by a random dude. When she asked FB to intercede, she > appeared to have her account back for a short time (< 24 hrs) before FB > themselves blocked the account, and that's where we are now. It's been > over 2 weeks and she has been going round and round with "CS" and getting > nowhere...whoever these robots are keep repeating requests for her to send > in ID, which she does, and then they repeat the request again and it just > goes in a circle. I have a feeling that I know what's going on > behind-the-scenes, but we can't seem to get a living, breathing human over > there who isn't just reading a script to actually listen to her. > Seriously, what is the average person supposed to do under these > circumstances? > > > > If this was just the story of a lone FB account I'm not sure I would > bother and I'd just tell her to get a new one. But she runs a business > (popular local coffee shop) with a FB page that this account of hers was > apparently the only admin for. > > > > Thanks in advance for any leads, > > > > -- > > Nathan Anderson > > First Step Internet, LLC > > nathana at fsr.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Thu Apr 11 05:39:28 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 11 Apr 2019 07:39:28 +0200 (CEST) Subject: Gi Firewall for mobile subscribers In-Reply-To: <20190410180220.GJ87786@stout2.chrillesen.dk> References: <20190410180220.GJ87786@stout2.chrillesen.dk> Message-ID: On Wed, 10 Apr 2019, Jan Chrillesen wrote: > Also keep in mind that most GGSN/PGW will assign a /64 (and not a /128) All 3GPP devices assign /64 per bearer because that's what's in the 3GPP spec. I've been told 3GPP went to IETF and asked what to do, IETF said "assign /64 per device" and that's what ended up in the specs. > so if someone does a scan targeting that specific /64 you might see a > lot of traffic to the device. I would strongly suggest deploying a > stateful device - purely to protect the radio and signaling network - > not the terminal/phone If they scan the /64 then this won't cause excessive paging traffic as the device will already be out of low power mode. The balanced solution is to have a stateful device that typically does nothing but has some kind of "abuse detection" which triggers filtering certain Internet sources when it decides that this device is performing scans of larger IP spaces. This protects the mobile network from paging storms but also allows users to be reachable from the Internet. -- Mikael Abrahamsson email: swmike at swm.pp.se From tore at fud.no Thu Apr 11 07:23:26 2019 From: tore at fud.no (Tore Anderson) Date: Thu, 11 Apr 2019 09:23:26 +0200 Subject: Gi Firewall for mobile subscribers In-Reply-To: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> References: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> Message-ID: <8872107d-daf8-e76e-0524-6b83207696e8@fud.no> * Owen DeLong > What would be the process for a subscriber who wishes to allow inbound connections? > > If you are simply saying that as a customer of your ISP you simply can’t allow inbound IPv6 connections at all, then you are becoming a very poor substitute for an ISP IMHO. I have to agree with this. We've been wanting to replace our all of our ad-hoc OOB links with a standardised setup based on LTE connectivity to an embedded login/console server at each PoP. IPv6 would be perfect due to no CGNAT and infinitesimal levels of background scanning. Unfortunately Telenor has decided to deploy a central firewall that drops all inbound connections, making their service totally unusable for our use case. I guess they don't want our money. Maybe with EU RLAH I could simply find another more suitable provider abroad. Maybe I'd even get vPLMN redundancy that way. Hmm... Tore From nanog-isp at mail.com Thu Apr 11 12:05:58 2019 From: nanog-isp at mail.com (nanog-isp at mail.com) Date: Thu, 11 Apr 2019 14:05:58 +0200 Subject: Netgate TNSR software router using DPDK/VPP/FRR Message-ID: Hello NANOG, Has anybody kicked the tires of Netgate's TNSR software router that uses DPDK/VPP/FRR and would like to share their experience? Jared From the76posse at gmail.com Thu Apr 11 12:21:54 2019 From: the76posse at gmail.com (Steve Danello) Date: Thu, 11 Apr 2019 08:21:54 -0400 Subject: Multi-tenant Internet Access Message-ID: <740C52E8-7C0D-440A-9627-50BF7042E7D5@gmail.com> Hello all; forwarding a question from a couple folks I know that are having issues with Comcast internet access at a seasonal resort on the East Coast. Does anyone know how multi tenant access works? It appears that something has been put in place that prevents cable modems from syncing and actually going ‘online’. The technicians have mentioned MDTA’s and Q2Q’s which are probably in the path; but can someone provide a brief explanation of how it works? There are somewhere on the order of 500+ tenants at the facility in question; they used to be able to get internet service over the same cabling where they were provided about 60+ standard def channels. Any guidance appreciated. Best; Steve From patrick_mcevilly at harvard.edu Thu Apr 11 14:08:17 2019 From: patrick_mcevilly at harvard.edu (Patrick McEvilly) Date: Thu, 11 Apr 2019 10:08:17 -0400 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <5E0AC5B3-665A-4845-A0C2-B340D4D4DF3B@harvard.edu> References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> <30abd3bdd62849b9a040165caf0d386b@BN8PR07MB6084.namprd07.prod.outlook.com> <5E0AC5B3-665A-4845-A0C2-B340D4D4DF3B@harvard.edu> Message-ID: I'm working with Level3 on a similar problem. They filter both UDP and TCP port 1900 on our peer to them. This is blocking all connections that randomly use ephemeral tcp port 1900. They are refusing to remove the tcp port 1900 filter without dispensation from the DDoS security gods. I understand blocking UDP 1900, what is the purpose of Level3 filtering tcp port 1900? On 3/25/19, 12:44 PM, "NANOG on behalf of Saku Ytti" wrote: Hey Tom, > If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose. You may at some cases have hard to troubleshoot issues, which is true for everything, even when perfectly configured, because software is not perfect. However choosing to do iACL is still something many networks choose to do, because the upside is worth the complexity to them. > Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor. Depends on implementation, on some implementations it is zero-cost on some it is not. On most implementations it's very cheap, particularly compared to say uRPF. It seems your position is 'i don't know how ACL works on my platforms and i don't trust myself to write ACL, so i should not do them', which is perfectly valid position under those constrains, but other networks have other constrains under which it is no longer valid proposal to omit doing iACL. I would encourage networks to continue deploying iACL and consider it BCP. iACL removes attack surface and protects you from host of known and unknown SIRT issues. -- ++ytti From owen at delong.com Thu Apr 11 15:43:53 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Apr 2019 08:43:53 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: <20190410180220.GJ87786@stout2.chrillesen.dk> Message-ID: <3F1CCDF0-F5F6-491B-9678-28D4D448DC9D@delong.com> > On Apr 10, 2019, at 10:39 PM, Mikael Abrahamsson wrote: > > On Wed, 10 Apr 2019, Jan Chrillesen wrote: > >> Also keep in mind that most GGSN/PGW will assign a /64 (and not a /128) > > All 3GPP devices assign /64 per bearer because that's what's in the 3GPP spec. I've been told 3GPP went to IETF and asked what to do, IETF said "assign /64 per device" and that's what ended up in the specs. > >> so if someone does a scan targeting that specific /64 you might see a lot of traffic to the device. I would strongly suggest deploying a stateful device - purely to protect the radio and signaling network - not the terminal/phone > > If they scan the /64 then this won't cause excessive paging traffic as the device will already be out of low power mode. If they scan the entire /64, I’ll be impressed. Let’s assume a maximum packet rate of 10,000 packets per second. A /64 contains 18,446,744,073,709,551,616 addresses. If we ping continuously and only count one of the two packets required for each ping attempt, that’s 184,467,440,737,096 seconds. Putting this in perspective, that’s 3,074,457,345,619 minutes or 51,240,955,761 hours or 2,135,039,824 days or 5,849,424 years. I’m pretty sure that no matter how good your power management is, any cell phone’s battery will die long before its /64 can be scanned. > The balanced solution is to have a stateful device that typically does nothing but has some kind of "abuse detection" which triggers filtering certain Internet sources when it decides that this device is performing scans of larger IP spaces. This protects the mobile network from paging storms but also allows users to be reachable from the Internet. +1 Owen From owen at delong.com Thu Apr 11 16:28:22 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Apr 2019 09:28:22 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> Message-ID: <019D61EA-4674-4E26-A7E5-E8426101F95F@delong.com> > On Apr 10, 2019, at 1:20 PM, Amos Rosenboim wrote: > > Owen, > > Let me clarify a few points: > > 1. I am in favor of end to end connectivity and IPv6 can help restore this. > > 2. In the fixed broadband portion of the network this is the case. > IPv6 is routed to the subscriber CPE. > Firewall on the CPE is turned on by default, but can be turned off by the user. > > 3. In the mobile portion life are a bit more complicated. > Unsolicited traffic from the internet towards an idle subscriber triggers a signaling process called paging. > Extra paging is expensive in terms of signaling resource utilization, as well as on device battery. That’s a problem I leave for the developers of the platform to improve/solve in the design of 5G or subsequent protocols. It should not be worked around by permanently and irrevocably disabling end user functionality. Owen > > > Amos > > Sent from my iPhone > > On 10 Apr 2019, at 22:52, Owen DeLong > wrote: > >> >>> We have an ongoing discussion about Gi firewall (adding a firewall between the subscribers and the internet, allowing only subscriber initiated connections), for the IPv6 traffic. >>> >>> >>> >>> The firewall is doing very little security, the ruleset is very basic, allowing anything from subscribers to the internet and blocking all traffic from the internet towards the subscribers. >>> >>> We have a few rules to limit the number of connections per subscriber (to a relatively high number) and that is it. >>> >> >> What would be the process for a subscriber who wishes to allow inbound connections? >> >> If you are simply saying that as a customer of your ISP you simply can’t allow inbound IPv6 connections at all, then you are becoming a very poor substitute for an ISP IMHO. >> >>> One of the arguments in favor of having the firewall is that unsolicited traffic from the internet can “wake” idle mobile devices, and create signaling (paging) storms as well as drain user batteries. >>> >>> >> >> There are lots of ways to configure alerts and reduce this problem space. If you want to provide a checkbox on the my.t-mobile page for the user to turn this firewall on or off on a per device basis, then sure, I could see that as viable. Even if it annoyingly defaults to on. >> >>> On the other hand, allowing only subscriber initiated traffic is mostly achievable using ACLs on the mobile core facing routers, or is it with the growing percentage of UDP traffic ? >>> >> Is it even desirable to allow only subscriber initiated traffic? >> >> Case in point, I will occasionally end up tethering my laptop (mobile hot spot) and want certain authorized individuals to be able to VNC into it via that tethering connection. >> >> There have been other times when I’ve had things on the other side of a tether that I wanted to ssh into. >> >> There are also things like Particle IONs where it is desirable to be able to push firmware updates OTA. I realize that Particle is sadly lagging on IPv6 support, but it will, hopefully, one day become a valid use case as well. >> >>> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all behind CGNAT which don’t allow internet initiated connections. >>> >> Yes, but IPv6 is supposed to hope us recover from this travesty. >> >>> Anyway, we are very interested to know hear more opinions, and especially to hear what are other mobile operators do. >>> >> >> As is tradition, most operators screw the customer in one way or another in this regard. Some haven’t thought about screwing customers in this particular way in IPv6 yet and so IPv6 sometimes works as one would hope. >> >> Owen >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredbaker.ietf at gmail.com Thu Apr 11 16:45:34 2019 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Thu, 11 Apr 2019 09:45:34 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: <3F1CCDF0-F5F6-491B-9678-28D4D448DC9D@delong.com> References: <20190410180220.GJ87786@stout2.chrillesen.dk> <3F1CCDF0-F5F6-491B-9678-28D4D448DC9D@delong.com> Message-ID: <5DC2A78E-8224-4DB3-A4E6-5B283C03ED78@gmail.com> > On Apr 11, 2019, at 8:43 AM, Owen DeLong wrote: > > I’m pretty sure that no matter how good your power management is, any cell phone’s battery will die long before its /64 can be scanned. And that might be the point of the scan - not to find the addresses in use, but to deplete the battery. That would have the effect of service denial. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From owen at delong.com Thu Apr 11 18:07:53 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Apr 2019 11:07:53 -0700 Subject: Gi Firewall for mobile subscribers In-Reply-To: <5DC2A78E-8224-4DB3-A4E6-5B283C03ED78@gmail.com> References: <20190410180220.GJ87786@stout2.chrillesen.dk> <3F1CCDF0-F5F6-491B-9678-28D4D448DC9D@delong.com> <5DC2A78E-8224-4DB3-A4E6-5B283C03ED78@gmail.com> Message-ID: > On Apr 11, 2019, at 9:45 AM, Fred Baker wrote: > > > >> On Apr 11, 2019, at 8:43 AM, Owen DeLong wrote: >> >> I’m pretty sure that no matter how good your power management is, any cell phone’s battery will die long before its /64 can be scanned. > > And that might be the point of the scan - not to find the addresses in use, but to deplete the battery. That would have the effect of service denial. Why bother scanning in that case vs. just repeatedly hammering the same address? Owen From bgreene at senki.org Thu Apr 11 19:52:33 2019 From: bgreene at senki.org (Barry Raveendran Greene) Date: Thu, 11 Apr 2019 15:52:33 -0400 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> <30abd3bdd62849b9a040165caf0d386b@BN8PR07MB6084.namprd07.prod.outlook.com> <5E0AC5B3-665A-4845-A0C2-B340D4D4DF3B@harvard.edu> Message-ID: <71C5EB3F-8F70-4001-975F-5E042B6B3C47@senki.org> > On Apr 11, 2019, at 10:08, Patrick McEvilly wrote: > They are refusing to remove the tcp port 1900 filter without dispensation from the DDoS security gods. I understand blocking UDP 1900, what is the purpose of Level3 filtering tcp port 1900? Filtering Exploitable Ports and Minimizing Risk from the Internet and from Your Customers - What are you doing to prepare for the next “scanning malware” and “Internet Worm?” http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Apr 11 20:24:49 2019 From: bill at herrin.us (William Herrin) Date: Thu, 11 Apr 2019 13:24:49 -0700 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> <30abd3bdd62849b9a040165caf0d386b@BN8PR07MB6084.namprd07.prod.outlook.com> <5E0AC5B3-665A-4845-A0C2-B340D4D4DF3B@harvard.edu> Message-ID: On Thu, Apr 11, 2019 at 7:15 AM Patrick McEvilly < patrick_mcevilly at harvard.edu> wrote: > I'm working with Level3 on a similar problem. They filter both UDP and TCP port 1900 on our peer to them. This is blocking all connections that randomly use ephemeral tcp port 1900. > > They are refusing to remove the tcp port 1900 filter without dispensation from the DDoS security gods. I understand blocking UDP 1900, what is the purpose of Level3 filtering tcp port 1900? Hi Patrick, I ran in to this years ago with the NIPR to Internet gateway at Pearl. They were filtering about 100 TCP ports in the 1024 to 5000 range because they were commonly used for malware C&C. They insisted they were only blocking destination ports... Didn't quite get the concept that the source port on a packet traveling one way becomes the destination port on the return packet, or that 1024 to 5000 were common ephemeral source ports for both Windows and a number of firewall products. The idea of filtering only on syn-not-ack packets also failed to make contact in their craniums. Good luck with Level3. The folks at Pearl still hadn't figured it out years later when I changed jobs. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Apr 11 20:28:58 2019 From: bill at herrin.us (William Herrin) Date: Thu, 11 Apr 2019 13:28:58 -0700 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: <71C5EB3F-8F70-4001-975F-5E042B6B3C47@senki.org> References: <5C989122.7030704@yahoo.fr> <41650741-a196-5b1c-6965-17b487597bfe@ninjabadger.net> <30abd3bdd62849b9a040165caf0d386b@BN8PR07MB6084.namprd07.prod.outlook.com> <5E0AC5B3-665A-4845-A0C2-B340D4D4DF3B@harvard.edu> <71C5EB3F-8F70-4001-975F-5E042B6B3C47@senki.org> Message-ID: On Thu, Apr 11, 2019 at 12:52 PM Barry Raveendran Greene wrote: > On Apr 11, 2019, at 10:08, Patrick McEvilly wrote: >> They are refusing to remove the tcp port 1900 filter without dispensation from the DDoS security gods. I understand blocking UDP 1900, what is the purpose of Level3 filtering tcp port 1900? > > http://www.senki.org/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/ Which calls out UDP port 1900, not TCP port 1900. I would ask any who don't know the difference to stay away from their router's ACLs. Blocking TCP 1900 except as a destination in the initial SYN packet breaks TCP. Do that and you DO get customer complaints. Like Patrick's. Regards. Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Apr 11 20:45:32 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 11 Apr 2019 14:45:32 -0600 Subject: Incoming SSDP UDP 1900 filtering In-Reply-To: Message-ID: <2140631f058ca24094d271381f4df6a9@mail.dessus.com> On Thursday, 11 April, 2019 08:08, Patrick McEvilly wrote: >I'm working with Level3 on a similar problem. They filter both UDP >and TCP port 1900 on our peer to them. This is blocking all >connections that randomly use ephemeral tcp port 1900. >They are refusing to remove the tcp port 1900 filter without >dispensation from the DDoS security gods. I understand blocking UDP >1900, what is the purpose of Level3 filtering tcp port 1900? They are both port 1900 (that is, they have a 1900 in them -- they also probably block TCP/UDP 19000 bidirectionally as well, since that has a "1900" in it -- they likely also tried to block TCP/UDP 190000 as well, but for some reason even through that also has "1900" in it the firewall would not accept it as a 16-bit port number, so they submitted a bug report to the vendor and closed the ticket). In short, never ascribe to malice that which can be oh so easily and correctly attributed to ignorance, stupidity (incurable ignorance) and incompetence. Besides, the "Internet" package that you purchased did not include that channel. If you wish to receive channels 1900 and 19000 they are available as an add-on feature pack. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From aaron1 at gvtc.com Fri Apr 12 04:57:11 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 11 Apr 2019 23:57:11 -0500 Subject: Disney+ CDN In-Reply-To: References: Message-ID: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? disneyplus.com -Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Graves Sent: Saturday, December 29, 2018 7:22 PM To: nanog at nanog.org Subject: Disney+ CDN Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. AG -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Apr 12 05:03:32 2019 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 12 Apr 2019 00:03:32 -0500 Subject: JunOS Fusion Provider Edge In-Reply-To: References: Message-ID: <000f01d4f0ed$143ca0a0$3cb5e1e0$@gvtc.com> Can I test fusion using vMX and vQFX ? Will it work? -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Apr 12 11:52:02 2019 From: sander at steffann.nl (Sander Steffann) Date: Fri, 12 Apr 2019 13:52:02 +0200 Subject: JunOS Fusion Provider Edge In-Reply-To: <000f01d4f0ed$143ca0a0$3cb5e1e0$@gvtc.com> References: <000f01d4f0ed$143ca0a0$3cb5e1e0$@gvtc.com> Message-ID: <2BF2701A-CC29-4396-A6E1-D15D42E12369@steffann.nl> Hi Aaron, > Can I test fusion using vMX and vQFX ? Will it work? I have tried and haven't managed to get it working. It's one of the improvements that I would like to see in vMX and vQFX. #featurerequest Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From cscora at apnic.net Fri Apr 12 18:03:32 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Apr 2019 04:03:32 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190412180332.CFAE3C55B5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Apr, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 745313 Prefixes after maximum aggregation (per Origin AS): 286294 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 358952 Total ASes present in the Internet Routing Table: 63889 Prefixes per ASN: 11.67 Origin-only ASes present in the Internet Routing Table: 54986 Origin ASes announcing only one prefix: 23700 Transit ASes present in the Internet Routing Table: 8903 Transit-only ASes present in the Internet Routing Table: 274 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN (206156) 26 Prefixes from unregistered ASNs in the Routing Table: 25 Number of instances of unregistered ASNs: 29 Number of 32-bit ASNs allocated by the RIRs: 26580 Number of 32-bit ASNs visible in the Routing Table: 21664 Prefixes from 32-bit ASNs in the Routing Table: 94966 Number of bogon 32-bit ASNs visible in the Routing Table: 24 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 242 Number of addresses announced to Internet: 2849895552 Equivalent to 169 /8s, 221 /16s and 244 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 249446 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 200535 Total APNIC prefixes after maximum aggregation: 58096 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 197351 Unique aggregates announced from the APNIC address blocks: 82271 APNIC Region origin ASes present in the Internet Routing Table: 9649 APNIC Prefixes per ASN: 20.45 APNIC Region origin ASes announcing only one prefix: 2702 APNIC Region transit ASes present in the Internet Routing Table: 1426 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4640 Number of APNIC addresses announced to Internet: 773494912 Equivalent to 46 /8s, 26 /16s and 152 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 221747 Total ARIN prefixes after maximum aggregation: 104303 ARIN Deaggregation factor: 2.13 Prefixes being announced from the ARIN address blocks: 220762 Unique aggregates announced from the ARIN address blocks: 105233 ARIN Region origin ASes present in the Internet Routing Table: 18426 ARIN Prefixes per ASN: 11.98 ARIN Region origin ASes announcing only one prefix: 6824 ARIN Region transit ASes present in the Internet Routing Table: 1891 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2655 Number of ARIN addresses announced to Internet: 1079234176 Equivalent to 64 /8s, 83 /16s and 206 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 205349 Total RIPE prefixes after maximum aggregation: 97932 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 201735 Unique aggregates announced from the RIPE address blocks: 119703 RIPE Region origin ASes present in the Internet Routing Table: 25987 RIPE Prefixes per ASN: 7.76 RIPE Region origin ASes announcing only one prefix: 11538 RIPE Region transit ASes present in the Internet Routing Table: 3697 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8009 Number of RIPE addresses announced to Internet: 718764160 Equivalent to 42 /8s, 215 /16s and 120 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 96391 Total LACNIC prefixes after maximum aggregation: 21650 LACNIC Deaggregation factor: 4.45 Prefixes being announced from the LACNIC address blocks: 97742 Unique aggregates announced from the LACNIC address blocks: 42278 LACNIC Region origin ASes present in the Internet Routing Table: 8268 LACNIC Prefixes per ASN: 11.82 LACNIC Region origin ASes announcing only one prefix: 2198 LACNIC Region transit ASes present in the Internet Routing Table: 1530 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5814 Number of LACNIC addresses announced to Internet: 173673728 Equivalent to 10 /8s, 90 /16s and 13 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 21265 Total AfriNIC prefixes after maximum aggregation: 4292 AfriNIC Deaggregation factor: 4.95 Prefixes being announced from the AfriNIC address blocks: 27481 Unique aggregates announced from the AfriNIC address blocks: 9244 AfriNIC Region origin ASes present in the Internet Routing Table: 1267 AfriNIC Prefixes per ASN: 21.69 AfriNIC Region origin ASes announcing only one prefix: 438 AfriNIC Region transit ASes present in the Internet Routing Table: 243 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 546 Number of AfriNIC addresses announced to Internet: 104472832 Equivalent to 6 /8s, 58 /16s and 33 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4715 545 547 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4468 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3136 1305 53 VIETEL-AS-AP Viettel Group, VN 45899 3007 1736 112 VNPT-AS-VN VNPT Corp, VN 9829 2734 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2613 11120 761 KIXS-AS-KR Korea Telecom, KR 9808 2436 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2180 4906 29 CTTNET China TieTong Telecommunications 4755 2149 429 186 TATACOMM-AS TATA Communications formerl 9498 2042 427 170 BBIL-AP BHARTI Airtel Ltd., 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 11492 3644 238 589 CABLEONE - CABLE ONE, INC., US 6327 3616 1325 94 SHAW - Shaw Communications Inc., CA 22773 3392 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2615 5904 1081 AMAZON-02 - Amazon.com, Inc., US 16625 2398 1316 1813 AKAMAI-AS - Akamai Technologies, Inc., 30036 2164 356 121 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2149 2751 527 CHARTER-20115 - Charter Communications, 18566 2109 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2040 5103 577 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5444 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3245 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2639 534 1913 AKAMAI-ASN1, US 12389 2227 2221 636 ROSTELECOM-AS, RU 34984 2083 342 537 TELLCOM-AS, TR 9121 1671 1693 19 TTNET, TR 13188 1602 100 47 TRIOLAN, UA 9009 1416 148 771 M247, GB 8402 1254 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5676 3339 593 Uninet S.A. de C.V., MX 10620 3436 537 388 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 7303 1461 1000 252 Telecom Argentina S.A., AR 28573 1367 2249 191 CLARO S.A., BR 6503 1299 433 53 Axtel, S.A.B. de C.V., MX 6147 1259 374 25 Telefonica del Peru S.A.A., PE 3816 1041 507 128 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 959 521 247 Mega Cable, S.A. de C.V., MX 11172 955 144 63 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1205 393 21 LINKdotNET-AS, EG 37611 894 107 9 Afrihost, ZA 24835 884 646 21 RAYA-AS, EG 36903 827 416 126 MT-MPLS, MA 36992 819 1531 71 ETISALAT-MISR, EG 8452 709 1731 19 TE-AS TE-AS, EG 29571 495 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5676 3339 593 Uninet S.A. de C.V., MX 12479 5444 1629 140 UNI2-AS, ES 7545 4715 545 547 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4468 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3644 238 589 CABLEONE - CABLE ONE, INC., US 6327 3616 1325 94 SHAW - Shaw Communications Inc., CA 10620 3436 537 388 Telmex Colombia S.A., CO 22773 3392 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3245 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5444 5304 UNI2-AS, ES 4538 4468 4394 ERX-CERNET-BKB China Education and Research Net 7545 4715 4168 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3616 3522 SHAW - Shaw Communications Inc., CA 22773 3392 3231 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3245 3201 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3136 3083 VIETEL-AS-AP Viettel Group, VN 11492 3644 3055 CABLEONE - CABLE ONE, INC., US 10620 3436 3048 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65553 UNALLOCATED 103.132.227.0/24 138556 ARMOUR-AS-AP Armour Technologi 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 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 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 43.255.82.0/24 36351 SOFTLAYER - SoftLayer Technologies Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:37 /11:100 /12:291 /13:568 /14:1135 /15:1905 /16:13353 /17:7972 /18:13881 /19:25629 /20:39916 /21:46161 /22:93255 /23:75822 /24:424200 /25:1066 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4358 5444 UNI2-AS, ES 6327 3390 3616 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2851 3644 CABLEONE - CABLE ONE, INC., US 8551 2699 3245 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2631 3392 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 2004 2109 MEGAPATH5-US - MegaPath Corporation, US 30036 1911 2164 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1754 2086 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1600 2:967 4:21 5:3085 6:45 7:1 8:1285 9:1 12:1805 13:328 14:1987 15:36 16:4 17:244 18:58 20:50 23:2666 24:2499 25:2 27:2483 31:1973 32:97 35:36 36:847 37:3051 38:1720 39:292 40:121 41:3279 42:767 43:2024 44:151 45:7175 46:3220 47:258 49:1351 50:1106 51:322 52:1016 54:285 55:693 56:6 57:42 58:1780 59:1070 60:507 61:2124 62:2124 63:1818 64:4967 65:2223 66:4836 67:2722 68:1169 69:3525 70:1324 71:605 72:2459 74:2754 75:515 76:543 77:1760 78:1806 79:2281 80:1804 81:1509 82:1134 83:905 84:1124 85:2297 86:514 87:1535 88:1053 89:2596 90:220 91:6566 92:1370 93:2442 94:2528 95:3254 96:928 97:343 98:951 99:377 100:87 101:1158 102:543 103:20923 104:3536 105:253 106:796 107:1784 108:690 109:3718 110:1652 111:1849 112:1484 113:1394 114:1143 115:1720 116:1734 117:1904 118:2175 119:1627 120:1008 121:1041 122:2348 123:1641 124:1471 125:1979 128:1267 129:829 130:538 131:1810 132:788 133:219 134:1087 135:242 136:566 137:718 138:2041 139:841 140:639 141:871 142:798 143:1046 144:862 145:494 146:1265 147:832 148:1723 149:801 150:787 151:1012 152:1054 153:335 154:2819 155:914 156:1622 157:948 158:640 159:1940 160:1571 161:906 162:2750 163:809 164:1194 165:1569 166:448 167:1393 168:3292 169:869 170:4103 171:574 172:1140 173:2213 174:1040 175:914 176:2327 177:4193 178:2522 179:1450 180:2179 181:2409 182:2668 183:1083 184:1441 185:14946 186:3652 187:2470 188:2899 189:1968 190:8301 191:1544 192:10047 193:6657 194:5411 195:4103 196:3092 197:1765 198:5909 199:6004 200:7190 201:5112 202:10392 203:10115 204:4539 205:3028 206:3223 207:3243 208:3963 209:4246 210:3936 211:1992 212:3156 213:2938 214:1099 215:54 216:5933 217:2214 218:881 219:581 220:1861 221:968 222:980 223:1364 End of report From jared at compuwizz.net Fri Apr 12 19:01:33 2019 From: jared at compuwizz.net (Jared Geiger) Date: Fri, 12 Apr 2019 12:01:33 -0700 Subject: Disney+ CDN In-Reply-To: <001c01d4f0ec$30b28160$92178420$@gvtc.com> References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO are built on. The bits from the first two come from Akamai and Level3 CDNs. I haven't looked into where HBO Go comes from. On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: > Have we found out yet if Disney+ will have a CDN? Like Netflix oca, > Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? > > > > disneyplus.com > > > > -Aaron > > > > > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron Graves > *Sent:* Saturday, December 29, 2018 7:22 PM > *To:* nanog at nanog.org > *Subject:* Disney+ CDN > > > > Anyone know what Disney is planning on doing for streaming content > distribution once they leave Netflix? Would be nice if they'd provide an > on-prem cache server. > > > > AG > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlm at pixelgate.net Fri Apr 12 19:03:10 2019 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 12 Apr 2019 12:03:10 -0700 (PDT) Subject: Gi Firewall for mobile subscribers In-Reply-To: <8872107d-daf8-e76e-0524-6b83207696e8@fud.no> References: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> <8872107d-daf8-e76e-0524-6b83207696e8@fud.no> Message-ID: On Thu, 11 Apr 2019, Tore Anderson wrote: > We've been wanting to replace our all of our ad-hoc OOB links with a > standardised setup based on LTE connectivity to an embedded > login/console server at each PoP. IPv6 would be perfect due to no > CGNAT and infinitesimal levels of background scanning. > > Unfortunately Telenor has decided to deploy a central firewall that > drops all inbound connections, making their service totally unusable > for our use case. I guess they don't want our money. Sounds like the console server will need to "phone home". That a workaround might be possible doesn't make a firewall which the user cannot control to some degree less annoying. Though it might be that Telenor just needs to be notified/reminded that power users and business customers exist. /mark From cgrundemann at gmail.com Fri Apr 12 19:31:24 2019 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 12 Apr 2019 15:31:24 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger wrote: > An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO > are built on. The bits from the first two come from Akamai and Level3 CDNs. > I haven't looked into where HBO Go comes from. > Yep, they decided to buy BAMTech and build their own: https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > > On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: > >> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, >> Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? >> >> >> >> disneyplus.com >> >> >> >> -Aaron >> >> >> >> >> >> >> >> *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron >> Graves >> *Sent:* Saturday, December 29, 2018 7:22 PM >> *To:* nanog at nanog.org >> *Subject:* Disney+ CDN >> >> >> >> Anyone know what Disney is planning on doing for streaming content >> distribution once they leave Netflix? Would be nice if they'd provide an >> on-prem cache server. >> >> >> >> AG >> > -- @ChrisGrundemann http://chrisgrundemann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Apr 12 19:34:22 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 12 Apr 2019 15:34:22 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: I wouldn't expect them to build out anything until they got some usage data to determine the build/buy economics. On Fri, Apr 12, 2019 at 3:02 PM Jared Geiger wrote: > An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO > are built on. The bits from the first two come from Akamai and Level3 CDNs. > I haven't looked into where HBO Go comes from. > > On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: > >> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, >> Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? >> >> >> >> disneyplus.com >> >> >> >> -Aaron >> >> >> >> >> >> >> >> *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron >> Graves >> *Sent:* Saturday, December 29, 2018 7:22 PM >> *To:* nanog at nanog.org >> *Subject:* Disney+ CDN >> >> >> >> Anyone know what Disney is planning on doing for streaming content >> distribution once they leave Netflix? Would be nice if they'd provide an >> on-prem cache server. >> >> >> >> AG >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Apr 12 19:37:54 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 12 Apr 2019 14:37:54 -0500 (CDT) Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: <1660830854.2724.1555097871560.JavaMail.mhammett@ThunderFuck> $1.6B for less than half of the company and they don't even source the bits themselves? Hrm.... ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Chris Grundemann" To: "Jared Geiger" Cc: "NANOG" Sent: Friday, April 12, 2019 2:31:24 PM Subject: Re: Disney+ CDN On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger < jared at compuwizz.net > wrote: An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO are built on. The bits from the first two come from Akamai and Level3 CDNs. I haven't looked into where HBO Go comes from. Yep, they decided to buy BAMTech and build their own: https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/
On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould < aaron1 at gvtc.com > wrote:
Have we found out yet if Disney+ will have a CDN? Like Netflix oca, Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? disneyplus.com -Aaron From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Aaron Graves Sent: Saturday, December 29, 2018 7:22 PM To: nanog at nanog.org Subject: Disney+ CDN Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. AG
-- @ChrisGrundemann http://chrisgrundemann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Fri Apr 12 19:42:30 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 12 Apr 2019 19:42:30 +0000 Subject: Disney+ CDN In-Reply-To: <1660830854.2724.1555097871560.JavaMail.mhammett@ThunderFuck> References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> <1660830854.2724.1555097871560.JavaMail.mhammett@ThunderFuck> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD35C72@RTC-EXCH01.RESERVE.LDS> They owned 33% and bought another 42% making it an even 75%. Luke ns From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Friday, April 12, 2019 2:38 PM To: Chris Grundemann Cc: Jared Geiger; NANOG Subject: Re: Disney+ CDN $1.6B for less than half of the company and they don't even source the bits themselves? Hrm.... ----- Mike Hammett Intelligent Computing Solutions [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] The Brothers WISP [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] ________________________________ From: "Chris Grundemann" > To: "Jared Geiger" > Cc: "NANOG" > Sent: Friday, April 12, 2019 2:31:24 PM Subject: Re: Disney+ CDN On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger > wrote: An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO are built on. The bits from the first two come from Akamai and Level3 CDNs. I haven't looked into where HBO Go comes from. Yep, they decided to buy BAMTech and build their own: https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould > wrote: Have we found out yet if Disney+ will have a CDN? Like Netflix oca, Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? disneyplus.com -Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Graves Sent: Saturday, December 29, 2018 7:22 PM To: nanog at nanog.org Subject: Disney+ CDN Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. AG -- @ChrisGrundemann http://chrisgrundemann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Fri Apr 12 20:23:29 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Apr 2019 13:23:29 -0700 Subject: Disney+ CDN Message-ID: <20190412132329.40399BD@m0117459.ppops.net> --- cgrundemann at gmail.com wrote: From: Chris Grundemann Yep, they decided to buy BAMTech and build their own: https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ ---------------------------------------------------- https://www.bamtechmedia.com/company 2004 - "Patent awarded for GeoLocation" I'd be interested in learning about how well that one works! scott From valdis.kletnieks at vt.edu Fri Apr 12 23:43:56 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 12 Apr 2019 19:43:56 -0400 Subject: Disney+ CDN In-Reply-To: <20190412132329.40399BD@m0117459.ppops.net> References: <20190412132329.40399BD@m0117459.ppops.net> Message-ID: <1720.1555112636@turing-police> On Fri, 12 Apr 2019 13:23:29 -0700, "Scott Weeks" said: > 2004 - "Patent awarded for GeoLocation" > > I'd be interested in learning about how well that one works! Under US law, ideas submitted for patent need be "non-obvious". There's no requirement they actually be a good idea. Though I guess that it should prevent the patenting of obvious bad ideas - but $DEITY knows there's plenty of subtly flawed concepts out there.... (And there's ample evidence that the USPTO is on occasion challenged by the "obviousness" requirement...) From tore at fud.no Sat Apr 13 09:13:48 2019 From: tore at fud.no (Tore Anderson) Date: Sat, 13 Apr 2019 11:13:48 +0200 Subject: Gi Firewall for mobile subscribers In-Reply-To: References: <6CD260BE-C1AE-4EC1-92D0-D3C6FC302D34@delong.com> <8872107d-daf8-e76e-0524-6b83207696e8@fud.no> Message-ID: <6e81e3d5-ed9b-eedc-5ec8-be782e477467@fud.no> * Mark Milhollan > On Thu, 11 Apr 2019, Tore Anderson wrote: > >> We've been wanting to replace our all of our ad-hoc OOB links with a >> standardised setup based on LTE connectivity to an embedded >> login/console server at each PoP. IPv6 would be perfect due to no >> CGNAT and infinitesimal levels of background scanning. >> >> Unfortunately Telenor has decided to deploy a central firewall that >> drops all inbound connections, making their service totally unusable >> for our use case. I guess they don't want our money. > > Sounds like the console server will need to "phone home". That a workaround might be possible doesn't make a firewall which the user cannot control to some degree less annoying. Though it might be that Telenor just needs to be notified/reminded that power users and business customers exist. Phoning home is not an option here, as the whole point is to have an OOB backdoor that works even if «home» is totally FUBAR. For that reason it needs to be completely independent of the production network. Standard Internet connections are perfect, IFF they are bi-directional. Tore From tonycane at iinet.net.au Sat Apr 13 03:21:49 2019 From: tonycane at iinet.net.au (Tony C) Date: Sat, 13 Apr 2019 13:21:49 +1000 Subject: Sflow billing or usage calculation software Message-ID: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> Hi All I am looking for Sflow analytical software that can tell me automatically over say a period of 24 hours (or any time period I select) the average mbit of data consumed for any IP address within our entire AS. (Without configuring a rule or billing group for each IP address or customer within our network) The purpose is to help quickly work out IP addressees which are using more bandwidth (in or out) than what we consider to be acceptable usage. For example, I would like to review a report or be automatically alerted to any IP address using more than an average of 50mbit within the past 24 hour plus have the capability to review data say over a month. Any names of software of suggestions would be great which I can investigate, happy to look at both commercial software and open source or if you have a Sflow billing solution for data consumption which is simple and easy to use please let me know Thanks Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From sneddon at gmail.com Sat Apr 13 07:58:51 2019 From: sneddon at gmail.com (sneddon at gmail.com) Date: Sat, 13 Apr 2019 00:58:51 -0700 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: Perhaps they are looking to build a hybrid solution? That’s what I would do. According to open job positions at BAMTech, they are looking for engineers to drive “on-premise, cloud, and third party distribution solutions. Working with the latest in streaming video, web serving and caching technologies.” There is also a CDN DevOps position open. https://jobs.disneycareers.com/job/new-york/senior-software-engineer-cdn/391/10490558 -Dan Sneddon > On Apr 12, 2019, at 12:34 PM, Tom Beecher wrote: > > I wouldn't expect them to build out anything until they got some usage data to determine the build/buy economics. > >> On Fri, Apr 12, 2019 at 3:02 PM Jared Geiger wrote: >> An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO are built on. The bits from the first two come from Akamai and Level3 CDNs. I haven't looked into where HBO Go comes from. >> >>> On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: >>> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? >>> >>> >>> >>> disneyplus.com >>> >>> >>> >>> -Aaron >>> >>> >>> >>> >>> >>> >>> >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Graves >>> Sent: Saturday, December 29, 2018 7:22 PM >>> To: nanog at nanog.org >>> Subject: Disney+ CDN >>> >>> >>> >>> Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. >>> >>> >>> >>> AG -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlrodriguez at gmail.com Sat Apr 13 14:20:46 2019 From: jlrodriguez at gmail.com (Jose Luis Rodriguez) Date: Sat, 13 Apr 2019 09:20:46 -0500 Subject: Disney+ CDN Message-ID: <89E604EC-DEDB-4081-A993-31AD10CC9A72@gmail.com> AFAIK, HBO now/go is running on the newer Broadpeak gear+umbrella (Paseo)... at least for LatAm. > Message: 2 > Date: Fri, 12 Apr 2019 12:01:33 -0700 > From: Jared Geiger > To: NANOG > Subject: Re: Disney+ CDN > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO > are built on. The bits from the first two come from Akamai and Level3 CDNs. > I haven't looked into where HBO Go comes from. > >> On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: >> >> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, >> Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? >> >> >> >> disneyplus.com >> >> >> >> -Aaron >> >> >> >> >> >> >> >> *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron Graves >> *Sent:* Saturday, December 29, 2018 7:22 PM >> *To:* nanog at nanog.org >> *Subject:* Disney+ CDN >> >> >> >> Anyone know what Disney is planning on doing for streaming content >> distribution once they leave Netflix? Would be nice if they'd provide an >> on-prem cache server. >> >> >> >> AG >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Fri, 12 Apr 2019 12:03:10 -0700 (PDT) > From: Mark Milhollan > To: NANOG list > Subject: Re: Gi Firewall for mobile subscribers > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > >> On Thu, 11 Apr 2019, Tore Anderson wrote: >> >> We've been wanting to replace our all of our ad-hoc OOB links with a >> standardised setup based on LTE connectivity to an embedded >> login/console server at each PoP. IPv6 would be perfect due to no >> CGNAT and infinitesimal levels of background scanning. >> >> Unfortunately Telenor has decided to deploy a central firewall that >> drops all inbound connections, making their service totally unusable >> for our use case. I guess they don't want our money. > > Sounds like the console server will need to "phone home". That a > workaround might be possible doesn't make a firewall which the user > cannot control to some degree less annoying. Though it might be that > Telenor just needs to be notified/reminded that power users and business > customers exist. > > > /mark > > > ------------------------------ > > Message: 4 > Date: Fri, 12 Apr 2019 15:31:24 -0400 > From: Chris Grundemann > To: Jared Geiger > Cc: NANOG > Subject: Re: Disney+ CDN > Message-ID: > > Content-Type: text/plain; charset="utf-8" > >> On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger wrote: >> >> An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO >> are built on. The bits from the first two come from Akamai and Level3 CDNs. >> I haven't looked into where HBO Go comes from. >> > > Yep, they decided to buy BAMTech and build their own: > https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > > > > >> >>> On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: >>> >>> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, >>> Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? >>> >>> >>> >>> disneyplus.com >>> >>> >>> >>> -Aaron >>> >>> >>> >>> >>> >>> >>> >>> *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron >>> Graves >>> *Sent:* Saturday, December 29, 2018 7:22 PM >>> *To:* nanog at nanog.org >>> *Subject:* Disney+ CDN >>> >>> >>> >>> Anyone know what Disney is planning on doing for streaming content >>> distribution once they leave Netflix? Would be nice if they'd provide an >>> on-prem cache server. >>> >>> >>> >>> AG >>> >> > > -- > @ChrisGrundemann > http://chrisgrundemann.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 5 > Date: Fri, 12 Apr 2019 15:34:22 -0400 > From: Tom Beecher > To: Jared Geiger > Cc: NANOG > Subject: Re: Disney+ CDN > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I wouldn't expect them to build out anything until they got some usage data > to determine the build/buy economics. > >> On Fri, Apr 12, 2019 at 3:02 PM Jared Geiger wrote: >> >> An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO >> are built on. The bits from the first two come from Akamai and Level3 CDNs. >> I haven't looked into where HBO Go comes from. >> >>> On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould wrote: >>> >>> Have we found out yet if Disney+ will have a CDN? Like Netflix oca, >>> Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? >>> >>> >>> >>> disneyplus.com >>> >>> >>> >>> -Aaron >>> >>> >>> >>> >>> >>> >>> >>> *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron >>> Graves >>> *Sent:* Saturday, December 29, 2018 7:22 PM >>> *To:* nanog at nanog.org >>> *Subject:* Disney+ CDN >>> >>> >>> >>> Anyone know what Disney is planning on doing for streaming content >>> distribution once they leave Netflix? Would be nice if they'd provide an >>> on-prem cache server. >>> >>> >>> >>> AG >>> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 6 > Date: Fri, 12 Apr 2019 14:37:54 -0500 (CDT) > From: Mike Hammett > To: Chris Grundemann > Cc: NANOG , Jared Geiger > Subject: Re: Disney+ CDN > Message-ID: > <1660830854.2724.1555097871560.JavaMail.mhammett at ThunderFuck> > Content-Type: text/plain; charset="utf-8" > > $1.6B for less than half of the company and they don't even source the bits themselves? Hrm.... > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Chris Grundemann" > To: "Jared Geiger" > Cc: "NANOG" > Sent: Friday, April 12, 2019 2:31:24 PM > Subject: Re: Disney+ CDN > > > > > > > > > > On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger < jared at compuwizz.net > wrote: > > > > An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO are built on. The bits from the first two come from Akamai and Level3 CDNs. I haven't looked into where HBO Go comes from. > > > > Yep, they decided to buy BAMTech and build their own: > https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > > > >
> > > > On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould < aaron1 at gvtc.com > wrote: > >
> > > > Have we found out yet if Disney+ will have a CDN? Like Netflix oca, Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? > > disneyplus.com > > -Aaron > > > > From: NANOG [mailto: nanog-bounces at nanog.org ] On Behalf Of Aaron Graves > Sent: Saturday, December 29, 2018 7:22 PM > To: nanog at nanog.org > Subject: Disney+ CDN > > > Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. > > > > AG >
> >
> > > > -- > > @ChrisGrundemann > http://chrisgrundemann.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 7 > Date: Fri, 12 Apr 2019 19:42:30 +0000 > From: Luke Guillory > To: Mike Hammett , Chris Grundemann > > Cc: Jared Geiger , NANOG > Subject: RE: Disney+ CDN > Message-ID: > <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD35C72 at RTC-EXCH01.RESERVE.LDS> > Content-Type: text/plain; charset="utf-8" > > They owned 33% and bought another 42% making it an even 75%. > > > > > Luke > > > ns > > > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett > Sent: Friday, April 12, 2019 2:38 PM > To: Chris Grundemann > Cc: Jared Geiger; NANOG > Subject: Re: Disney+ CDN > > $1.6B for less than half of the company and they don't even source the bits themselves? Hrm.... > > > ----- > Mike Hammett > Intelligent Computing Solutions > [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] > Midwest Internet Exchange > [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] > The Brothers WISP > [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png] > ________________________________ > From: "Chris Grundemann" > > To: "Jared Geiger" > > Cc: "NANOG" > > Sent: Friday, April 12, 2019 2:31:24 PM > Subject: Re: Disney+ CDN > > > > On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger > wrote: > An article mentioned BAMTech's platform which is what NHL, MLB, and HBO GO are built on. The bits from the first two come from Akamai and Level3 CDNs. I haven't looked into where HBO Go comes from. > > Yep, they decided to buy BAMTech and build their own: > https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > > > > On Thu, Apr 11, 2019 at 9:58 PM Aaron Gould > wrote: > Have we found out yet if Disney+ will have a CDN? Like Netflix oca, Akamai aanp, google ggc, facebook fna … a Disney isp-located cdn presence ? > > disneyplus.com > > -Aaron > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Graves > Sent: Saturday, December 29, 2018 7:22 PM > To: nanog at nanog.org > Subject: Disney+ CDN > > Anyone know what Disney is planning on doing for streaming content distribution once they leave Netflix? Would be nice if they'd provide an on-prem cache server. > > AG > > > -- > @ChrisGrundemann > http://chrisgrundemann.com > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Fri, 12 Apr 2019 13:23:29 -0700 > From: "Scott Weeks" > To: > Subject: Re: Disney+ CDN > Message-ID: <20190412132329.40399BD at m0117459.ppops.net> > Content-Type: text/plain; charset="UTF-8" > > > > --- cgrundemann at gmail.com wrote: > From: Chris Grundemann > > Yep, they decided to buy BAMTech and build their own: > https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > ---------------------------------------------------- > > > https://www.bamtechmedia.com/company > > 2004 - "Patent awarded for GeoLocation" > > I'd be interested in learning about how well that one works! > > scott > > > ------------------------------ > > Message: 9 > Date: Fri, 12 Apr 2019 19:43:56 -0400 > From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" > To: surfer at mauigateway.com > Cc: nanog at nanog.org > Subject: Re: Disney+ CDN > Message-ID: <1720.1555112636 at turing-police> > Content-Type: text/plain; charset=us-ascii > > On Fri, 12 Apr 2019 13:23:29 -0700, "Scott Weeks" said: > >> 2004 - "Patent awarded for GeoLocation" >> >> I'd be interested in learning about how well that one works! > > Under US law, ideas submitted for patent need be "non-obvious". There's no > requirement they actually be a good idea. Though I guess that it should prevent > the patenting of obvious bad ideas - but $DEITY knows there's plenty of subtly > flawed concepts out there.... (And there's ample evidence that the USPTO is on > occasion challenged by the "obviousness" requirement...) > > > > ------------------------------ > > Message: 10 > Date: Sat, 13 Apr 2019 11:13:48 +0200 > From: Tore Anderson > To: Mark Milhollan , NANOG list > Subject: Re: Gi Firewall for mobile subscribers > Message-ID: <6e81e3d5-ed9b-eedc-5ec8-be782e477467 at fud.no> > Content-Type: text/plain; charset=utf-8 > > * Mark Milhollan >>> On Thu, 11 Apr 2019, Tore Anderson wrote: >>> >>> We've been wanting to replace our all of our ad-hoc OOB links with a >>> standardised setup based on LTE connectivity to an embedded >>> login/console server at each PoP. IPv6 would be perfect due to no >>> CGNAT and infinitesimal levels of background scanning. >>> >>> Unfortunately Telenor has decided to deploy a central firewall that >>> drops all inbound connections, making their service totally unusable >>> for our use case. I guess they don't want our money. >> >> Sounds like the console server will need to "phone home". That a workaround might be possible doesn't make a firewall which the user cannot control to some degree less annoying. Though it might be that Telenor just needs to be notified/reminded that power users and business customers exist. > > Phoning home is not an option here, as the whole point is to have an OOB backdoor that works even if «home» is totally FUBAR. > > For that reason it needs to be completely independent of the production network. Standard Internet connections are perfect, IFF they are bi-directional. > > Tore > > > End of NANOG Digest, Vol 135, Issue 13 > ************************************** From Ryan.Hamel at quadranet.com Sat Apr 13 21:32:07 2019 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Sat, 13 Apr 2019 21:32:07 +0000 Subject: Sflow billing or usage calculation software In-Reply-To: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> Message-ID: Tony, Take a look at pmacct, it will be able to handle your needs with a number of modifications. The section I linked below should give you a good starting point. Change the traffic dump to a MySQL database, add some indexes, craft some SQL queries, then you're off to the races. As for billing notifications, a cron script would need to calculate the usages, and alert based on your set thresholds. http://wiki.pmacct.net/OfficialExamples - XVII. Using pmacct as traffic/event logger For added bonus points, combine it with a BGP feed, and know where your traffic is going outbound, that way intelligent routing changes can be made much quicker. -- Ryan Hamel Network Administrator ryan.hamel at quadranet.com | +1 (888) 578-2372 QuadraNet Enterprises, LLC. | Dedicated Servers, Colocation, Cloud From: NANOG On Behalf Of Tony C Sent: Friday, April 12, 2019 8:22 PM To: nanog at nanog.org Subject: Sflow billing or usage calculation software Hi All I am looking for Sflow analytical software that can tell me automatically over say a period of 24 hours (or any time period I select) the average mbit of data consumed for any IP address within our entire AS. (Without configuring a rule or billing group for each IP address or customer within our network) The purpose is to help quickly work out IP addressees which are using more bandwidth (in or out) than what we consider to be acceptable usage. For example, I would like to review a report or be automatically alerted to any IP address using more than an average of 50mbit within the past 24 hour plus have the capability to review data say over a month. Any names of software of suggestions would be great which I can investigate, happy to look at both commercial software and open source or if you have a Sflow billing solution for data consumption which is simple and easy to use please let me know Thanks Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.phaal at gmail.com Sat Apr 13 21:55:20 2019 From: peter.phaal at gmail.com (Peter Phaal) Date: Sat, 13 Apr 2019 14:55:20 -0700 Subject: Sflow billing or usage calculation software In-Reply-To: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> Message-ID: Tony, You might find the following article useful in identifying features to consider when evaluating sFlow analyzers: https://blog.sflow.com/2009/05/choosing-sflow-analyzer.html The following white paper discusses accuracy of packet sampling for usage accounting: https://inmon.com/pdf/sFlowBilling.pdf Peter On Sat, Apr 13, 2019 at 2:07 PM Tony C wrote: > Hi All > > I am looking for Sflow analytical software that can tell me automatically > over say a period of 24 hours (or any time period I select) the average > mbit of data consumed for any IP address within our entire AS. > > (Without configuring a rule or billing group for each IP address or > customer within our network) > > The purpose is to help quickly work out IP addressees which are using more > bandwidth (in or out) than what we consider to be acceptable usage. > > For example, I would like to review a report or be automatically alerted > to any IP address using more than an average of 50mbit within the past 24 > hour plus have the capability to review data say over a month. > > Any names of software of suggestions would be great which I can > investigate, happy to look at both commercial software and open source or > if you have a Sflow billing solution for data consumption which is simple > and easy to use please let me know > > Thanks > > Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Sat Apr 13 23:24:19 2019 From: beecher at beecher.cc (Tom Beecher) Date: Sat, 13 Apr 2019 19:24:19 -0400 Subject: Sflow billing or usage calculation software In-Reply-To: References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> Message-ID: I’m curious what the service is that 50Mbps avg over a 24 hr window is an investigative threshold. On Sat, Apr 13, 2019 at 17:57 Peter Phaal wrote: > Tony, > > You might find the following article useful in identifying features to > consider when evaluating sFlow analyzers: > https://blog.sflow.com/2009/05/choosing-sflow-analyzer.html > > The following white paper discusses accuracy of packet sampling for usage > accounting: > https://inmon.com/pdf/sFlowBilling.pdf > > > Peter > > > > On Sat, Apr 13, 2019 at 2:07 PM Tony C wrote: > >> Hi All >> >> I am looking for Sflow analytical software that can tell me automatically >> over say a period of 24 hours (or any time period I select) the average >> mbit of data consumed for any IP address within our entire AS. >> >> (Without configuring a rule or billing group for each IP address or >> customer within our network) >> >> The purpose is to help quickly work out IP addressees which are using >> more bandwidth (in or out) than what we consider to be acceptable usage. >> >> For example, I would like to review a report or be automatically alerted >> to any IP address using more than an average of 50mbit within the past 24 >> hour plus have the capability to review data say over a month. >> >> Any names of software of suggestions would be great which I can >> investigate, happy to look at both commercial software and open source or >> if you have a Sflow billing solution for data consumption which is simple >> and easy to use please let me know >> >> Thanks >> >> Tony >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at peterson.org Sun Apr 14 03:50:10 2019 From: matt at peterson.org (Matt Peterson) Date: Sat, 13 Apr 2019 20:50:10 -0700 Subject: SNMP via proxy In-Reply-To: References: Message-ID: We've had good luck with snmpfwd for this sort of setup. --Matt On Wed, Apr 10, 2019 at 7:12 AM Dovid Bender wrote: > Hi, > > A bit off topic. One of my early mistakes in my 9-5 was hard coding the > IP's of our SNMP box in all of our gear (networking equipment, Servers > etc,). The box is at its limit and increasing its capacity will be > nearly impossible. We mainly use Nagios and Cacti to monitor our network. > Going forward I was thinking of setting up a few hosts whose job would be > to simply relay SNMP traffic. This way moving forward we could hard code > several IP's and bounce all traffic through one of these IP's. > > TIA for your advice. > > Regards, > > Dovid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonycane at iinet.net.au Sun Apr 14 11:28:28 2019 From: tonycane at iinet.net.au (Tony C) Date: Sun, 14 Apr 2019 21:28:28 +1000 Subject: Sflow billing or usage calculation software In-Reply-To: References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> Message-ID: <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> Hi Tom The 50Mbps is just an example, it’s the function we are more after. The pmacct option looks interesting I wonder if this can be integrated with IPAM I also found the UTM5 ISP Billing System which looks interesting anyone using it ? or not using it for specific reasons ? Please keep the suggestions coming. Tony From: Tom Beecher [mailto:beecher at beecher.cc] Sent: Sunday, April 14, 2019 9:24 AM To: Peter Phaal Cc: Tony C ; nanog Subject: Re: Sflow billing or usage calculation software I’m curious what the service is that 50Mbps avg over a 24 hr window is an investigative threshold. On Sat, Apr 13, 2019 at 17:57 Peter Phaal > wrote: Tony, You might find the following article useful in identifying features to consider when evaluating sFlow analyzers: https://blog.sflow.com/2009/05/choosing-sflow-analyzer.html The following white paper discusses accuracy of packet sampling for usage accounting: https://inmon.com/pdf/sFlowBilling.pdf Peter On Sat, Apr 13, 2019 at 2:07 PM Tony C > wrote: Hi All I am looking for Sflow analytical software that can tell me automatically over say a period of 24 hours (or any time period I select) the average mbit of data consumed for any IP address within our entire AS. (Without configuring a rule or billing group for each IP address or customer within our network) The purpose is to help quickly work out IP addressees which are using more bandwidth (in or out) than what we consider to be acceptable usage. For example, I would like to review a report or be automatically alerted to any IP address using more than an average of 50mbit within the past 24 hour plus have the capability to review data say over a month. Any names of software of suggestions would be great which I can investigate, happy to look at both commercial software and open source or if you have a Sflow billing solution for data consumption which is simple and easy to use please let me know Thanks Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From aveline at misaka.io Sun Apr 14 11:30:04 2019 From: aveline at misaka.io (Siyuan Miao) Date: Sun, 14 Apr 2019 19:30:04 +0800 Subject: Facebook outage Message-ID: Dear community, It seems that Facebook network is partially down. Here's a traceroute from some locations to fbcdn Hong Kong (157.240.15.37): Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. fra-in8-01sw.voxility.net 0.6% 181 0.5 0.6 0.4 4.9 0.5 3. fra-in8-01c.voxility.net 0.0% 181 14.7 3.7 0.3 44.1 8.5 4. fra-in3-02gw.voxility.net 0.0% 181 0.9 3.5 0.7 195.2 14.5 5. fra-eq5-02gw.voxility.net 0.0% 181 0.6 0.5 0.3 0.7 0.0 6. fra-eq5-03gw.voxility.net 0.0% 181 0.6 0.7 0.4 6.6 0.7 7. ae10.pr02.fra5.tfbnw.net 0.0% 181 1.2 3.5 0.8 35.0 5.2 8. ??? 9. ae121.ar03.fra2.tfbnw.net 0.0% 181 4.4 2.1 1.0 21.1 2.2 10. ae32.bb02.fra2.tfbnw.net 0.0% 181 5.1 4.6 1.4 14.0 2.7 11. ae15.bb03.odn2.tfbnw.net 0.0% 181 19.2 19.8 18.5 26.3 1.2 12. ae12.dr03.odn2.tfbnw.net 92.8% 181 27.8 24.4 18.3 43.4 8.4 13. ??? Host Loss% Snt Last Avg Best Wrst StDev 1. lax-cs1-02sw.voxility.net 0.0% 194 0.3 2.5 0.2 36.9 5.1 2. lax-cs1-01c.voxility.net 0.0% 194 6.1 2.8 0.2 47.3 6.4 3. lax-cs1-02gw.voxility.net 0.0% 194 0.2 0.1 0.1 0.3 0.0 4. ce-0-13-0-1.r00.lsanca07.us.bb.gin.ntt.net 0.0% 194 0.9 0.5 0.4 1.0 0.0 5. ae-3.r01.lsanca07.us.bb.gin.ntt.net 0.0% 194 0.5 0.5 0.4 0.9 0.0 6. ae-0.tata-communications.lsanca07.us.bb.gin.ntt.net 0.0% 194 0.7 1.0 0.4 28.8 2.8 7. if-et-20-2.hcore2.kv8-chiba.as6453.net 0.0% 194 158.6 158.8 158.4 175.5 1.8 8. if-et-1-2.hcore1.kv8-chiba.as6453.net 0.0% 194 152.7 152.8 152.5 155.8 0.2 9. if-ae-16-2.tcore1.hk2-hong-kong.as6453.net 0.0% 194 162.1 163.0 162.0 213.5 4.9 10. ??? What do you think ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Sun Apr 14 11:41:53 2019 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 14 Apr 2019 07:41:53 -0400 Subject: Facebook outage In-Reply-To: References: Message-ID: It's all over Twitter. DB, What's app and Instagram are all having issues. On Sun, Apr 14, 2019, 07:32 Siyuan Miao wrote: > Dear community, > > It seems that Facebook network is partially down. > > Here's a traceroute from some locations to fbcdn Hong Kong (157.240.15.37): > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. ??? > 2. fra-in8-01sw.voxility.net > 0.6% 181 0.5 0.6 0.4 4.9 0.5 > 3. fra-in8-01c.voxility.net > 0.0% 181 14.7 3.7 0.3 44.1 8.5 > 4. fra-in3-02gw.voxility.net > 0.0% 181 0.9 3.5 0.7 195.2 14.5 > 5. fra-eq5-02gw.voxility.net > 0.0% 181 0.6 0.5 0.3 0.7 0.0 > 6. fra-eq5-03gw.voxility.net > 0.0% 181 0.6 0.7 0.4 6.6 0.7 > 7. ae10.pr02.fra5.tfbnw.net > 0.0% 181 1.2 3.5 0.8 35.0 5.2 > 8. ??? > 9. ae121.ar03.fra2.tfbnw.net > 0.0% 181 4.4 2.1 1.0 21.1 2.2 > 10. ae32.bb02.fra2.tfbnw.net > 0.0% 181 5.1 4.6 1.4 14.0 2.7 > 11. ae15.bb03.odn2.tfbnw.net > 0.0% 181 19.2 19.8 18.5 26.3 1.2 > 12. ae12.dr03.odn2.tfbnw.net > 92.8% 181 27.8 24.4 18.3 43.4 8.4 > 13. ??? > > Host > Loss% Snt Last Avg Best Wrst StDev > 1. lax-cs1-02sw.voxility.net > 0.0% 194 0.3 2.5 0.2 36.9 5.1 > 2. lax-cs1-01c.voxility.net > 0.0% 194 6.1 2.8 0.2 47.3 6.4 > 3. lax-cs1-02gw.voxility.net > 0.0% 194 0.2 0.1 0.1 0.3 0.0 > 4. ce-0-13-0-1.r00.lsanca07.us.bb.gin.ntt.net > 0.0% 194 0.9 0.5 0.4 1.0 0.0 > 5. ae-3.r01.lsanca07.us.bb.gin.ntt.net > 0.0% 194 0.5 0.5 0.4 0.9 0.0 > 6. ae-0.tata-communications.lsanca07.us.bb.gin.ntt.net > 0.0% 194 0.7 1.0 0.4 28.8 2.8 > 7. if-et-20-2.hcore2.kv8-chiba.as6453.net > 0.0% 194 158.6 158.8 158.4 175.5 1.8 > 8. if-et-1-2.hcore1.kv8-chiba.as6453.net > 0.0% 194 152.7 152.8 152.5 155.8 0.2 > 9. if-ae-16-2.tcore1.hk2-hong-kong.as6453.net > 0.0% 194 162.1 163.0 162.0 213.5 4.9 > 10. ??? > > What do you think ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Sun Apr 14 11:48:48 2019 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 14 Apr 2019 07:48:48 -0400 Subject: Facebook outage In-Reply-To: References: Message-ID: That should have read FB not DB. On Sun, Apr 14, 2019, 07:41 Dovid Bender wrote: > It's all over Twitter. DB, What's app and Instagram are all having issues. > > On Sun, Apr 14, 2019, 07:32 Siyuan Miao wrote: > >> Dear community, >> >> It seems that Facebook network is partially down. >> >> Here's a traceroute from some locations to fbcdn Hong Kong >> (157.240.15.37): >> >> Host >> Loss% Snt Last Avg Best Wrst StDev >> 1. ??? >> 2. fra-in8-01sw.voxility.net >> 0.6% 181 0.5 0.6 0.4 4.9 0.5 >> 3. fra-in8-01c.voxility.net >> 0.0% 181 14.7 3.7 0.3 44.1 8.5 >> 4. fra-in3-02gw.voxility.net >> 0.0% 181 0.9 3.5 0.7 195.2 14.5 >> 5. fra-eq5-02gw.voxility.net >> 0.0% 181 0.6 0.5 0.3 0.7 0.0 >> 6. fra-eq5-03gw.voxility.net >> 0.0% 181 0.6 0.7 0.4 6.6 0.7 >> 7. ae10.pr02.fra5.tfbnw.net >> 0.0% 181 1.2 3.5 0.8 35.0 5.2 >> 8. ??? >> 9. ae121.ar03.fra2.tfbnw.net >> 0.0% 181 4.4 2.1 1.0 21.1 2.2 >> 10. ae32.bb02.fra2.tfbnw.net >> 0.0% 181 5.1 4.6 1.4 14.0 2.7 >> 11. ae15.bb03.odn2.tfbnw.net >> 0.0% 181 19.2 19.8 18.5 26.3 1.2 >> 12. ae12.dr03.odn2.tfbnw.net >> 92.8% 181 27.8 24.4 18.3 43.4 8.4 >> 13. ??? >> >> Host >> Loss% Snt Last Avg Best Wrst StDev >> 1. lax-cs1-02sw.voxility.net >> 0.0% 194 0.3 2.5 0.2 36.9 5.1 >> 2. lax-cs1-01c.voxility.net >> 0.0% 194 6.1 2.8 0.2 47.3 6.4 >> 3. lax-cs1-02gw.voxility.net >> 0.0% 194 0.2 0.1 0.1 0.3 0.0 >> 4. ce-0-13-0-1.r00.lsanca07.us.bb.gin.ntt.net >> 0.0% 194 0.9 0.5 0.4 1.0 0.0 >> 5. ae-3.r01.lsanca07.us.bb.gin.ntt.net >> 0.0% 194 0.5 0.5 0.4 0.9 0.0 >> 6. ae-0.tata-communications.lsanca07.us.bb.gin.ntt.net >> 0.0% 194 0.7 1.0 0.4 28.8 2.8 >> 7. if-et-20-2.hcore2.kv8-chiba.as6453.net >> 0.0% 194 158.6 158.8 158.4 175.5 1.8 >> 8. if-et-1-2.hcore1.kv8-chiba.as6453.net >> 0.0% 194 152.7 152.8 152.5 155.8 0.2 >> 9. if-ae-16-2.tcore1.hk2-hong-kong.as6453.net >> 0.0% 194 162.1 163.0 162.0 213.5 4.9 >> 10. ??? >> >> What do you think ? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at nanocat.net Sun Apr 14 12:09:24 2019 From: nick at nanocat.net (Nick Morrison) Date: Sun, 14 Apr 2019 14:09:24 +0200 Subject: Sflow billing or usage calculation software In-Reply-To: <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> Message-ID: On 14. Apr 2019, at 13:28, Tony C wrote: > > Please keep the suggestions coming. I’ve had good results using Traffic Sentinel from Inmon. It’s got a nice queriable database backend and you don’t have to do much manual setup to get good results. The UI feels a bit 1995, but it works, and the API is practical and useful. It’s quite fast, too. They can probably give you trial licenses to see if it works for you. Nick From jayfar at jayfar.com Sun Apr 14 12:20:23 2019 From: jayfar at jayfar.com (Jay Farrell) Date: Sun, 14 Apr 2019 08:20:23 -0400 Subject: Facebook outage In-Reply-To: References: Message-ID: On Sun, Apr 14, 2019 at 7:33 AM Siyuan Miao wrote: > Dear community, > > It seems that Facebook network is partially down. > I wouldn't say partially. And just a month and a day since their 10+ hour record-breaking outage. Of course FB will downplay it in their eventual RFO as "some users" had difficulty connecting. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak at ai.net Mon Apr 15 22:21:33 2019 From: deepak at ai.net (Deepak Jain) Date: Mon, 15 Apr 2019 22:21:33 +0000 Subject: Sflow billing or usage calculation software In-Reply-To: References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> Message-ID: <84383daa120f462ebed4bf5051d8de76@AiNET-EX13-S01.ainet.local> (I'm out of practice with mailing lists, apologies in advance).... Dove tailing on this request... not sure its worth another thread. Is there a good Sflow-way or Sflow+something way to link all the traffic flow from a physical port for this kind (or any kind) of inspection? One way would be to suck down all the IP configs (and learned addresses ala BGP) and perform complex analysis of the Sflow database. I'm hoping there is something more intuitive... so you could say port 5 on switch xxx has this % TCP traffic vs this % UDP traffic (for example). I'm only aware of Sflow being IP/protocol/etc aware. thanks in advance, Deepak -----Original Message----- From: NANOG [mailto:nanog-bounces+deepak=ai.net at nanog.org] On Behalf Of Nick Morrison Sent: Sunday, April 14, 2019 8:09 AM To: Tony C Cc: nanog Subject: Re: Sflow billing or usage calculation software On 14. Apr 2019, at 13:28, Tony C wrote: > > Please keep the suggestions coming. I’ve had good results using Traffic Sentinel from Inmon. It’s got a nice queriable database backend and you don’t have to do much manual setup to get good results. The UI feels a bit 1995, but it works, and the API is practical and useful. It’s quite fast, too. They can probably give you trial licenses to see if it works for you. Nick From nick at nanocat.net Tue Apr 16 09:12:47 2019 From: nick at nanocat.net (Nick Morrison) Date: Tue, 16 Apr 2019 11:12:47 +0200 Subject: Sflow billing or usage calculation software In-Reply-To: <84383daa120f462ebed4bf5051d8de76@AiNET-EX13-S01.ainet.local> References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> <84383daa120f462ebed4bf5051d8de76@AiNET-EX13-S01.ainet.local> Message-ID: > On 16. Apr 2019, at 00:21, Deepak Jain wrote: > > I'm only aware of Sflow being IP/protocol/etc aware. Actually the sflow standard is flexible, and there are many fields widely available, including input interface and output interface, vlan/vxlan/mpls headers, etc. The sending device just needs to support the fields. To give you an idea of some of the fields you can query from a TS server for example, here’s a description of one of the tables in the database: https://inmon.com/sentinel_help/8.0/help/en/report/api_view_traffic.shtml Browse sflow.org for more fun info, including ideas for running sflow agents on your hypervisors (for eg correlating CPU and RAM usage per VM) etc :-) Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From yang.yu.list at gmail.com Tue Apr 16 10:30:17 2019 From: yang.yu.list at gmail.com (Yang Yu) Date: Tue, 16 Apr 2019 03:30:17 -0700 Subject: Sflow billing or usage calculation software In-Reply-To: References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> <84383daa120f462ebed4bf5051d8de76@AiNET-EX13-S01.ainet.local> Message-ID: >On Tue, Apr 16, 2019 at 2:14 AM Nick Morrison wrote: > > Actually the sflow standard is flexible, and there are many fields widely available, including input interface and output interface, vlan/vxlan/mpls headers, etc. The sending device just needs to support the fields. Vendor support for sFlow extended data types seems to be very limited and there are quite a few caveats on when the data is missing/inaccurate. RFC5472 Section 4.2 Using IPFIX for Billing (Reliability Limitations) might be applicable to sFlow as well. https://tools.ietf.org/html/rfc5472#section-4.2 Yang From mark.tinka at seacom.mu Tue Apr 16 07:56:07 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Apr 2019 09:56:07 +0200 Subject: Fwd: [safnog] SAFNOG-5 and iWeek 2019 In-Reply-To: References: Message-ID: FYI. Mark. -------- Forwarded Message -------- Subject: [safnog-mc] SAFNOG-5 and iWeek 2019 Date: Thu, 11 Apr 2019 14:59:24 +0000 From: Portia Rabonda - FLEXOPTIX To: safnog-mc , safnog at safnog.org SAFNOG-5 and iWeek 2019     SAFNOG-5 & iWeek 2019 www.safnog.org       https://gallery.mailchimp.com/88792d6999cc80b3de7b079b8/images/1fc94a4f-c2fc-4ed3-99a6-4261679bf7dd.png       We are proud to announce that for the 5th instalment of SAFNOG, we will be returning to Johannesburg, South Africa where it all began. SAFNOG and iWeek will be teaming up again this year to bring you SAFNOG-5 and the 2019 edition of iWeek in Johannesburg, South Africa. The meeting will be held on 26-28 August 2019 at the Indaba Hotel, in Fourways,  Johannesburg, South Africa.  For more details and updates on the event, visit our website www.safnog.org  and www.iweek.org.za       *Find Out More* https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-facebook-48.png https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-twitter-48.png https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-instagram-48.png https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-link-48.png https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-linkedin-48.png https://cdn-images.mailchimp.com/icons/social-block-v2/outline-light-youtube-48.png     /Copyright © /SAFNOG ORG 2019/, All rights reserved./ *Our mailing address is:* safnog at safnog.org Want to change how you receive these emails? You can update your preferences or unsubscribe from this list .   https://gmail.us20.list-manage.com/track/open.php?u=88792d6999cc80b3de7b079b8&id=be6ce54966&e=7ffa6a58f8 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ safnog-mc mailing list safnog-mc at safnog.org http://lists.safnog.org/listinfo/safnog-mc From pzhu011 at ucr.edu Tue Apr 16 04:36:45 2019 From: pzhu011 at ucr.edu (Pengxiong Zhu) Date: Mon, 15 Apr 2019 21:36:45 -0700 Subject: Ownership of Routers on Both Ends of Transnational Links Message-ID: Howdy folks, We are a group of researchers at UC Riverside conducting some measurement about transnational networks. In particular, we are interested in studying the ownership of routers on the two sides of transnational links. We have some concrete questions which we hope someone can shed some light on. Basically when we send packets from US/Canada to China, through traceroute and the RTT of each hop, we can locate the last hop in the US before the packets enter China (*there is a large jump of RTT of 100+ms from this hop onwards*). Oftentimes the ownership of such routers is ambiguous. These hops whose IPs seem to belong to US or European ISPs (*according to BGP info*) but their reverse DNS names have *chinaunicom* in it, which is a Chinese ISP. AS1299 Telia Company AB 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. AS701 Verizon Business 152.179.103.254 name = chinaunicom-gw.customer.alter.net. While the following routers, they don't have a reverse DNS name at all, which seem to be uncommon if they were managed by US or European ISPs but quite common for Chinese ISPs. AS6453 TATA COMMUNICATIONS (AMERICA) INC 63.243.205.90 66.110.59.118 Can anyone confirm that these are indeed managed by the Chinese ISPs (even though they are physically located in the US according to the traceroute and RTT analysis)? Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Apr 16 12:52:23 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Apr 2019 14:52:23 +0200 Subject: SAFNOG-5 & iWeek 2019 Message-ID: Hello all. We are proud to announce that for the 5th installment of SAFNOG, we will be returning to Johannesburg, South Africa where it all began. SAFNOG and iWeek will be teaming up again this year to bring you SAFNOG-5 and the 2019 edition of iWeek in Johannesburg, South Africa. The meeting will be held on 26-28 August 2019 at the Indaba Hotel, in Fourways, Johannesburg, South Africa. More details about the meeting will be posted to our web site in the coming weeks:     http://www.safnog.org/ We look forward to seeing you in Johannesburg. Thanks. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Apr 16 13:13:30 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 16 Apr 2019 09:13:30 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: "company-ic" and "company-gw" are commonly used names for /30s used for interconnection to a customer or another carrier. Those routers are likely owned/managed by Telia/Verizon. On Tue, Apr 16, 2019 at 8:54 AM Pengxiong Zhu wrote: > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.jun at towardex.com Tue Apr 16 14:58:39 2019 From: james.jun at towardex.com (James Jun) Date: Tue, 16 Apr 2019 10:58:39 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: <20190416145839.GA31629@mis10.towardex.com> On Tue, Apr 16, 2019 at 09:13:30AM -0400, Ross Tajvar wrote: > "company-ic" and "company-gw" are commonly used names for /30s used for > interconnection to a customer or another carrier. Those routers are likely > owned/managed by Telia/Verizon. > I highly doubt VZ or Telia owns and provides a Big Expensive Router as CPE sitting on US landing POP for a major international carrier. More likely, thease routers are China Unicom's routers in their US POP, not managed by VZ/Telia. The /30s in this case are unmanaged IP transit hand-offs, coming in as Nx10G or 100G. When your IP transit provider assigns the /30, your router looks like it belongs to your upstream, common mistake when interpreting traceroutes[1]. [1]: see Page 22 on https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf James From morrowc.lists at gmail.com Tue Apr 16 19:47:10 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Apr 2019 15:47:10 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: <20190416145839.GA31629@mis10.towardex.com> References: <20190416145839.GA31629@mis10.towardex.com> Message-ID: On Tue, Apr 16, 2019 at 10:59 AM James Jun wrote: > More likely, thease routers are China Unicom's routers in their US POP, not managed by VZ/Telia. > The /30s in this case are unmanaged IP transit hand-offs, coming in as Nx10G or 100G. When your > IP transit provider assigns the /30, your router looks like it belongs to your upstream, common > mistake when interpreting traceroutes[1]. > $ nslookup 62.115.170.56 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net. if you model (as james says) each interconnect as a /30 or /31 ... look for the adjacent ip and see the PTR for that ip. (the above is your first link example's peer ip) > [1]: see Page 22 on https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf > > James From ross at tajvar.io Tue Apr 16 20:50:11 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 16 Apr 2019 16:50:11 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: <20190416145839.GA31629@mis10.towardex.com> Message-ID: I think it's clear that the IPs belong to Telia, but I understood James's point to be that the router using the IP in question may belong to China Unicom. (I agree with that, I was not thinking clearly this morning.) As this is an interconnect link, one side must belong to Telia and the other to China Unicom. The question, then, is which side are we looking at? Well, first I want to know how big the subnet is. I assume either /30 or /31. So, I do a reverse DNS lookup on all the IPs in the surrounding /30 block: 62.115.170.56 - sjo-b21-link.telia.net 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net 62.115.170.58 - las-b24-link.telia.net 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net That looks like two /31s. Only one IP in each has the name of China Unicom in it, so that one is probably in use by China Unicom, and the other is probably in use by Telia. On Tue, Apr 16, 2019, 3:50 PM Christopher Morrow wrote: > On Tue, Apr 16, 2019 at 10:59 AM James Jun wrote: > > > More likely, thease routers are China Unicom's routers in their US POP, > not managed by VZ/Telia. > > The /30s in this case are unmanaged IP transit hand-offs, coming in as > Nx10G or 100G. When your > > IP transit provider assigns the /30, your router looks like it belongs > to your upstream, common > > mistake when interpreting traceroutes[1]. > > > > $ nslookup 62.115.170.56 > 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net. > > if you model (as james says) each interconnect as a /30 or /31 ... > look for the adjacent ip and see the PTR for that ip. > (the above is your first link example's peer ip) > > > [1]: see Page 22 on > https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf > > > > James > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Tue Apr 16 21:34:16 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Apr 2019 17:34:16 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: <20190416145839.GA31629@mis10.towardex.com> Message-ID: On Tue, Apr 16, 2019 at 5:19 PM Nimrod Levy wrote: > > > > On Tue, Apr 16, 2019, 16:52 Ross Tajvar wrote: >> >> I think it's clear that the IPs belong to Telia, but I understood James's point to be that the router using the IP in question may belong to China Unicom. (I agree with that, I was not thinking clearly this morning.) As this is an interconnect link, one side must belong to Telia and the other to China Unicom. The question, then, is which side are we looking at? Well, first I want to know how big the subnet is. I assume either /30 or /31. So, I do a reverse DNS lookup on all the IPs in the surrounding /30 block: >> 62.115.170.56 - sjo-b21-link.telia.net >> 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net >> 62.115.170.58 - las-b24-link.telia.net >> 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net >> That looks like two /31s. Only one IP in each has the name of China Unicom in it, so that one is probably in use by China Unicom, and the other is probably in use by Telia. > that was my point yes. > I think we're making a lot of assumptions about how well PTR records are maintained. All of this could be totally accurate. Or...not... this is totally true :) but... if the next hop after chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better than average chance that the chinaunicom-ic-341501-sjo-b21.c.telia.net address is a telia /30 (or /31) on the ptp link between CU/Telia. That Telia owns the ip space and that PROBABLY the customer identification is correct. (cu) -chris From pzhu011 at ucr.edu Tue Apr 16 21:48:53 2019 From: pzhu011 at ucr.edu (Pengxiong Zhu) Date: Tue, 16 Apr 2019 14:48:53 -0700 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: <20190416145839.GA31629@mis10.towardex.com> Message-ID: Thank you so much for your insightful replies. We are asking the right people! I checked the rest of them, they all seem to be /30 or /31s. 62.115.33.227 jax-b1-link.telia.net 62.115.33.228 telconet-ic-337544-jax-b1.c.telia.net 62.115.33.229 las-bb1-link.telia.net * 62.115.33.230 chinaunicom-ic-302366-las-bb1.c.telia.net 213.248.73.185 adm-b4-link.telia.net 213.248.73.186 riot-ic-303251-adm-b4.c.telia.net 213.248.73.187 213.248.73.188 213.248.73.189 sjo-b21-link.telia.net * 213.248.73.190 chinaunicom-ic-127288-sjo-b21.c.telia.net. 152.179.103.250 0.xe-1-2-1.GW7.LAX1.ALTER.NET 152.179.103.250 chinaunicom-gw.customer.alter.net 152.179.103.251 152.179.103.252 152.179.103.253 0.xe-1-0-0.gw2.lax1.alter.net * 152.179.103.254 chinaunicom-gw.customer.alter.net. 63.243.205.89 ix-xe-0-3-3-0.tcore1.sqn-san-jose.as6453.net * 63.243.205.90 63.243.205.91 63.243.205.92 63.243.205.93 ix-xe-8-2-5-0.tcore1.sqn-san-jose.as6453.net 66.110.59.117 ix-xe-2-1-3-0-0.tcore1.lvw-los-angeles.as6453.net * 66.110.59.118 66.110.59.119 66.110.59.120 66.110.59.121 ix-ae-2-611.tcore1.lvw-los-angeles.as6453.net How about the two IPs(63.243.205.90, 66.110.59.118) that don't have a reserve DNS name? Since they don't have any PTR records. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 1:50 PM Ross Tajvar wrote: > I think it's clear that the IPs belong to Telia, but I understood James's > point to be that the router using the IP in question may belong to China > Unicom. (I agree with that, I was not thinking clearly this morning.) As > this is an interconnect link, one side must belong to Telia and the other > to China Unicom. The question, then, is which side are we looking at? Well, > first I want to know how big the subnet is. I assume either /30 or /31. So, > I do a reverse DNS lookup on all the IPs in the surrounding /30 block: > 62.115.170.56 - sjo-b21-link.telia.net > 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net > 62.115.170.58 - las-b24-link.telia.net > 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net > That looks like two /31s. Only one IP in each has the name of China Unicom > in it, so that one is probably in use by China Unicom, and the other is > probably in use by Telia. > > On Tue, Apr 16, 2019, 3:50 PM Christopher Morrow > wrote: > >> On Tue, Apr 16, 2019 at 10:59 AM James Jun >> wrote: >> >> > More likely, thease routers are China Unicom's routers in their US POP, >> not managed by VZ/Telia. >> > The /30s in this case are unmanaged IP transit hand-offs, coming in as >> Nx10G or 100G. When your >> > IP transit provider assigns the /30, your router looks like it belongs >> to your upstream, common >> > mistake when interpreting traceroutes[1]. >> > >> >> $ nslookup 62.115.170.56 >> 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net. >> >> if you model (as james says) each interconnect as a /30 or /31 ... >> look for the adjacent ip and see the PTR for that ip. >> (the above is your first link example's peer ip) >> >> > [1]: see Page 22 on >> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf >> > >> > James >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pzhu011 at ucr.edu Tue Apr 16 21:57:06 2019 From: pzhu011 at ucr.edu (Pengxiong Zhu) Date: Tue, 16 Apr 2019 14:57:06 -0700 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: <20190416145839.GA31629@mis10.towardex.com> Message-ID: > > this is totally true :) but... if the next hop after > chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better > than average chance that the > chinaunicom-ic-341501-sjo-b21.c.telia.net > address is a telia /30 (or /31) on the ptp link between CU/Telia. That > Telia owns the ip space and that PROBABLY the customer identification > is correct. (cu) Yes, in our case, the next hops after all the six routers are some CU IPs. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 2:34 PM Christopher Morrow wrote: > On Tue, Apr 16, 2019 at 5:19 PM Nimrod Levy > wrote: > > > > > > > > On Tue, Apr 16, 2019, 16:52 Ross Tajvar wrote: > >> > >> I think it's clear that the IPs belong to Telia, but I understood > James's point to be that the router using the IP in question may belong to > China Unicom. (I agree with that, I was not thinking clearly this morning.) > As this is an interconnect link, one side must belong to Telia and the > other to China Unicom. The question, then, is which side are we looking at? > Well, first I want to know how big the subnet is. I assume either /30 or > /31. So, I do a reverse DNS lookup on all the IPs in the surrounding /30 > block: > >> 62.115.170.56 - sjo-b21-link.telia.net > >> 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net > >> 62.115.170.58 - las-b24-link.telia.net > >> 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net > >> That looks like two /31s. Only one IP in each has the name of China > Unicom in it, so that one is probably in use by China Unicom, and the other > is probably in use by Telia. > > > > that was my point yes. > > > I think we're making a lot of assumptions about how well PTR records are > maintained. All of this could be totally accurate. Or...not... > > this is totally true :) but... if the next hop after > chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better > than average chance that the > chinaunicom-ic-341501-sjo-b21.c.telia.net > > address is a telia /30 (or /31) on the ptp link between CU/Telia. That > Telia owns the ip space and that PROBABLY the customer identification > is correct. (cu) > > -chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Apr 16 22:26:39 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 16 Apr 2019 18:26:39 -0400 Subject: Ownership of Routers on Both Ends of Transnational Links In-Reply-To: References: Message-ID: "Can anyone confirm that these are indeed managed by the Chinese ISPs (even though they are physically located in the US according to the traceroute and RTT analysis)?" If a router is part of the CU AS, it's owed and managed by them. Physical location isn't really relevant to your question. On Tue, Apr 16, 2019 at 8:53 AM Pengxiong Zhu wrote: > Howdy folks, > > We are a group of researchers at UC Riverside conducting some measurement > about transnational networks. In particular, we are interested in studying > the ownership of routers on the two sides of transnational links. > > We have some concrete questions which we hope someone can shed some light > on. Basically when we send packets from US/Canada to China, through > traceroute and the RTT of each hop, we can locate the last hop in the US > before the packets enter China (*there is a large jump of RTT of 100+ms > from this hop onwards*). Oftentimes the ownership of such routers is > ambiguous. > > These hops whose IPs seem to belong to US or European ISPs (*according to > BGP info*) but their reverse DNS names have *chinaunicom* in it, which is > a Chinese ISP. > AS1299 Telia Company AB > 62.115.170.57 name = chinaunicom-ic-341501-sjo-b21.c.telia.net. > 62.115.33.230 name = chinaunicom-ic-302366-las-bb1.c.telia.net. > 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. > > AS701 Verizon Business > 152.179.103.254 name = chinaunicom-gw.customer.alter.net. > > While the following routers, they don't have a reverse DNS name at all, > which seem to be uncommon if they were managed by US or European ISPs but > quite common for Chinese ISPs. > AS6453 TATA COMMUNICATIONS (AMERICA) INC > 63.243.205.90 > 66.110.59.118 > > Can anyone confirm that these are indeed managed by the Chinese ISPs (even > though they are physically located in the US according to the traceroute > and RTT analysis)? > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak at ai.net Tue Apr 16 22:48:24 2019 From: deepak at ai.net (Deepak Jain) Date: Tue, 16 Apr 2019 18:48:24 -0400 Subject: Sflow billing or usage calculation software In-Reply-To: References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> <84383daa120f462ebed4bf5051d8de76@AiNET-EX13-S01.ainet.local> Message-ID: <4af97f81-c6bb-12a5-0593-bf1cd4b110b7@ai.net> Thanks for the pointers and suggestions! Now I know I'm pushing my luck... but do certain vendors more fully embrace sFlow than others? maybe one of the whitebox vendors if not one of the majors? Hacking support into something isn't the worse thing in the world, but if there is any experience on this to leverage off of, that is helpful. TIA, Deepak On 4/16/2019 6:30 AM, Yang Yu wrote: >> On Tue, Apr 16, 2019 at 2:14 AM Nick Morrison wrote: >> >> Actually the sflow standard is flexible, and there are many fields widely available, including input interface and output interface, vlan/vxlan/mpls headers, etc. The sending device just needs to support the fields. > > > Vendor support for sFlow extended data types seems to be very limited > and there are quite a few caveats on when the data is > missing/inaccurate. > > RFC5472 Section 4.2 Using IPFIX for Billing (Reliability Limitations) > might be applicable to sFlow as well. > https://tools.ietf.org/html/rfc5472#section-4.2 > > > Yang > > From peter.phaal at gmail.com Wed Apr 17 17:11:19 2019 From: peter.phaal at gmail.com (Peter Phaal) Date: Wed, 17 Apr 2019 10:11:19 -0700 Subject: Sflow billing or usage calculation software In-Reply-To: <4af97f81-c6bb-12a5-0593-bf1cd4b110b7@ai.net> References: <003701d4f1a8$084e0e80$18ea2b80$@iinet.net.au> <004801d4f2b5$2ecfa6f0$8c6ef4d0$@iinet.net.au> <84383daa120f462ebed4bf5051d8de76@AiNET-EX13-S01.ainet.local> <4af97f81-c6bb-12a5-0593-bf1cd4b110b7@ai.net> Message-ID: On Tue, Apr 16, 2019 at 8:35 PM Deepak Jain wrote: > Now I know I'm pushing my luck... but do certain vendors more fully > embrace sFlow than others? maybe one of the whitebox vendors if not one > of the majors? > > Hacking support into something isn't the worse thing in the world, but > if there is any experience on this to leverage off of, that is helpful. > Unfortunately, there isn't a publicly available list showing how well or completely vendors have implemented the sFlow specifications: https://sflow.org/developers/specifications.php I have been working on an sFlow test suite to try and address this problem: https://blog.sflow.com/2015/11/sflow-test.html The source code for the tests is on GitHub: https://github.com/sflow-rt/sflow-test The easiest way to run the software is using Docker: https://hub.docker.com/r/sflow/sflow-test The goal is to compile a list of equipment and network operating systems that pass the tests and publish the results on sFlow.org. Failed tests can be passed to vendors to help them improve their implementations. In addition to identifying feature support, there are also stress tests to ensure accurate results under production workloads (rapid detection of DDoS etc). Involvement of operators would be great. If there are tests that are missing from the suite, please submit an enhancement request, or even better, a pull request, on GitHub. If you have a test lab and can run the tests on your own hardware, please share the results. The open source Host sFlow agent, https://sflow.net/, has been ported to a number of white box network operating systems and provides an opportunity for the community to extend sFlow functionality and address issues in the white box ecosystem. Operator involvement in this project would be most welcome. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at breathe-underwater.com Wed Apr 17 17:49:10 2019 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Wed, 17 Apr 2019 10:49:10 -0700 Subject: Anyone from Home Town Communications in Florida that can contact me off list? Message-ID: Need some help tracking down a device. Thank you, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu Apr 18 01:02:52 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 17 Apr 2019 21:02:52 -0400 (EDT) Subject: Special Counsel Office report web site Message-ID: The Special Counsel's report is expected to be posted on its website sometime between 11 a.m. and noon on Thursday, April 18, 2019. https://www.justice.gov/sco Since I helped with website for the Starr Report on September 11, 1998, I wish all website admins and network admins well tommorrow morning. # config t ip go faster From patrick at ianai.net Thu Apr 18 01:36:38 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 17 Apr 2019 21:36:38 -0400 Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: On Apr 17, 2019, at 9:02 PM, Sean Donelan wrote: > > The Special Counsel's report is expected to be posted on its website sometime between 11 a.m. and noon on Thursday, April 18, 2019. > > https://www.justice.gov/sco > > Since I helped with website for the Starr Report on September 11, 1998, I wish all website admins and network admins well tommorrow morning. > > # config t > ip go faster Sean: I remember “ip go faster” when you first posted it back in 1998. It was hilarious, I literally “LOL”ed. However, I did not envy you your job with that short notice. (But I did envy you all the people who were willing to help on such short notice.) I am still impressed at what you were able to pull together in just a few days. Major Kudos. Things will probably be easier this time. The Internet has evolved ways of dealing with exactly this problem. (Avi used to call it “slash-dot insurance”, but the idea is the same.) Specifically: TiggerBook-C-32:~ patrick$ dig +short www.justice.gov www.justice.gov.edgekey.net. e7598.dscg.akamaiedge.net. ’Nuff said. -- TTFN, patrick From sean at donelan.com Thu Apr 18 02:35:29 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 17 Apr 2019 22:35:29 -0400 (EDT) Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: > Things will probably be easier this time. The Internet has evolved ways > of dealing with exactly this problem. (Avi used to call it “slash-dot > insurance”, but the idea is the same.) Specifically: Yep, it will be interesting to see where the chokepoints are tommorrow. In 1998, the bandwidth pipes never filled up. The chokepoint was in the TCP and Web stacks. Eventually the Associated Press got a copy of the Starr Report on a CD from a congressional staffer. The press intern running down the street holding a CD was faster than 1998 internet :-) We were also lucky in 1998, no one had thought of DDOS yet. From fwessling at succinctsystems.com Thu Apr 18 02:55:56 2019 From: fwessling at succinctsystems.com (fwessling at succinctsystems.com) Date: Wed, 17 Apr 2019 22:55:56 -0400 Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: And we may still see the web stack being the ultimate cause of the delay. Parkinson's law always comes to the rescue:-) More faster and efficient processing architecture, Hyper transport buses, amd-64 Branch prediction. Massively faster storage subsystems and disk arrays, SSD slab caching for hypervisors And some dude with a AJAX framework to serve a PDF bringging the whole thing to a a screeching halt On April 17, 2019 10:35:29 PM EDT, Sean Donelan wrote: >On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: >> Things will probably be easier this time. The Internet has evolved >ways >> of dealing with exactly this problem. (Avi used to call it “slash-dot > >> insurance”, but the idea is the same.) Specifically: > >Yep, it will be interesting to see where the chokepoints are tommorrow. > >In 1998, the bandwidth pipes never filled up. The chokepoint was in the > >TCP and Web stacks. Eventually the Associated Press got a copy of the >Starr Report on a CD from a congressional staffer. The press intern >running down the street holding a CD was faster than 1998 internet :-) > >We were also lucky in 1998, no one had thought of DDOS yet. Frederick Wessling (CIO) Succinct Systems LLC Cell: +1(561) 571-2799 Office: +1(904) 758-9915 ext. 9925 Fax: +1(904) 758-9987 www.SuccinctSystems.com From mis at seiden.com Thu Apr 18 03:26:39 2019 From: mis at seiden.com (Mark Seiden) Date: Wed, 17 Apr 2019 20:26:39 -0700 Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: of course p2p is the way to distribute this but i doubt the justice department can admit there is any positive legitimate use for p2p. (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet.  “russiar, are you listening?”) (i sure hope there’s a signed version or at least a hash.) i predict there will be versions with fake content, missing content, and malware inserted that are distributed as well. and i’ll bet there will be some infected pdf version as well distributed that way. On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , wrote: > And we may still see the web stack being the ultimate cause of the delay. > > > Parkinson's law always comes to the rescue:-) > More faster and efficient processing architecture, Hyper transport buses, amd-64 Branch prediction. > Massively faster storage subsystems and disk arrays, SSD slab caching for hypervisors > > And some dude with a AJAX framework to serve a PDF bringging the whole thing to a a screeching halt > > On April 17, 2019 10:35:29 PM EDT, Sean Donelan wrote: > > On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: > > > Things will probably be easier this time. The Internet has evolved > > ways > > > of dealing with exactly this problem. (Avi used to call it “slash-dot > > > > > insurance”, but the idea is the same.) Specifically: > > > > Yep, it will be interesting to see where the chokepoints are tommorrow. > > > > In 1998, the bandwidth pipes never filled up. The chokepoint was in the > > > > TCP and Web stacks. Eventually the Associated Press got a copy of the > > Starr Report on a CD from a congressional staffer. The press intern > > running down the street holding a CD was faster than 1998 internet :-) > > > > We were also lucky in 1998, no one had thought of DDOS yet. > > Frederick Wessling (CIO) > Succinct Systems LLC > Cell: +1(561) 571-2799 > Office: +1(904) 758-9915 ext. 9925 > Fax: +1(904) 758-9987 > www.SuccinctSystems.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Thu Apr 18 03:32:21 2019 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 17 Apr 2019 20:32:21 -0700 Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> Isn’t this why god invented CDNs? Though, i doubt the govment is Akamized... -Mike > On Apr 17, 2019, at 20:26, Mark Seiden wrote: > > of course p2p is the way to distribute this but i doubt the justice department can admit there is any positive legitimate use for p2p. > > (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet. “russiar, are you listening?”) > > (i sure hope there’s a signed version or at least a hash.) > > i predict there will be versions with fake content, missing content, and malware inserted that are distributed as well. > > > > > and i’ll bet there will be some infected pdf version as well distributed that way. >> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , wrote: >> And we may still see the web stack being the ultimate cause of the delay. >> >> >> Parkinson's law always comes to the rescue:-) >> More faster and efficient processing architecture, Hyper transport buses, amd-64 Branch prediction. >> Massively faster storage subsystems and disk arrays, SSD slab caching for hypervisors >> >> And some dude with a AJAX framework to serve a PDF bringging the whole thing to a a screeching halt >> >>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan wrote: >>>> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: >>>> Things will probably be easier this time. The Internet has evolved >>> ways >>>> of dealing with exactly this problem. (Avi used to call it “slash-dot >>> >>>> insurance”, but the idea is the same.) Specifically: >>> >>> Yep, it will be interesting to see where the chokepoints are tommorrow. >>> >>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the >>> >>> TCP and Web stacks. Eventually the Associated Press got a copy of the >>> Starr Report on a CD from a congressional staffer. The press intern >>> running down the street holding a CD was faster than 1998 internet :-) >>> >>> We were also lucky in 1998, no one had thought of DDOS yet. >> >> Frederick Wessling (CIO) >> Succinct Systems LLC >> Cell: +1(561) 571-2799 >> Office: +1(904) 758-9915 ext. 9925 >> Fax: +1(904) 758-9987 >> www.SuccinctSystems.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Thu Apr 18 04:11:37 2019 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 18 Apr 2019 00:11:37 -0400 Subject: Special Counsel Office report web site In-Reply-To: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> Message-ID: Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It certainly is. On Wed, Apr 17, 2019 at 23:34 wrote: > Isn’t this why god invented CDNs? Though, i doubt the govment is > Akamized... > > -Mike > > On Apr 17, 2019, at 20:26, Mark Seiden wrote: > > of course p2p is the way to distribute this but i doubt the justice > department can admit there is any positive legitimate use for p2p. > > (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent > yet. “russiar, are you listening?”) > > (i sure hope there’s a signed version or at least a hash.) > > i predict there will be versions with fake content, missing content, and > malware inserted that are distributed as well. > > > > > and i’ll bet there will be some infected pdf version as well distributed > that way. > On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , > wrote: > > And we may still see the web stack being the ultimate cause of the delay. > > > Parkinson's law always comes to the rescue:-) > More faster and efficient processing architecture, Hyper transport buses, > amd-64 Branch prediction. > Massively faster storage subsystems and disk arrays, SSD slab caching for > hypervisors > > And some dude with a AJAX framework to serve a PDF bringging the whole > thing to a a screeching halt > > On April 17, 2019 10:35:29 PM EDT, Sean Donelan wrote: > > On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: > > Things will probably be easier this time. The Internet has evolved > > ways > > of dealing with exactly this problem. (Avi used to call it “slash-dot > > > insurance”, but the idea is the same.) Specifically: > > > Yep, it will be interesting to see where the chokepoints are tommorrow. > > In 1998, the bandwidth pipes never filled up. The chokepoint was in the > > TCP and Web stacks. Eventually the Associated Press got a copy of the > Starr Report on a CD from a congressional staffer. The press intern > running down the street holding a CD was faster than 1998 internet :-) > > We were also lucky in 1998, no one had thought of DDOS yet. > > > Frederick Wessling (CIO) > Succinct Systems LLC > Cell: +1(561) 571-2799 > Office: +1(904) 758-9915 ext. 9925 > Fax: +1(904) 758-9987 > www.SuccinctSystems.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at the-watsons.org Thu Apr 18 04:14:50 2019 From: brett at the-watsons.org (Brett Watson) Date: Wed, 17 Apr 2019 21:14:50 -0700 Subject: Special Counsel Office report web site In-Reply-To: References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> Message-ID: Or maybe do this (faster than nanog archives) :) bash-3.2# dig cia.gov ns ; <<>> DiG 9.10.6 <<>> cia.gov ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cia.gov. IN NS ;; ANSWER SECTION: cia.gov. 86400 IN NS a22-66.akam.net. cia.gov. 86400 IN NS a16-67.akam.net. cia.gov. 86400 IN NS a1-22.akam.net. cia.gov. 86400 IN NS a12-65.akam.net. cia.gov. 86400 IN NS a3-64.akam.net. cia.gov. 86400 IN NS a13-65.akam.net. > On Apr 17, 2019, at 9:11 PM, Martin Hannigan wrote: > > > Check the nANOG archives for examples of whitehouse.gov , cia.gov etc. It certainly is. > > > > On Wed, Apr 17, 2019 at 23:34 > wrote: > Isn’t this why god invented CDNs? Though, i doubt the govment is Akamized... > > -Mike > > On Apr 17, 2019, at 20:26, Mark Seiden > wrote: > >> of course p2p is the way to distribute this but i doubt the justice department can admit there is any positive legitimate use for p2p. >> >> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet. “russiar, are you listening?”) >> >> (i sure hope there’s a signed version or at least a hash.) >> >> i predict there will be versions with fake content, missing content, and malware inserted that are distributed as well. >> >> >> >> >> and i’ll bet there will be some infected pdf version as well distributed that way. >> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG >, wrote: >>> And we may still see the web stack being the ultimate cause of the delay. >>> >>> >>> Parkinson's law always comes to the rescue:-) >>> More faster and efficient processing architecture, Hyper transport buses, amd-64 Branch prediction. >>> Massively faster storage subsystems and disk arrays, SSD slab caching for hypervisors >>> >>> And some dude with a AJAX framework to serve a PDF bringging the whole thing to a a screeching halt >>> >>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan > wrote: >>>> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: >>>>> Things will probably be easier this time. The Internet has evolved >>>> ways >>>>> of dealing with exactly this problem. (Avi used to call it “slash-dot >>>> >>>>> insurance”, but the idea is the same.) Specifically: >>>> >>>> Yep, it will be interesting to see where the chokepoints are tommorrow. >>>> >>>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the >>>> >>>> TCP and Web stacks. Eventually the Associated Press got a copy of the >>>> Starr Report on a CD from a congressional staffer. The press intern >>>> running down the street holding a CD was faster than 1998 internet :-) >>>> >>>> We were also lucky in 1998, no one had thought of DDOS yet. >>> >>> Frederick Wessling (CIO) >>> Succinct Systems LLC >>> Cell: +1(561) 571-2799 >>> Office: +1(904) 758-9915 ext. 9925 >>> Fax: +1(904) 758-9987 >>> www.SuccinctSystems.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Thu Apr 18 04:19:48 2019 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 17 Apr 2019 21:19:48 -0700 Subject: Special Counsel Office report web site In-Reply-To: References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> Message-ID: <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> Oh spiffy! Will be interesting to see if there are any problems then. -Mike > On Apr 17, 2019, at 21:14, Brett Watson wrote: > > Or maybe do this (faster than nanog archives) :) > > > bash-3.2# dig cia.gov ns > > ; <<>> DiG 9.10.6 <<>> cia.gov ns > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;cia.gov. IN NS > > ;; ANSWER SECTION: > cia.gov. 86400 IN NS a22-66.akam.net. > cia.gov. 86400 IN NS a16-67.akam.net. > cia.gov. 86400 IN NS a1-22.akam.net. > cia.gov. 86400 IN NS a12-65.akam.net. > cia.gov. 86400 IN NS a3-64.akam.net. > cia.gov. 86400 IN NS a13-65.akam.net. > > > >> On Apr 17, 2019, at 9:11 PM, Martin Hannigan wrote: >> >> >> Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It certainly is. >> >> >> >>> On Wed, Apr 17, 2019 at 23:34 wrote: >>> Isn’t this why god invented CDNs? Though, i doubt the govment is Akamized... >>> >>> -Mike >>> >>>> On Apr 17, 2019, at 20:26, Mark Seiden wrote: >>>> >>>> of course p2p is the way to distribute this but i doubt the justice department can admit there is any positive legitimate use for p2p. >>>> >>>> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet. “russiar, are you listening?”) >>>> >>>> (i sure hope there’s a signed version or at least a hash.) >>>> >>>> i predict there will be versions with fake content, missing content, and malware inserted that are distributed as well. >>>> >>>> >>>> >>>> >>>> and i’ll bet there will be some infected pdf version as well distributed that way. >>>>> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , wrote: >>>>> And we may still see the web stack being the ultimate cause of the delay. >>>>> >>>>> >>>>> Parkinson's law always comes to the rescue:-) >>>>> More faster and efficient processing architecture, Hyper transport buses, amd-64 Branch prediction. >>>>> Massively faster storage subsystems and disk arrays, SSD slab caching for hypervisors >>>>> >>>>> And some dude with a AJAX framework to serve a PDF bringging the whole thing to a a screeching halt >>>>> >>>>>> On April 17, 2019 10:35:29 PM EDT, Sean Donelan wrote: >>>>>>> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: >>>>>>> Things will probably be easier this time. The Internet has evolved >>>>>> ways >>>>>>> of dealing with exactly this problem. (Avi used to call it “slash-dot >>>>>> >>>>>>> insurance”, but the idea is the same.) Specifically: >>>>>> >>>>>> Yep, it will be interesting to see where the chokepoints are tommorrow. >>>>>> >>>>>> In 1998, the bandwidth pipes never filled up. The chokepoint was in the >>>>>> >>>>>> TCP and Web stacks. Eventually the Associated Press got a copy of the >>>>>> Starr Report on a CD from a congressional staffer. The press intern >>>>>> running down the street holding a CD was faster than 1998 internet :-) >>>>>> >>>>>> We were also lucky in 1998, no one had thought of DDOS yet. >>>>> >>>>> Frederick Wessling (CIO) >>>>> Succinct Systems LLC >>>>> Cell: +1(561) 571-2799 >>>>> Office: +1(904) 758-9915 ext. 9925 >>>>> Fax: +1(904) 758-9987 >>>>> www.SuccinctSystems.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Thu Apr 18 04:25:32 2019 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 18 Apr 2019 00:25:32 -0400 Subject: Special Counsel Office report web site In-Reply-To: <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> Message-ID: Hey Mike. Agreed. But the scale of a 400 page document with global interest? Should be highly cached with a good ratio of served to pull bits. I'm willing to bet you a beer its just another day on the Internet. However, I could be wrong. Hope to see you in DC to collect! I already know Brett is in. :) Best, -M< On Thu, Apr 18, 2019 at 12:21 AM wrote: > Oh spiffy! > > Will be interesting to see if there are any problems then. > > -Mike > > On Apr 17, 2019, at 21:14, Brett Watson wrote: > > Or maybe do this (faster than nanog archives) :) > > > bash-3.2# dig cia.gov ns > > ; <<>> DiG 9.10.6 <<>> cia.gov ns > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33203 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;cia.gov. IN NS > > ;; ANSWER SECTION: > cia.gov. 86400 IN NS a22-66.akam.net. > cia.gov. 86400 IN NS a16-67.akam.net. > cia.gov. 86400 IN NS a1-22.akam.net. > cia.gov. 86400 IN NS a12-65.akam.net. > cia.gov. 86400 IN NS a3-64.akam.net. > cia.gov. 86400 IN NS a13-65.akam.net. > > > > On Apr 17, 2019, at 9:11 PM, Martin Hannigan wrote: > > > Check the nANOG archives for examples of whitehouse.gov, cia.gov etc. It > certainly is. > > > > On Wed, Apr 17, 2019 at 23:34 wrote: > >> Isn’t this why god invented CDNs? Though, i doubt the govment is >> Akamized... >> >> -Mike >> >> On Apr 17, 2019, at 20:26, Mark Seiden wrote: >> >> of course p2p is the way to distribute this but i doubt the justice >> department can admit there is any positive legitimate use for p2p. >> >> (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent >> yet. “russiar, are you listening?”) >> >> (i sure hope there’s a signed version or at least a hash.) >> >> i predict there will be versions with fake content, missing content, and >> malware inserted that are distributed as well. >> >> >> >> >> and i’ll bet there will be some infected pdf version as well distributed >> that way. >> On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG , >> wrote: >> >> And we may still see the web stack being the ultimate cause of the delay. >> >> >> Parkinson's law always comes to the rescue:-) >> More faster and efficient processing architecture, Hyper transport buses, >> amd-64 Branch prediction. >> Massively faster storage subsystems and disk arrays, SSD slab caching for >> hypervisors >> >> And some dude with a AJAX framework to serve a PDF bringging the whole >> thing to a a screeching halt >> >> On April 17, 2019 10:35:29 PM EDT, Sean Donelan wrote: >> >> On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: >> >> Things will probably be easier this time. The Internet has evolved >> >> ways >> >> of dealing with exactly this problem. (Avi used to call it “slash-dot >> >> >> insurance”, but the idea is the same.) Specifically: >> >> >> Yep, it will be interesting to see where the chokepoints are tommorrow. >> >> In 1998, the bandwidth pipes never filled up. The chokepoint was in the >> >> TCP and Web stacks. Eventually the Associated Press got a copy of the >> Starr Report on a CD from a congressional staffer. The press intern >> running down the street holding a CD was faster than 1998 internet :-) >> >> We were also lucky in 1998, no one had thought of DDOS yet. >> >> >> Frederick Wessling (CIO) >> Succinct Systems LLC >> Cell: +1(561) 571-2799 >> Office: +1(904) 758-9915 ext. 9925 >> Fax: +1(904) 758-9987 >> www.SuccinctSystems.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.lyon at gmail.com Thu Apr 18 04:37:31 2019 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Wed, 17 Apr 2019 21:37:31 -0700 Subject: Special Counsel Office report web site Message-ID: Deal. Though, like you, i am assuming it’ll just be another day on the intarwebs as well... We shall see! -Mike > On Apr 17, 2019, at 21:25, Martin Hannigan wrote: > > Hey Mike. > > Agreed. But the scale of a 400 page document with global interest? Should > be highly cached with a good ratio of served to pull bits. I'm willing to > bet you a beer its just another day on the Internet. However, I could be > wrong. Hope to see you in DC to collect! I already know Brett is in. :) > > Best, > > -M< > From jared at puck.nether.net Thu Apr 18 10:43:27 2019 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Apr 2019 06:43:27 -0400 Subject: Special Counsel Office report web site In-Reply-To: References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> Message-ID: <20190418104327.GA24350@puck.nether.net> On Thu, Apr 18, 2019 at 12:25:32AM -0400, Martin Hannigan wrote: > Hey Mike. > > Agreed. But the scale of a 400 page document with global interest? Should > be highly cached with a good ratio of served to pull bits. I'm willing to > bet you a beer its just another day on the Internet. However, I could be > wrong. Hope to see you in DC to collect! I already know Brett is in. :) I would expect far more traffic from patch tuesday to exceed the size of the document. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From bkain1 at ford.com Thu Apr 18 12:56:03 2019 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Thu, 18 Apr 2019 12:56:03 +0000 Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: I can’t believe p2p isn’t used more, even inside companies. It does have legit uses From: NANOG On Behalf Of Mark Seiden Sent: Wednesday, April 17, 2019 11:27 PM To: fwessling at succinctsystems.com; Mark Tinka via NANOG Subject: Re: Special Counsel Office report web site of course p2p is the way to distribute this but i doubt the justice department can admit there is any positive legitimate use for p2p. (i’ve been surprised that it hasn’t made it to wikileaks or bittorrent yet. “russiar, are you listening?”) (i sure hope there’s a signed version or at least a hash.) i predict there will be versions with fake content, missing content, and malware inserted that are distributed as well. and i’ll bet there will be some infected pdf version as well distributed that way. On Apr 17, 2019, 7:57 PM -0700, fwessling--- via NANOG >, wrote: And we may still see the web stack being the ultimate cause of the delay. Parkinson's law always comes to the rescue:-) More faster and efficient processing architecture, Hyper transport buses, amd-64 Branch prediction. Massively faster storage subsystems and disk arrays, SSD slab caching for hypervisors And some dude with a AJAX framework to serve a PDF bringging the whole thing to a a screeching halt On April 17, 2019 10:35:29 PM EDT, Sean Donelan > wrote: On Wed, 17 Apr 2019, Patrick W. Gilmore wrote: Things will probably be easier this time. The Internet has evolved ways of dealing with exactly this problem. (Avi used to call it “slash-dot insurance”, but the idea is the same.) Specifically: Yep, it will be interesting to see where the chokepoints are tommorrow. In 1998, the bandwidth pipes never filled up. The chokepoint was in the TCP and Web stacks. Eventually the Associated Press got a copy of the Starr Report on a CD from a congressional staffer. The press intern running down the street holding a CD was faster than 1998 internet :-) We were also lucky in 1998, no one had thought of DDOS yet. Frederick Wessling (CIO) Succinct Systems LLC Cell: +1(561) 571-2799 Office: +1(904) 758-9915 ext. 9925 Fax: +1(904) 758-9987 www.SuccinctSystems.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Thu Apr 18 13:46:12 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 18 Apr 2019 13:46:12 +0000 Subject: Special Counsel Office report web site In-Reply-To: <20190418104327.GA24350@puck.nether.net> References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> <20190418104327.GA24350@puck.nether.net> Message-ID: <6c66e27294e041d9a607770a73b8eb14@medline.com> Agreed, I remember the biggest problem when the Starr Report was released was that our dial-up PoPs had all lines busy. It was a different Internet then. Steven Naslund Chicago IL > Hey Mike. > > Agreed. But the scale of a 400 page document with global interest? > Should be highly cached with a good ratio of served to pull bits. I'm > willing to bet you a beer its just another day on the Internet. > However, I could be wrong. Hope to see you in DC to collect! I already > know Brett is in. :) From rsk at gsp.org Thu Apr 18 14:17:47 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 18 Apr 2019 10:17:47 -0400 Subject: Special Counsel Office report web site In-Reply-To: References: Message-ID: <20190418141747.GA4567@gsp.org> On Wed, Apr 17, 2019 at 09:02:52PM -0400, Sean Donelan wrote: > The Special Counsel's report is expected to be posted [...] Not quite. A *version* of the report that has been redacted by the President's hand-picked obedient lackey will be posted. I suspect that the full report will find its way to us via other means. ---rsk From mel at beckman.org Thu Apr 18 14:23:55 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 18 Apr 2019 14:23:55 +0000 Subject: Special Counsel Office report web site In-Reply-To: <20190418141747.GA4567@gsp.org> References: , <20190418141747.GA4567@gsp.org> Message-ID: Rich, If you want NANOG to devolve into a morass of political claptrap, keep posting comments like that. Personally, I want NANOG to remain a useful technical resource, and leave the partisan crap to Facebook and its ilk. -mel beckman > On Apr 18, 2019, at 7:18 AM, Rich Kulawiec wrote: > >> On Wed, Apr 17, 2019 at 09:02:52PM -0400, Sean Donelan wrote: >> The Special Counsel's report is expected to be posted [...] > > Not quite. A *version* of the report that has been redacted by > the President's hand-picked obedient lackey will be posted. > > I suspect that the full report will find its way to us via other means. > > ---rsk From mel at beckman.org Thu Apr 18 14:33:15 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 18 Apr 2019 14:33:15 +0000 Subject: Special Counsel Office report web site In-Reply-To: <6c66e27294e041d9a607770a73b8eb14@medline.com> References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> <20190418104327.GA24350@puck.nether.net>, <6c66e27294e041d9a607770a73b8eb14@medline.com> Message-ID: <88611E65-B8B6-46C7-A371-5019087A2547@beckman.org> B&N just announced that they are offering free downloads via their Nook reader. I noticed I couldn’t reach B&N via IPv6, and discovered the cause : nslookup > set type=AAAA > barnesandnoble.com Server: 4.2.2.1 Non-authoritative answer: *** Can't find barnesandnoble.com: No answer > set type=A > barnesandnoble.com. Server: 4.2.2.1 Non-authoritative answer: Name: barnesandnoble.com Address: 161.221.74.213 I don’t know if this is a temporary DNS failure, or B&N really still has no IPv6 hosted web services :) -mel > On Apr 18, 2019, at 6:46 AM, Naslund, Steve wrote: > > Agreed, I remember the biggest problem when the Starr Report was released was that our dial-up PoPs had all lines busy. It was a different Internet then. > > Steven Naslund > Chicago IL > >> Hey Mike. >> >> Agreed. But the scale of a 400 page document with global interest? >> Should be highly cached with a good ratio of served to pull bits. I'm >> willing to bet you a beer its just another day on the Internet. >> However, I could be wrong. Hope to see you in DC to collect! I already >> know Brett is in. :) > From rsk at gsp.org Thu Apr 18 14:36:24 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 18 Apr 2019 10:36:24 -0400 Subject: P2P [was: Special Counsel Office report web site] In-Reply-To: References: Message-ID: <20190418143624.GA4864@gsp.org> On Thu, Apr 18, 2019 at 12:56:03PM +0000, Kain, Rebecca (.) wrote: > I can???t believe p2p isn???t used more, even inside companies. It does have legit uses It does, and some of the use cases for it are quite compelling. However, there is often deep mistrust associated with it: years of propaganda from the copyright lobby have fostered the impression that it is inherently malicious. That can be very difficult to overcome: it's in the same class of mythos as "all ICMP traffic is bad", and well, lots of us have spent lots of time over lots of years trying to get past that one. Getting P2P accepted looks like a much bigger hill to climb. ---rsk From bkain1 at ford.com Thu Apr 18 15:16:34 2019 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Thu, 18 Apr 2019 15:16:34 +0000 Subject: who attacks the weather channel? Message-ID: <425baa9949074ee1b1c2b2c917e3c689@ford.com> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Thu Apr 18 15:26:19 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 18 Apr 2019 17:26:19 +0200 Subject: who attacks the weather channel? In-Reply-To: <425baa9949074ee1b1c2b2c917e3c689@ford.com> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> Message-ID: <20190418152619.wusrant6vx5fpoeb@nic.fr> On Thu, Apr 18, 2019 at 03:16:34PM +0000, Kain, Rebecca (.) wrote a message of 69 lines which said: > https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html May be these people? https://en.wikipedia.org/wiki/Weather_Underground From morrowc.lists at gmail.com Thu Apr 18 15:38:30 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Apr 2019 11:38:30 -0400 Subject: who attacks the weather channel? In-Reply-To: <20190418152619.wusrant6vx5fpoeb@nic.fr> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> Message-ID: On Thu, Apr 18, 2019 at 11:27 AM Stephane Bortzmeyer wrote: > > On Thu, Apr 18, 2019 at 03:16:34PM +0000, > Kain, Rebecca (.) wrote > a message of 69 lines which said: > > > https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html > > May be these people? > > https://en.wikipedia.org/wiki/Weather_Underground I think WU was actually bought by weatherunderground... From fredbaker.ietf at gmail.com Thu Apr 18 15:50:49 2019 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Thu, 18 Apr 2019 08:50:49 -0700 Subject: who attacks the weather channel? In-Reply-To: References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> Message-ID: <9E7680AE-D75B-4F0A-896D-766B417B5D86@gmail.com> According to this, Weather Underground was purchased by the Weather Channel and firmed “The Weather Company”, and that was in turn purchased by IBM last year. https://www.wunderground.com/blog/JeffMasters/weather-underground-bought-by-ibm.html Sent using a machine that autocorrects in interesting ways... > On Apr 18, 2019, at 8:38 AM, Christopher Morrow wrote: > >> On Thu, Apr 18, 2019 at 11:27 AM Stephane Bortzmeyer wrote: >> >> On Thu, Apr 18, 2019 at 03:16:34PM +0000, >> Kain, Rebecca (.) wrote >> a message of 69 lines which said: >> >>> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html >> >> May be these people? >> >> https://en.wikipedia.org/wiki/Weather_Underground > > I think WU was actually bought by weatherunderground... -------------- next part -------------- An HTML attachment was scrubbed... URL: From quantumfoam at gmail.com Thu Apr 18 15:56:01 2019 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Thu, 18 Apr 2019 11:56:01 -0400 Subject: who attacks the weather channel? In-Reply-To: <9E7680AE-D75B-4F0A-896D-766B417B5D86@gmail.com> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <9E7680AE-D75B-4F0A-896D-766B417B5D86@gmail.com> Message-ID: The Weather **Channel** is now a separate entity, which is the cable channel only. The Weather **Company** is the entity now owned by IBM, and it provides the web content and apps such as Weather Underground and Weather.com. I live near their corporate HDQ and interview there for a job, so they explained all of this to me at the time. --Jonathan Rogers On Thu, Apr 18, 2019 at 11:52 AM Fred Baker wrote: > According to this, Weather Underground was purchased by the Weather > Channel and firmed “The Weather Company”, and that was in turn purchased by > IBM last year. > > > https://www.wunderground.com/blog/JeffMasters/weather-underground-bought-by-ibm.html > > Sent using a machine that autocorrects in interesting ways... > > On Apr 18, 2019, at 8:38 AM, Christopher Morrow > wrote: > > On Thu, Apr 18, 2019 at 11:27 AM Stephane Bortzmeyer > wrote: > > > On Thu, Apr 18, 2019 at 03:16:34PM +0000, > > Kain, Rebecca (.) wrote > > a message of 69 lines which said: > > > https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html > > > May be these people? > > > https://en.wikipedia.org/wiki/Weather_Underground > > > I think WU was actually bought by weatherunderground... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu Apr 18 16:16:47 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 18 Apr 2019 16:16:47 +0000 Subject: who attacks the weather channel? In-Reply-To: <9E7680AE-D75B-4F0A-896D-766B417B5D86@gmail.com> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <9E7680AE-D75B-4F0A-896D-766B417B5D86@gmail.com> Message-ID: When IBM purchased TWC, IBM summarily cancelled our heretofore free weather station monitoring through Wunderground.com. Instead IBM offered to “sell” us our own remote data center weather stations information back to us at an exorbitant price. No thank you. We switched everything to Ambient.com. The idea of Wunderground.com was free public collection and sharing of useful weather data to vastly increase the density of coverage over commercial services. It’s a pity IBM, who otherwise supports open source through it’s vast Linux contributions, couldn’t see that. During the Santa Barbara fires last year, our weather station on Gibraltar Peak was the one source firefighting helicopter pilots had to obtain ridge wind speeds, which was critical to their operation. Neither the NWS nor TWC or IBM is willing to invest in critical public information infrastructure. I’m a capitalist, but I don’t believe destroying the good works of others is ultimately profitable. -mel On Apr 18, 2019, at 8:50 AM, Fred Baker > wrote: According to this, Weather Underground was purchased by the Weather Channel and firmed “The Weather Company”, and that was in turn purchased by IBM last year. https://www.wunderground.com/blog/JeffMasters/weather-underground-bought-by-ibm.html Sent using a machine that autocorrects in interesting ways... On Apr 18, 2019, at 8:38 AM, Christopher Morrow > wrote: On Thu, Apr 18, 2019 at 11:27 AM Stephane Bortzmeyer > wrote: On Thu, Apr 18, 2019 at 03:16:34PM +0000, Kain, Rebecca (.) > wrote a message of 69 lines which said: https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html May be these people? https://en.wikipedia.org/wiki/Weather_Underground I think WU was actually bought by weatherunderground... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Thu Apr 18 16:51:25 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 18 Apr 2019 16:51:25 +0000 Subject: who attacks the weather channel? In-Reply-To: References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <9E7680AE-D75B-4F0A-896D-766B417B5D86@gmail.com> Message-ID: <2D59D4EC-31AF-4AFA-92A6-1BE947F01D64@beckman.org> I mistyped. It's AmbientWeather.com. Here’s the Gibraltar Peak weather station link if anyone is interested: https://dashboard.ambientweather.net/devices/public/143d3d3f9aa00e499954061991374c7b Ignore the rain data. Something is not mapping correctly from our weather station to the Ambient data collection, so it looks like we have many feet of rain :) But it’s wind and temperature we’re most concerned with, so I haven’t put any time into sorting out the decimal point in the rain gauge, or whatever is the cause of crazy rain data. -mel On Apr 18, 2019, at 9:16 AM, Mel Beckman > wrote: When IBM purchased TWC, IBM summarily cancelled our heretofore free weather station monitoring through Wunderground.com. Instead IBM offered to “sell” us our own remote data center weather stations information back to us at an exorbitant price. No thank you. We switched everything to Ambient.com. The idea of Wunderground.com was free public collection and sharing of useful weather data to vastly increase the density of coverage over commercial services. It’s a pity IBM, who otherwise supports open source through it’s vast Linux contributions, couldn’t see that. During the Santa Barbara fires last year, our weather station on Gibraltar Peak was the one source firefighting helicopter pilots had to obtain ridge wind speeds, which was critical to their operation. Neither the NWS nor TWC or IBM is willing to invest in critical public information infrastructure. I’m a capitalist, but I don’t believe destroying the good works of others is ultimately profitable. -mel On Apr 18, 2019, at 8:50 AM, Fred Baker > wrote: According to this, Weather Underground was purchased by the Weather Channel and firmed “The Weather Company”, and that was in turn purchased by IBM last year. https://www.wunderground.com/blog/JeffMasters/weather-underground-bought-by-ibm.html Sent using a machine that autocorrects in interesting ways... On Apr 18, 2019, at 8:38 AM, Christopher Morrow > wrote: On Thu, Apr 18, 2019 at 11:27 AM Stephane Bortzmeyer > wrote: On Thu, Apr 18, 2019 at 03:16:34PM +0000, Kain, Rebecca (.) > wrote a message of 69 lines which said: https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html May be these people? https://en.wikipedia.org/wiki/Weather_Underground I think WU was actually bought by weatherunderground... -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Apr 18 17:18:05 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 18 Apr 2019 11:18:05 -0600 Subject: We have it here, including the conclusions (was Re: Special Counsel Office report web site) In-Reply-To: <88611E65-B8B6-46C7-A371-5019087A2547@beckman.org> References: <6E208A72-03B5-406B-B909-D44918D6CEB4@gmail.com> <9D4A713A-1B69-4E7E-B1BD-E168E861A59D@gmail.com> <20190418104327.GA24350@puck.nether.net> <6c66e27294e041d9a607770a73b8eb14@medline.com> <88611E65-B8B6-46C7-A371-5019087A2547@beckman.org> Message-ID: Oops..the link would be helpful, sorry! We have made the full report available here, including conclusions (full report both embedded by iframe, and linked to the actual report at DOJ). https://www.theinternetpatrol.com/the-mueller-report-online-text-of-the-mueller-report-and-analysis/ Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop > On Apr 18, 2019, at 8:33 AM, Mel Beckman wrote: > > B&N just announced that they are offering free downloads via their Nook reader. I noticed I couldn’t reach B&N via IPv6, and discovered the cause : > > nslookup >> set type=AAAA >> barnesandnoble.com > Server: 4.2.2.1 > Non-authoritative answer: > *** Can't find barnesandnoble.com: No answer > >> set type=A >> barnesandnoble.com. > Server: 4.2.2.1 > Non-authoritative answer: > Name: barnesandnoble.com > Address: 161.221.74.213 > > I don’t know if this is a temporary DNS failure, or B&N really still has no IPv6 hosted web services :) > > > -mel > >> On Apr 18, 2019, at 6:46 AM, Naslund, Steve wrote: >> >> Agreed, I remember the biggest problem when the Starr Report was released was that our dial-up PoPs had all lines busy. It was a different Internet then. >> >> Steven Naslund >> Chicago IL >> >>> Hey Mike. >>> >>> Agreed. But the scale of a 400 page document with global interest? >>> Should be highly cached with a good ratio of served to pull bits. I'm >>> willing to bet you a beer its just another day on the Internet. >>> However, I could be wrong. Hope to see you in DC to collect! I already >>> know Brett is in. :) >> From jsage at finchhaven.com Thu Apr 18 17:46:28 2019 From: jsage at finchhaven.com (John Sage) Date: Thu, 18 Apr 2019 10:46:28 -0700 Subject: who attacks the weather channel? In-Reply-To: <20190418152619.wusrant6vx5fpoeb@nic.fr> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> Message-ID: <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> On 4/18/19 8:26 AM, Stephane Bortzmeyer wrote: > On Thu, Apr 18, 2019 at 03:16:34PM +0000, > Kain, Rebecca (.) wrote > a message of 69 lines which said: > >> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html > > May be these people? > > https://en.wikipedia.org/wiki/Weather_Underground > umm... Thinking this was a joke that, by the replies I've seen, most people are too young to get the reference to radical 60's politics Also it seems no one actually clicked through on the link, which would have suggested this *sigh* - John -- From marco at heavenlysanctuary.com Thu Apr 18 17:38:59 2019 From: marco at heavenlysanctuary.com (Marco Belmonte) Date: Thu, 18 Apr 2019 10:38:59 -0700 Subject: Special Counsel Office report web site In-Reply-To: References: <20190418141747.GA4567@gsp.org> Message-ID: <32934cd3-5a14-c5f6-1df4-cdb4c427240e@heavenlysanctuary.com> An HTML attachment was scrubbed... URL: From ler762 at gmail.com Thu Apr 18 18:17:13 2019 From: ler762 at gmail.com (Lee) Date: Thu, 18 Apr 2019 14:17:13 -0400 Subject: who attacks the weather channel? In-Reply-To: <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> Message-ID: On 4/18/19, John Sage wrote: > On 4/18/19 8:26 AM, Stephane Bortzmeyer wrote: >> On Thu, Apr 18, 2019 at 03:16:34PM +0000, >> Kain, Rebecca (.) wrote >> a message of 69 lines which said: >> >>> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html >> >> May be these people? >> >> https://en.wikipedia.org/wiki/Weather_Underground >> > > umm... > > Thinking this was a joke that, by the replies I've seen, most people are > too young to get the reference to radical 60's politics > > Also it seems no one actually clicked through on the link, which would > have suggested this > > *sigh* > Look on the bright side - if this type of thing still prompts a *sigh* you're not all that old. Best Regards, Lee From morrowc.lists at gmail.com Thu Apr 18 18:33:27 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Apr 2019 14:33:27 -0400 Subject: who attacks the weather channel? In-Reply-To: References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> Message-ID: On Thu, Apr 18, 2019 at 2:18 PM Lee wrote: > > On 4/18/19, John Sage wrote: > > On 4/18/19 8:26 AM, Stephane Bortzmeyer wrote: > >> On Thu, Apr 18, 2019 at 03:16:34PM +0000, > >> Kain, Rebecca (.) wrote > >> a message of 69 lines which said: > >> > >>> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html > >> > >> May be these people? > >> > >> https://en.wikipedia.org/wiki/Weather_Underground > >> > > > > umm... > > > > Thinking this was a joke that, by the replies I've seen, most people are > > too young to get the reference to radical 60's politics > > sure, but is painting an actual org with that brush a good idea? which was why I pointed out that WU was bought by TWC. (not the other TWC, of course) > > Also it seems no one actually clicked through on the link, which would > > have suggested this > > > > *sigh* > > > Look on the bright side - if this type of thing still prompts a *sigh* > you're not all that old. #getoffamalawn! From amitchell at isipp.com Thu Apr 18 18:36:57 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 18 Apr 2019 12:36:57 -0600 Subject: who attacks the weather channel? In-Reply-To: <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> Message-ID: <2FCEF7C7-46DF-4B64-9946-7FCFA053374D@isipp.com> I not only got it, my best friend in junior high's father was president of SDS. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting http://www.SuretyMail.com/ http://www.SuretyMail.eu/ > On Apr 18, 2019, at 11:46 AM, John Sage wrote: > > On 4/18/19 8:26 AM, Stephane Bortzmeyer wrote: >> On Thu, Apr 18, 2019 at 03:16:34PM +0000, >> Kain, Rebecca (.) wrote >> a message of 69 lines which said: >>> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html >> May be these people? >> https://en.wikipedia.org/wiki/Weather_Underground > > umm... > > Thinking this was a joke that, by the replies I've seen, most people are too young to get the reference to radical 60's politics > > Also it seems no one actually clicked through on the link, which would have suggested this > > *sigh* > > > - John > -- From randy at psg.com Thu Apr 18 19:01:54 2019 From: randy at psg.com (Randy Bush) Date: Thu, 18 Apr 2019 12:01:54 -0700 Subject: Special Counsel Office report web site In-Reply-To: <32934cd3-5a14-c5f6-1df4-cdb4c427240e@heavenlysanctuary.com> References: <20190418141747.GA4567@gsp.org> <32934cd3-5a14-c5f6-1df4-cdb4c427240e@heavenlysanctuary.com> Message-ID: > If you want NANOG to devolve into a morass of political claptrap you mean it could improve? From johnl at iecc.com Thu Apr 18 22:08:47 2019 From: johnl at iecc.com (John Levine) Date: 18 Apr 2019 18:08:47 -0400 Subject: We have it here, including the conclusions (was Re: Special Counsel Office report web site) In-Reply-To: Message-ID: <20190418220848.17E8420123E7C4@ary.qy> In article you write: >Oops..the link would be helpful, sorry! > >We have made the full report available here, including conclusions (full report both embedded by iframe, and linked to the actual report at DOJ). The DOJ web site is hosted on Akamai's CDN. I don't think anyone's had trouble getting to it or downloading the report. I certainly didn't. From amitchell at isipp.com Thu Apr 18 22:27:58 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 18 Apr 2019 16:27:58 -0600 Subject: We have it here, including the conclusions (was Re: Special Counsel Office report web site) In-Reply-To: <20190418220848.17E8420123E7C4@ary.qy> References: <20190418220848.17E8420123E7C4@ary.qy> Message-ID: >> Oops..the link would be helpful, sorry! >> >> We have made the full report available here, including conclusions (full report both embedded by iframe, and linked to the actual report at DOJ). > > The DOJ web site is hosted on Akamai's CDN. I don't think anyone's > had trouble getting to it or downloading the report. I certainly didn't. However I was responding to someone who couldn't get it from B&N. That said, our reason for making it available at TIP was that a) not everyone knows how to find the DOJ site, and more importantly b) to preserve it if/when the DOJ buries it. Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From sean at donelan.com Thu Apr 18 22:44:32 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 18 Apr 2019 18:44:32 -0400 (EDT) Subject: Any technical-network issues? (was Re: Special Counsel Office report web site) In-Reply-To: References: Message-ID: On Wed, 17 Apr 2019, Sean Donelan wrote: > The Special Counsel's report is expected to be posted on its website sometime > between 11 a.m. and noon on Thursday, April 18, 2019. Its been about 7 hours since the report was released on the SCO web site and to the news media. Ignoring the content of the report, and looking only at technical network distribution issues: 1. I did not experience and did not see any reports of network distribution problems. 2. I did not experience and did not see any reports of malicious DDOS or attempts to disrupt the distribution. From r.engehausen at gmail.com Fri Apr 19 05:35:34 2019 From: r.engehausen at gmail.com (Roy) Date: Thu, 18 Apr 2019 22:35:34 -0700 Subject: Any technical-network issues? (was Re: Special Counsel Office report web site) In-Reply-To: References: Message-ID: <59953e3e-ed0c-3679-b418-31779076c8fe@gmail.com> On 4/18/2019 3:44 PM, Sean Donelan wrote: > On Wed, 17 Apr 2019, Sean Donelan wrote: >> The Special Counsel's report is expected to be posted on its website >> sometime between 11 a.m. and noon on Thursday, April 18, 2019. > > Its been about 7 hours since the report was released on the SCO web > site and to the news media.  Ignoring the content of the report, and > looking only at technical network distribution issues: > > 1. I did not experience and did not see any reports of network > distribution problems. > > 2. I did not experience and did not see any reports of malicious DDOS > or attempts to disrupt the distribution. > > I think every news website had a copy: CNN, Fox, Reuters, US Today, MSNBC etc.  Even aljazeera.com and BBC News had copies.  I don't know anyone who used a .gov website. From cscora at apnic.net Fri Apr 19 18:03:28 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Apr 2019 04:03:28 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190419180328.17497C55B5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 20 Apr, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 746957 Prefixes after maximum aggregation (per Origin AS): 286549 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 359606 Total ASes present in the Internet Routing Table: 63934 Prefixes per ASN: 11.68 Origin-only ASes present in the Internet Routing Table: 55016 Origin ASes announcing only one prefix: 23717 Transit ASes present in the Internet Routing Table: 8918 Transit-only ASes present in the Internet Routing Table: 276 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 23 Number of instances of unregistered ASNs: 26 Number of 32-bit ASNs allocated by the RIRs: 26645 Number of 32-bit ASNs visible in the Routing Table: 21734 Prefixes from 32-bit ASNs in the Routing Table: 95335 Number of bogon 32-bit ASNs visible in the Routing Table: 19 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 240 Number of addresses announced to Internet: 2850884224 Equivalent to 169 /8s, 237 /16s and 10 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 249808 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 201295 Total APNIC prefixes after maximum aggregation: 58160 APNIC Deaggregation factor: 3.46 Prefixes being announced from the APNIC address blocks: 198092 Unique aggregates announced from the APNIC address blocks: 82348 APNIC Region origin ASes present in the Internet Routing Table: 9656 APNIC Prefixes per ASN: 20.51 APNIC Region origin ASes announcing only one prefix: 2704 APNIC Region transit ASes present in the Internet Routing Table: 1431 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4654 Number of APNIC addresses announced to Internet: 773909376 Equivalent to 46 /8s, 32 /16s and 235 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 221967 Total ARIN prefixes after maximum aggregation: 104388 ARIN Deaggregation factor: 2.13 Prefixes being announced from the ARIN address blocks: 221005 Unique aggregates announced from the ARIN address blocks: 105318 ARIN Region origin ASes present in the Internet Routing Table: 18431 ARIN Prefixes per ASN: 11.99 ARIN Region origin ASes announcing only one prefix: 6835 ARIN Region transit ASes present in the Internet Routing Table: 1902 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2668 Number of ARIN addresses announced to Internet: 1079461760 Equivalent to 64 /8s, 87 /16s and 71 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 205826 Total RIPE prefixes after maximum aggregation: 98067 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 202113 Unique aggregates announced from the RIPE address blocks: 120064 RIPE Region origin ASes present in the Internet Routing Table: 25995 RIPE Prefixes per ASN: 7.78 RIPE Region origin ASes announcing only one prefix: 11542 RIPE Region transit ASes present in the Internet Routing Table: 3687 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8022 Number of RIPE addresses announced to Internet: 718821248 Equivalent to 42 /8s, 216 /16s and 87 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 96496 Total LACNIC prefixes after maximum aggregation: 21634 LACNIC Deaggregation factor: 4.46 Prefixes being announced from the LACNIC address blocks: 97895 Unique aggregates announced from the LACNIC address blocks: 42364 LACNIC Region origin ASes present in the Internet Routing Table: 8291 LACNIC Prefixes per ASN: 11.81 LACNIC Region origin ASes announcing only one prefix: 2201 LACNIC Region transit ASes present in the Internet Routing Table: 1533 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5842 Number of LACNIC addresses announced to Internet: 173703424 Equivalent to 10 /8s, 90 /16s and 129 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 21349 Total AfriNIC prefixes after maximum aggregation: 4281 AfriNIC Deaggregation factor: 4.99 Prefixes being announced from the AfriNIC address blocks: 27612 Unique aggregates announced from the AfriNIC address blocks: 9289 AfriNIC Region origin ASes present in the Internet Routing Table: 1269 AfriNIC Prefixes per ASN: 21.76 AfriNIC Region origin ASes announcing only one prefix: 435 AfriNIC Region transit ASes present in the Internet Routing Table: 241 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 548 Number of AfriNIC addresses announced to Internet: 104731648 Equivalent to 6 /8s, 62 /16s and 20 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4728 546 551 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4711 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3133 1305 53 VIETEL-AS-AP Viettel Group, VN 45899 3004 1738 112 VNPT-AS-VN VNPT Corp, VN 9829 2734 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2611 11120 762 KIXS-AS-KR Korea Telecom, KR 9808 2448 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2176 4898 27 CTTNET China TieTong Telecommunications 4755 2148 429 185 TATACOMM-AS TATA Communications formerl 9498 2046 427 171 BBIL-AP BHARTI Airtel Ltd., 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 11492 3644 238 587 CABLEONE - CABLE ONE, INC., US 6327 3624 1325 94 SHAW - Shaw Communications Inc., CA 22773 3397 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2657 5908 1110 AMAZON-02 - Amazon.com, Inc., US 16625 2408 1318 1822 AKAMAI-AS - Akamai Technologies, Inc., 30036 2172 356 112 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2149 2751 527 CHARTER-20115 - Charter Communications, 18566 2108 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications 209 2040 5103 576 CENTURYLINK-US-LEGACY-QWEST - CenturyLi Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5437 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3238 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2642 534 1916 AKAMAI-ASN1, US 12389 2236 2222 640 ROSTELECOM-AS, RU 34984 2082 343 539 TELLCOM-AS, TR 9121 1671 1693 19 TTNET, TR 13188 1605 100 47 TRIOLAN, UA 9009 1433 149 784 M247, GB 8402 1250 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5680 3338 598 Uninet S.A. de C.V., MX 10620 3438 537 382 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 7303 1469 1006 255 Telecom Argentina S.A., AR 28573 1366 2248 196 CLARO S.A., BR 6503 1300 433 53 Axtel, S.A.B. de C.V., MX 6147 1246 376 28 Telefonica del Peru S.A.A., PE 3816 1041 507 128 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 955 144 64 Alestra, S. de R.L. de C.V., MX 13999 954 512 241 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1202 393 21 LINKdotNET-AS, EG 37611 896 107 9 Afrihost, ZA 24835 887 646 21 RAYA-AS, EG 36992 841 1531 68 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 708 1731 19 TE-AS TE-AS, EG 29571 494 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5680 3338 598 Uninet S.A. de C.V., MX 12479 5437 1629 140 UNI2-AS, ES 7545 4728 546 551 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4711 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3644 238 587 CABLEONE - CABLE ONE, INC., US 6327 3624 1325 94 SHAW - Shaw Communications Inc., CA 10620 3438 537 382 Telmex Colombia S.A., CO 22773 3397 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3238 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5437 5297 UNI2-AS, ES 4538 4711 4637 ERX-CERNET-BKB China Education and Research Net 7545 4728 4177 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3624 3530 SHAW - Shaw Communications Inc., CA 22773 3397 3236 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3238 3193 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3133 3080 VIETEL-AS-AP Viettel Group, VN 11492 3644 3057 CABLEONE - CABLE ONE, INC., US 10620 3438 3056 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 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 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:37 /11:100 /12:291 /13:568 /14:1136 /15:1908 /16:13369 /17:7968 /18:13899 /19:25644 /20:40186 /21:46265 /22:93440 /23:75950 /24:425109 /25:1065 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4355 5437 UNI2-AS, ES 6327 3398 3624 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2853 3644 CABLEONE - CABLE ONE, INC., US 8551 2692 3238 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2633 3397 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 2003 2108 MEGAPATH5-US - MegaPath Corporation, US 30036 1919 2172 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1754 2086 FRONTIER-FRTR - Frontier Communications of Amer Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1598 2:989 3:6 4:21 5:3103 6:45 7:1 8:1294 9:1 12:1799 13:330 14:1994 15:36 16:4 17:245 18:58 20:50 23:2676 24:2497 25:2 27:2480 31:1977 32:101 35:36 36:850 37:3054 38:1733 39:297 40:121 41:3268 42:775 43:2023 44:150 45:7311 46:3216 47:259 49:1354 50:1108 51:321 52:1015 54:283 55:701 56:6 57:43 58:1791 59:1076 60:507 61:2127 62:2125 63:1823 64:4957 65:2225 66:4835 67:2716 68:1177 69:3510 70:1323 71:615 72:2471 74:2758 75:536 76:543 77:1760 78:1810 79:2280 80:1804 81:1509 82:1125 83:896 84:1128 85:2309 86:510 87:1548 88:1055 89:2579 90:217 91:6565 92:1379 93:2474 94:2531 95:3247 96:930 97:343 98:953 99:393 100:87 101:1162 102:544 103:20984 104:3544 105:252 106:798 107:1780 108:694 109:3730 110:1654 111:1936 112:1477 113:1401 114:1144 115:1715 116:1744 117:1894 118:2180 119:1631 120:1022 121:1041 122:2354 123:1648 124:1473 125:1973 128:1236 129:830 130:534 131:1803 132:786 133:221 134:1091 135:241 136:569 137:742 138:2052 139:866 140:645 141:877 142:802 143:1049 144:847 145:494 146:1269 147:834 148:1720 149:848 150:783 151:1010 152:1059 153:335 154:2811 155:914 156:1629 157:960 158:651 159:1943 160:1584 161:923 162:2750 163:808 164:1194 165:1579 166:448 167:1392 168:3279 169:870 170:4071 171:576 172:1191 173:2216 174:1043 175:915 176:2332 177:4177 178:2534 179:1451 180:2149 181:2429 182:2673 183:1089 184:1504 185:14983 186:3661 187:2463 188:2900 189:1985 190:8303 191:1596 192:10057 193:6654 194:5410 195:4096 196:3139 197:1777 198:5894 199:6006 200:7159 201:5104 202:10414 203:10122 204:4543 205:3028 206:3229 207:3228 208:3957 209:4241 210:3935 211:2009 212:3154 213:2920 214:1100 215:54 216:5930 217:2237 218:883 219:582 220:1855 221:968 222:987 223:1365 End of report From rfg at tristatelogic.com Tue Apr 23 04:28:20 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 22 Apr 2019 21:28:20 -0700 Subject: AS24940 Hetzner -- non-role contact wanted Message-ID: <23295.1555993700@segfault.tristatelogic.com> Subtitle: Another Big Mess On Aisle Thirteen. Somebody Grab The Mop! Just over a month ago, I was here, doing what I always do, bitching and moaning about the low-life trash that is typically allowed to roam free and unfettered on the Internet: https://mailman.nanog.org/pipermail/nanog/2019-March/100135.html Shortly thereafter, it appeared that perhaps that effort on my part had not been a total waste of electrons. The extortion spams stopped, for awhile anyway, and it started to look like Digital Ocean had in fact kicked the perp's as the curb. So, you know, case closed, right? Well, not really. Once this kind of clown gets a taste for the easy money, it's hard to go back to actually washing dishes for a living again. So, you know, HE'S BACK. https://twitter.com/SpamAuditor/status/1120473072354635779 (And for those of you who may want to claim that I'm being sexist, and that I can't know for sure if it is a man or a woman behind this shit, I just have one word: No. Women don't do this shit. Perhaps they have more respect for their fellow humans, or whatever. But the reality is, of all the low-life scumbag spammers that I've ID'd over the past 20+ years... and there have been plenty of them... 99,99% have been men. That's just a fact.) So anyway, based on the current evidence, it's looking like Digital Ocean -may- possibly have actually -tried- to kick this guy off their network, or maybe not. (See below.) It's possible that they just told him that they would be happy to keep on taking his money, but that he just shouldn't spam from their network anymore. I don't really have any way of knowing. They didn't tell me the crook's name, so who the hell knows? In any case, now it appears that this same specific spammer and con-man si now doing his extortion spamming 100% from AS24940 Hetzner. Here is a freshly updated list of all of his spam spewer FQDNs, and the IPv4 addresses that all of them are pointed at right now: https://pastebin.com/raw/3fbACedn If and only if Digital Ocean (AS14061) really did kick this scumbag's ass to the curb... or if they at least tried to do so... then that eliminates all of the IP address shown in the above list that are prefixed with Digital Ocean's ASN (14061) from the ilst, at least as far as outbound spamming is concerned. That would leave us with only the AS24940 Hetzner IP addresses as current live spam spewers: https://pastebin.com/raw/t9Rs4HMT (In case it isn't obvious, I do advise all parties not to accept any incoming email from any of the above listed IPs or domain names until this all gets cleaned up.) Meanwhile, I'd like to get hold of a (non-role) contact email address for any warm body at Hetzner who may actually give a shit about any of this. I understand that this may be a REAL big ask. I have been informed, just today, by a reliable source that fundamentally, Hetzner just doesn't do shit about spam reports sent their way. And anyway, why would they? Apparently, none of the other big hosting providers do anything but ignore the spam reports that are sent to them either. And just as Digital Ocean had done to me one month ago, when I had occasion to send Hetzner a report about some totally unrelated spam that I received, just today, from their network, about 30 seconds later I got back what can only be called an "ignore bot" automated email reply, telling me ... just as Digital Ocean has done to me previously... that while it was perfectly OK with them if their customers spammed my via the medium of email, that there was nontheless no frekin' way that THEY would entertain any reports about that VIA EMAIL. So I was told to fill out some web form on the Hetzner web site, so that Hetzner staff could remain anonymous, and could anonymously receive that report, and then immediately and with all due haste dispatch it forthwith directly to /dev/null. Swell. So, you know, it may not do a bit of good, but I really would like to be able to find out for myself if Hetzner is just totally staffed by mindless robots, utterly lacking in compassion and empathy and also any sense of ethics, or if there is at least one live engineer there... someone with a name and a face and maybe ever a friend or relative who has been conned by one in this endless parade of unaccountable Internet fraudsters. I'd like to find out, in other words, if there is any warm body there who even gives a shit. So, if any fo you who are reading this happen to know any live humans at Hetzner, please do send me their contact info. I am most certainly *not* going to flll out Hetzner's dumb-ass watse-of-my-time web form just for the honor of informing THEM of THEIR freekin't problem child customer, especially guven the high probability that my attempt to report this to them will go straight to the but bucket. I actually don't mind lending a hand to help mega providers like this to clean their own toilets. I do mind however when they go out of their way to make it harder and more tedious and time consuming for me to do that. In fact it would be nice if this entire industry would get its collective head out of its collective ass, recognize that it has an ongoing problem with Bad Actors acquiring "hosting" resources, and figure out a way to deal with that that DOESN'T just involve taking the money and looking the other way, and routinely ignoring all abuse reports. (Ther smaller providers actually deal with this problem much better than the bigger ones. THEY as least are not cowed into utter silence by paranoid and over-protective corporate counsel. So they can and do let one another know when a Bad Actor is out there, roaming the streets, looking for hosting companies to use and abuse. Just search webhostingtalk.com for mentions of "PredictLabs" and you can see for yourselves. This isn't anti-trust. This is self-preservation, which is different, even if a lot of corporate counsel are just too effing stoopid to grasp the important differences between Standard Oil in the year 1900 and a modern Neighborhood Watch group.) Anyway, to return to today's Bad Actor de jure, although it is looking like he is graciously confining his outbound spamming to just AS24940, i.e. Hetzner at the moment, it's apparent that he plans to be around for awhile, even in the unlikely even that anybody at Hetzner should notice what he is doing -or- elect to give a shit about it. So he's done what any Internet user seeking survivability does... he has distributed his name servers over several different networks. Specifically here they all are: 67.215.224.116 ns1.eatshit.xyz 81.4.102.145 ns1.epicdns.xyz 81.17.24.253 ns1.suck-me.xyz 95.179.209.35 ns1.suckmycock.online 142.11.199.11 ns1.privatedns.top 142.93.227.159 ns1.younoob.life 145.14.157.84 ns1.gmail-dns.com 168.235.86.16 ns1.privatedns.rocks 185.158.249.155 ns1.mynameservers.org 185.249.197.6 ns1.fuckdns.org (The ns2. name server in all of these cases is on the same IPv4 address with the ns1. server.) So, even though this guy is likely only spamming from Hetzner at present, he's got his name servers well distributed, as you can see above. Those name server are scattered around on all ofthe following networks (in numerical order): AS3842 US RamNode LLC AS8100 US QuadraNet Enterprises LLC AS14061 US DigitalOcean, LLC AS20473 US Choopa, LLC AS47583 CY Hostinger International Limited AS51852 PA Private Layer INC AS54290 US Hostwinds LLC. AS58329 DE easystores GmbH AS62370 NL Snel.com B.V. AS197071 DE Dennis Rainer Warnholz trading as active-servers.com I would consider it a good day's work if I could get people here on this lest to help me to get some of these name server turned off, and the associated accounts canceled, but I'm probably hoping for too much. Still, I have to ask. Please help if you can. I spent several hours working on this case today. maybe the rest of you could pictch in just long enough to send polite email to one or more of the above networks, just to let them know that they have a problem child as a customer (at the exact addresses listed above). You can send them also a link to this posting in teh NANOG archives also if you like. I don't know if that would help or hurt, but it is worth a try. Anyway, "takedowns" shouldn't only be for botnets. When the Internet does... as it frequently does these days... get this kind of exceptionally annoying AND exceptionally criminal professional spammer, it would be kind of nice if there were some way to get his ass totally turfed from the whole Internet. That seems to have happened in the case of Bitcanal... with a lot of help from a lot of concerned netizens. Why should a case like this be any different? This guy needs to be gone. I'm perfectly OK with me repeatedly -finding- all of his shit, and then reporting it here or elsewhere. (It takes -me- less effort to find it that it takes -him- to set it all up.) The missing part of the puzzle is action, by the relevant providers. So, please help me to do a full takedown on this guy. Please. Thanks for listening. Regards, rfg P.S. I do hope that everyone will have noticed that Digital Ocean is listed above as being among the set of providers that are giving service to one of this dickhead's name servers. I'll give them the benefit of the doubt and try to believe that they really did fully kick this guy to the curb last month, not long after I bitched about him here. Even if that's the case however, he has clearly managed to sneak back on to Digital Ocean's network. So, obvious question: Whose fault is that? About ten years ago I had my one and only European Vacation. I was shocked when, in France, I went to buy a cheap cell phone that would work on French networks and they ASKED ME FOR MY PASSPORT. It wasn't a problem. It just seemed weird because I was unaccustomed to this extra level of security. So, I have to ask: Why does one need to demonstrate one's identity to a greater degree if one buys a simple cell phone, as opposed to, say, buying a hosting account, late on a Friday, after which you may immediately start spamming and then spam one's brains out, to all seven billion people on this planet if desired, before the regular staff at the hosting company even comes back in to work on Monday morning? If there's a universe in which this all makes sense, then all I can say is that I personally am not in that one. From greg.kovich at al-enterprise.com Tue Apr 23 13:19:31 2019 From: greg.kovich at al-enterprise.com (Kovich Greg) Date: Tue, 23 Apr 2019 13:19:31 +0000 Subject: AS24940 Hetzner -- non-role contact wanted In-Reply-To: References: Message-ID: <0891A4D8-2254-4546-B7CD-71EFEE182A20@al-enterprise.com> Hello Ronald, I did a quick search on LinkedIn and found a couple Hetzner internet companies - each had a couple employees listed that I could request a connection with. I love your passion about SPAM - I wish there was a way to stop all the VoIP Spoofing/Spammers… I am certainly tired of hearing that this is the last time I’ll be contacted about an extended car warranty, from a phone number that is not in service. Good luck - and thanks for trying to clean up some of the low-life trash. Regards, Greg ------- Greg Kovich Director, Global Education Sales Alcatel-Lucent Enterprise ALE USA 3015 Abby Lane | Suite 301-B Schererville, IN 46375 t: +1-818-878-4667 m: +1-219-276-2320 e: Greg.Kovich at al-enterprise.com w: www.al-enterprise.com @ALUEnterprise [LinkedIn] [Twitter] [YouTube] [Facebook] [Rainbow] [https://www.al-enterprise.com/en/-/media/assets/internet/images/logo.png] The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. This communication is intended to be received only by the individual or entity to whom or to which it is addressed and may contain information that is privileged/confidential or subject to copyright. Any unauthorized use, copying, review or disclosure of this communication is strictly prohibited. If you have received this communication in error, please delete this message from your e-mail box and information system (including all files and documents attached) and notify the sender by reply email. On Apr 23, 2019, at 7:00 AM, nanog-request at nanog.org wrote: ** External email - Please consider with caution ** Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. AS24940 Hetzner -- non-role contact wanted (Ronald F. Guilmette) ---------------------------------------------------------------------- Message: 1 Date: Mon, 22 Apr 2019 21:28:20 -0700 From: "Ronald F. Guilmette" > To: nanog at nanog.org Subject: AS24940 Hetzner -- non-role contact wanted Message-ID: <23295.1555993700 at segfault.tristatelogic.com> Subtitle: Another Big Mess On Aisle Thirteen. Somebody Grab The Mop! Just over a month ago, I was here, doing what I always do, bitching and moaning about the low-life trash that is typically allowed to roam free and unfettered on the Internet: https://mailman.nanog.org/pipermail/nanog/2019-March/100135.html Shortly thereafter, it appeared that perhaps that effort on my part had not been a total waste of electrons. The extortion spams stopped, for awhile anyway, and it started to look like Digital Ocean had in fact kicked the perp's as the curb. So, you know, case closed, right? Well, not really. Once this kind of clown gets a taste for the easy money, it's hard to go back to actually washing dishes for a living again. So, you know, HE'S BACK. https://twitter.com/SpamAuditor/status/1120473072354635779 (And for those of you who may want to claim that I'm being sexist, and that I can't know for sure if it is a man or a woman behind this shit, I just have one word: No. Women don't do this shit. Perhaps they have more respect for their fellow humans, or whatever. But the reality is, of all the low-life scumbag spammers that I've ID'd over the past 20+ years... and there have been plenty of them... 99,99% have been men. That's just a fact.) So anyway, based on the current evidence, it's looking like Digital Ocean -may- possibly have actually -tried- to kick this guy off their network, or maybe not. (See below.) It's possible that they just told him that they would be happy to keep on taking his money, but that he just shouldn't spam from their network anymore. I don't really have any way of knowing. They didn't tell me the crook's name, so who the hell knows? In any case, now it appears that this same specific spammer and con-man si now doing his extortion spamming 100% from AS24940 Hetzner. Here is a freshly updated list of all of his spam spewer FQDNs, and the IPv4 addresses that all of them are pointed at right now: https://pastebin.com/raw/3fbACedn If and only if Digital Ocean (AS14061) really did kick this scumbag's ass to the curb... or if they at least tried to do so... then that eliminates all of the IP address shown in the above list that are prefixed with Digital Ocean's ASN (14061) from the ilst, at least as far as outbound spamming is concerned. That would leave us with only the AS24940 Hetzner IP addresses as current live spam spewers: https://pastebin.com/raw/t9Rs4HMT (In case it isn't obvious, I do advise all parties not to accept any incoming email from any of the above listed IPs or domain names until this all gets cleaned up.) Meanwhile, I'd like to get hold of a (non-role) contact email address for any warm body at Hetzner who may actually give a shit about any of this. I understand that this may be a REAL big ask. I have been informed, just today, by a reliable source that fundamentally, Hetzner just doesn't do shit about spam reports sent their way. And anyway, why would they? Apparently, none of the other big hosting providers do anything but ignore the spam reports that are sent to them either. And just as Digital Ocean had done to me one month ago, when I had occasion to send Hetzner a report about some totally unrelated spam that I received, just today, from their network, about 30 seconds later I got back what can only be called an "ignore bot" automated email reply, telling me ... just as Digital Ocean has done to me previously... that while it was perfectly OK with them if their customers spammed my via the medium of email, that there was nontheless no frekin' way that THEY would entertain any reports about that VIA EMAIL. So I was told to fill out some web form on the Hetzner web site, so that Hetzner staff could remain anonymous, and could anonymously receive that report, and then immediately and with all due haste dispatch it forthwith directly to /dev/null. Swell. So, you know, it may not do a bit of good, but I really would like to be able to find out for myself if Hetzner is just totally staffed by mindless robots, utterly lacking in compassion and empathy and also any sense of ethics, or if there is at least one live engineer there... someone with a name and a face and maybe ever a friend or relative who has been conned by one in this endless parade of unaccountable Internet fraudsters. I'd like to find out, in other words, if there is any warm body there who even gives a shit. So, if any fo you who are reading this happen to know any live humans at Hetzner, please do send me their contact info. I am most certainly *not* going to flll out Hetzner's dumb-ass watse-of-my-time web form just for the honor of informing THEM of THEIR freekin't problem child customer, especially guven the high probability that my attempt to report this to them will go straight to the but bucket. I actually don't mind lending a hand to help mega providers like this to clean their own toilets. I do mind however when they go out of their way to make it harder and more tedious and time consuming for me to do that. In fact it would be nice if this entire industry would get its collective head out of its collective ass, recognize that it has an ongoing problem with Bad Actors acquiring "hosting" resources, and figure out a way to deal with that that DOESN'T just involve taking the money and looking the other way, and routinely ignoring all abuse reports. (Ther smaller providers actually deal with this problem much better than the bigger ones. THEY as least are not cowed into utter silence by paranoid and over-protective corporate counsel. So they can and do let one another know when a Bad Actor is out there, roaming the streets, looking for hosting companies to use and abuse. Just search webhostingtalk.com for mentions of "PredictLabs" and you can see for yourselves. This isn't anti-trust. This is self-preservation, which is different, even if a lot of corporate counsel are just too effing stoopid to grasp the important differences between Standard Oil in the year 1900 and a modern Neighborhood Watch group.) Anyway, to return to today's Bad Actor de jure, although it is looking like he is graciously confining his outbound spamming to just AS24940, i.e. Hetzner at the moment, it's apparent that he plans to be around for awhile, even in the unlikely even that anybody at Hetzner should notice what he is doing -or- elect to give a shit about it. So he's done what any Internet user seeking survivability does... he has distributed his name servers over several different networks. Specifically here they all are: 67.215.224.116 ns1.eatshit.xyz 81.4.102.145 ns1.epicdns.xyz 81.17.24.253 ns1.suck-me.xyz 95.179.209.35 ns1.suckmycock.online 142.11.199.11 ns1.privatedns.top 142.93.227.159 ns1.younoob.life 145.14.157.84 ns1.gmail-dns.com 168.235.86.16 ns1.privatedns.rocks 185.158.249.155 ns1.mynameservers.org 185.249.197.6 ns1.fuckdns.org (The ns2. name server in all of these cases is on the same IPv4 address with the ns1. server.) So, even though this guy is likely only spamming from Hetzner at present, he's got his name servers well distributed, as you can see above. Those name server are scattered around on all ofthe following networks (in numerical order): AS3842 US RamNode LLC AS8100 US QuadraNet Enterprises LLC AS14061 US DigitalOcean, LLC AS20473 US Choopa, LLC AS47583 CY Hostinger International Limited AS51852 PA Private Layer INC AS54290 US Hostwinds LLC. AS58329 DE easystores GmbH AS62370 NL Snel.com B.V. AS197071 DE Dennis Rainer Warnholz trading as active-servers.com I would consider it a good day's work if I could get people here on this lest to help me to get some of these name server turned off, and the associated accounts canceled, but I'm probably hoping for too much. Still, I have to ask. Please help if you can. I spent several hours working on this case today. maybe the rest of you could pictch in just long enough to send polite email to one or more of the above networks, just to let them know that they have a problem child as a customer (at the exact addresses listed above). You can send them also a link to this posting in teh NANOG archives also if you like. I don't know if that would help or hurt, but it is worth a try. Anyway, "takedowns" shouldn't only be for botnets. When the Internet does... as it frequently does these days... get this kind of exceptionally annoying AND exceptionally criminal professional spammer, it would be kind of nice if there were some way to get his ass totally turfed from the whole Internet. That seems to have happened in the case of Bitcanal... with a lot of help from a lot of concerned netizens. Why should a case like this be any different? This guy needs to be gone. I'm perfectly OK with me repeatedly -finding- all of his shit, and then reporting it here or elsewhere. (It takes -me- less effort to find it that it takes -him- to set it all up.) The missing part of the puzzle is action, by the relevant providers. So, please help me to do a full takedown on this guy. Please. Thanks for listening. Regards, rfg P.S. I do hope that everyone will have noticed that Digital Ocean is listed above as being among the set of providers that are giving service to one of this dickhead's name servers. I'll give them the benefit of the doubt and try to believe that they really did fully kick this guy to the curb last month, not long after I bitched about him here. Even if that's the case however, he has clearly managed to sneak back on to Digital Ocean's network. So, obvious question: Whose fault is that? About ten years ago I had my one and only European Vacation. I was shocked when, in France, I went to buy a cheap cell phone that would work on French networks and they ASKED ME FOR MY PASSPORT. It wasn't a problem. It just seemed weird because I was unaccustomed to this extra level of security. So, I have to ask: Why does one need to demonstrate one's identity to a greater degree if one buys a simple cell phone, as opposed to, say, buying a hosting account, late on a Friday, after which you may immediately start spamming and then spam one's brains out, to all seven billion people on this planet if desired, before the regular staff at the hosting company even comes back in to work on Monday morning? If there's a universe in which this all makes sense, then all I can say is that I personally am not in that one. End of NANOG Digest, Vol 135, Issue 21 ************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Apr 23 17:55:55 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 23 Apr 2019 13:55:55 -0400 Subject: AS24940 Hetzner -- non-role contact wanted In-Reply-To: <0891A4D8-2254-4546-B7CD-71EFEE182A20@al-enterprise.com> References: <0891A4D8-2254-4546-B7CD-71EFEE182A20@al-enterprise.com> Message-ID: Several telcos are working on a project to authenticate calls: https://transnexus.com/whitepapers/understanding-stir-shaken/ AT&T and Comcast have reportedly tested it between their networks. On Tue, Apr 23, 2019 at 9:23 AM Kovich Greg wrote: > Hello Ronald, > > I did a quick search on LinkedIn and found a couple Hetzner internet > companies - each had a couple employees listed that I could request a > connection with. > > I love your passion about SPAM - I wish there was a way to stop all the > VoIP Spoofing/Spammers… I am certainly tired of hearing that this is the > last time I’ll be contacted about an extended car warranty, from a phone > number that is not in service. > > Good luck - and thanks for trying to clean up some of the low-life trash. > > Regards, > Greg > > ------- > > Greg Kovich > Director, Global Education Sales > Alcatel-Lucent Enterprise > ALE USA > 3015 Abby Lane | Suite 301-B > Schererville, IN 46375 > t: +1-818-878-4667 m: +1-219-276-2320 > e: Greg.Kovich at al-enterprise.com w: > www.al-enterprise.com > > @ALUEnterprise > [image: LinkedIn] > [image: > Twitter] [image: YouTube] > [image: Facebook] > [image: Rainbow] > > > > The Alcatel-Lucent name and logo are trademarks of Nokia used under > license by ALE. > This communication is intended to be received only by the individual or > entity to whom or to which it is addressed and may contain information that > is privileged/confidential or subject to copyright. Any unauthorized use, > copying, review or disclosure of this communication is strictly prohibited. > If you have received this communication in error, please delete this > message from your e-mail box and information system (including all files > and documents attached) and notify the sender by reply email. > > > > On Apr 23, 2019, at 7:00 AM, nanog-request at nanog.org wrote: > > > ** External email - Please consider with caution ** > > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. AS24940 Hetzner -- non-role contact wanted (Ronald F. Guilmette) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Apr 2019 21:28:20 -0700 > From: "Ronald F. Guilmette" > To: nanog at nanog.org > Subject: AS24940 Hetzner -- non-role contact wanted > Message-ID: <23295.1555993700 at segfault.tristatelogic.com> > > > Subtitle: Another Big Mess On Aisle Thirteen. Somebody Grab The Mop! > > Just over a month ago, I was here, doing what I always do, bitching > and moaning about the low-life trash that is typically allowed to roam > free and unfettered on the Internet: > > https://mailman.nanog.org/pipermail/nanog/2019-March/100135.html > > Shortly thereafter, it appeared that perhaps that effort on my part had > not been a total waste of electrons. The extortion spams stopped, for > awhile anyway, and it started to look like Digital Ocean had in fact > kicked the perp's as the curb. So, you know, case closed, right? Well, > not really. Once this kind of clown gets a taste for the easy money, > it's hard to go back to actually washing dishes for a living again. So, > you know, HE'S BACK. > > https://twitter.com/SpamAuditor/status/1120473072354635779 > > (And for those of you who may want to claim that I'm being sexist, and > that I can't know for sure if it is a man or a woman behind this shit, > I just have one word: No. Women don't do this shit. Perhaps they > have more respect for their fellow humans, or whatever. But the reality > is, of all the low-life scumbag spammers that I've ID'd over the past 20+ > years... and there have been plenty of them... 99,99% have been men. > That's just a fact.) > > So anyway, based on the current evidence, it's looking like Digital > Ocean -may- possibly have actually -tried- to kick this guy off their > network, or maybe not. (See below.) It's possible that they just told > him that they would be happy to keep on taking his money, but that he > just shouldn't spam from their network anymore. I don't really have > any way of knowing. They didn't tell me the crook's name, so who the > hell knows? > > In any case, now it appears that this same specific spammer and con-man > si now doing his extortion spamming 100% from AS24940 Hetzner. Here is > a freshly updated list of all of his spam spewer FQDNs, and the IPv4 > addresses that all of them are pointed at right now: > > https://pastebin.com/raw/3fbACedn > > If and only if Digital Ocean (AS14061) really did kick this scumbag's > ass to the curb... or if they at least tried to do so... then that > eliminates all of the IP address shown in the above list that are > prefixed with Digital Ocean's ASN (14061) from the ilst, at least as > far as outbound spamming is concerned. That would leave us with only > the AS24940 Hetzner IP addresses as current live spam spewers: > > https://pastebin.com/raw/t9Rs4HMT > > (In case it isn't obvious, I do advise all parties not to accept any > incoming email from any of the above listed IPs or domain names until > this all gets cleaned up.) > > Meanwhile, I'd like to get hold of a (non-role) contact email address > for any warm body at Hetzner who may actually give a shit about any of > this. I understand that this may be a REAL big ask. I have been > informed, just today, by a reliable source that fundamentally, Hetzner > just doesn't do shit about spam reports sent their way. > > And anyway, why would they? Apparently, none of the other big hosting > providers do anything but ignore the spam reports that are sent to them > either. And just as Digital Ocean had done to me one month ago, when I had > occasion to send Hetzner a report about some totally unrelated spam that > I received, just today, from their network, about 30 seconds later I got > back what can only be called an "ignore bot" automated email reply, telling > me ... just as Digital Ocean has done to me previously... that while it > was perfectly OK with them if their customers spammed my via the medium > of email, that there was nontheless no frekin' way that THEY would > entertain > any reports about that VIA EMAIL. So I was told to fill out some web form > on the Hetzner web site, so that Hetzner staff could remain anonymous, and > could anonymously receive that report, and then immediately and with all > due haste dispatch it forthwith directly to /dev/null. Swell. > > So, you know, it may not do a bit of good, but I really would like to be > able to find out for myself if Hetzner is just totally staffed by mindless > robots, utterly lacking in compassion and empathy and also any sense of > ethics, or if there is at least one live engineer there... someone with > a name and a face and maybe ever a friend or relative who has been conned > by one in this endless parade of unaccountable Internet fraudsters. I'd > like to find out, in other words, if there is any warm body there who even > gives a shit. > > So, if any fo you who are reading this happen to know any live humans at > Hetzner, please do send me their contact info. I am most certainly > *not* going to flll out Hetzner's dumb-ass watse-of-my-time web form just > for the honor of informing THEM of THEIR freekin't problem child customer, > especially guven the high probability that my attempt to report this to > them will go straight to the but bucket. > > I actually don't mind lending a hand to help mega providers like this to > clean their own toilets. I do mind however when they go out of their way > to make it harder and more tedious and time consuming for me to do that. > > In fact it would be nice if this entire industry would get its collective > head out of its collective ass, recognize that it has an ongoing problem > with Bad Actors acquiring "hosting" resources, and figure out a way to > deal with that that DOESN'T just involve taking the money and looking > the other way, and routinely ignoring all abuse reports. (Ther smaller > providers actually deal with this problem much better than the bigger ones. > THEY as least are not cowed into utter silence by paranoid and > over-protective > corporate counsel. So they can and do let one another know when a Bad > Actor > is out there, roaming the streets, looking for hosting companies to use and > abuse. Just search webhostingtalk.com for mentions of "PredictLabs" and > you can see for yourselves. This isn't anti-trust. This is > self-preservation, > which is different, even if a lot of corporate counsel are just too effing > stoopid to grasp the important differences between Standard Oil in the year > 1900 and a modern Neighborhood Watch group.) > > Anyway, to return to today's Bad Actor de jure, although it is looking > like he is graciously confining his outbound spamming to just AS24940, > i.e. Hetzner at the moment, it's apparent that he plans to be around for > awhile, even in the unlikely even that anybody at Hetzner should notice > what he is doing -or- elect to give a shit about it. So he's done what > any Internet user seeking survivability does... he has distributed his > name servers over several different networks. Specifically here they > all are: > > 67.215.224.116 ns1.eatshit.xyz > 81.4.102.145 ns1.epicdns.xyz > 81.17.24.253 ns1.suck-me.xyz > 95.179.209.35 ns1.suckmycock.online > 142.11.199.11 ns1.privatedns.top > 142.93.227.159 ns1.younoob.life > 145.14.157.84 ns1.gmail-dns.com > 168.235.86.16 ns1.privatedns.rocks > 185.158.249.155 ns1.mynameservers.org > 185.249.197.6 ns1.fuckdns.org > > (The ns2. name server in all of these cases is on the same IPv4 address > with the ns1. server.) > > So, even though this guy is likely only spamming from Hetzner at present, > he's got his name servers well distributed, as you can see above. Those > name server are scattered around on all ofthe following networks (in > numerical order): > > AS3842 US RamNode LLC > AS8100 US QuadraNet Enterprises LLC > AS14061 US DigitalOcean, LLC > AS20473 US Choopa, LLC > AS47583 CY Hostinger International Limited > AS51852 PA Private Layer INC > AS54290 US Hostwinds LLC. > AS58329 DE easystores GmbH > AS62370 NL Snel.com B.V. > AS197071 DE Dennis Rainer Warnholz trading as active-servers.com > > I would consider it a good day's work if I could get people here on this > lest to help me to get some of these name server turned off, and the > associated accounts canceled, but I'm probably hoping for too much. > Still, I have to ask. Please help if you can. I spent several hours > working on this case today. maybe the rest of you could pictch in just > long enough to send polite email to one or more of the above networks, > just to let them know that they have a problem child as a customer > (at the exact addresses listed above). You can send them also a link > to this posting in teh NANOG archives also if you like. I don't know > if that would help or hurt, but it is worth a try. > > Anyway, "takedowns" shouldn't only be for botnets. When the Internet > does... as it frequently does these days... get this kind of exceptionally > annoying AND exceptionally criminal professional spammer, it would be > kind of nice if there were some way to get his ass totally turfed from > the whole Internet. That seems to have happened in the case of Bitcanal... > with a lot of help from a lot of concerned netizens. Why should a case > like this be any different? This guy needs to be gone. I'm perfectly > OK with me repeatedly -finding- all of his shit, and then reporting it > here or elsewhere. (It takes -me- less effort to find it that it takes > -him- to set it all up.) The missing part of the puzzle is action, by > the relevant providers. > > So, please help me to do a full takedown on this guy. Please. > > Thanks for listening. > > > Regards, > rfg > > > P.S. I do hope that everyone will have noticed that Digital Ocean is > listed above as being among the set of providers that are giving service > to one of this dickhead's name servers. I'll give them the benefit of > the doubt and try to believe that they really did fully kick this guy > to the curb last month, not long after I bitched about him here. Even > if that's the case however, he has clearly managed to sneak back on to > Digital Ocean's network. > > So, obvious question: Whose fault is that? > > About ten years ago I had my one and only European Vacation. I was shocked > when, in France, I went to buy a cheap cell phone that would work on French > networks and they ASKED ME FOR MY PASSPORT. It wasn't a problem. It just > seemed weird because I was unaccustomed to this extra level of security. > > So, I have to ask: Why does one need to demonstrate one's identity to a > greater degree if one buys a simple cell phone, as opposed to, say, buying > a hosting account, late on a Friday, after which you may immediately start > spamming and then spam one's brains out, to all seven billion people on > this > planet if desired, before the regular staff at the hosting company even > comes > back in to work on Monday morning? > > If there's a universe in which this all makes sense, then all I can say is > that I personally am not in that one. > > > End of NANOG Digest, Vol 135, Issue 21 > ************************************** > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dovid at telecurve.com Tue Apr 23 19:55:43 2019 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 23 Apr 2019 15:55:43 -0400 Subject: OffTopic: Telecom Fraud Message-ID: Hi All, I am wondering if a bit of public shaming may help. I every so often get calls from the "verizon wireless fraud prevention dept". It's scammers calling me (and others) telling them there was fraud on their account. This gets people worked up and fooled into giving out data that they normally wouldn't. This allows the fraudsters to then order devices under the victims name. They spoof their caller ID to that of Verizons. I understand there is currently no fix (though lets hope that SHAKEN/STIR fixes it one day). but at the very least why can't Verizon drop these calls at their edge. If they see the B-Number as being their client and the A number being theirs but coming from elsewhere why can't they just drop the call? If anyone has any insight I would love to hear it. TIA. Regards, Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Tue Apr 23 20:13:57 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 23 Apr 2019 16:13:57 -0400 Subject: OffTopic: Telecom Fraud In-Reply-To: References: Message-ID: <22712.1556050437@turing-police> On Tue, 23 Apr 2019 15:55:43 -0400, Dovid Bender said: > day). but at the very least why can't Verizon drop these calls at their > edge. If they see the B-Number as being their client and the A number being > theirs but coming from elsewhere why can't they just drop the call? Probably for the same exact reasons why BCP38 isn't more widely deployed. From paul at telcodata.us Tue Apr 23 20:14:25 2019 From: paul at telcodata.us (Paul Timmins) Date: Tue, 23 Apr 2019 16:14:25 -0400 Subject: OffTopic: Telecom Fraud In-Reply-To: References: Message-ID: I guarantee you that if carriers were made civilly or criminally liable for allowing robodialers to operate on their network, this sort of issue would end practically overnight. Robodialer calling patterns are obvious, and I'd imagine any tech could give you a criteria to search for in the CDR streams to identify them and shut them off in hours. Problem is, they're lucrative to provide services to, and there is immunity on the carrier's part to these sorts of issues. SHAKEN/STIR nonwithstanding (I don't think we'll see widespread adoption of this within a decade, even with a government mandate as there's still a massive embedded base of switches that can't support it and never will). It may be incredibly frustrating, but there's plenty of money to be made in prolonging the problem. -Paul On 4/23/19 3:55 PM, Dovid Bender wrote: > Hi All, > > I am wondering if a bit of public shaming may help. I every so often > get calls from the "verizon wireless fraud prevention dept". It's > scammers calling me (and others) telling them there was fraud on their > account. This gets people worked up and fooled into giving out data > that they normally wouldn't. This allows the fraudsters to then order > devices under the victims name. They spoof their caller ID to that of > Verizons. I understand there is currently no fix (though lets hope > that SHAKEN/STIR fixes it one day). but at the very least why can't > Verizon drop these calls at their edge. If they see the B-Number as > being their client and the A number being theirs but coming from > elsewhere why can't they just drop the call? > > If anyone has any insight I would love to hear it. > > TIA. > > Regards, > > Dovid > From dovid at telecurve.com Tue Apr 23 20:23:23 2019 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 23 Apr 2019 16:23:23 -0400 Subject: OffTopic: Telecom Fraud In-Reply-To: References: Message-ID: On Tue, Apr 23, 2019 at 4:18 PM Paul Timmins wrote: > I guarantee you that if carriers were made civilly or criminally liable > for allowing robodialers to operate on their network, this sort of issue > would end practically overnight. Robodialer calling patterns are > obvious, and I'd imagine any tech could give you a criteria to search > for in the CDR streams to identify them and shut them off in hours. > > Problem is, they're lucrative to provide services to, and there is > immunity on the carrier's part to these sorts of issues. SHAKEN/STIR > nonwithstanding (I don't think we'll see widespread adoption of this > within a decade, even with a government mandate as there's still a > massive embedded base of switches that can't support it and never will). > > It may be incredibly frustrating, but there's plenty of money to be made > in prolonging the problem. > > That was my thought as well. From what I heard last 50% of the calls are fraud. That's a lot of money that they are collecting on origination. I also saw this https://www.multichannel.com/news/comcast-and-att-test-anti-robocalling-tech and did a test. A client owned a Comcast number and had ATT. I set the CLI to the Comcast number and it showed up on the ATT phone as I set it. You would think if ATT had the tools in place at the very least it wouldn't display the number. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Apr 23 20:53:28 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 23 Apr 2019 20:53:28 +0000 Subject: OffTopic: Telecom Fraud In-Reply-To: References: , Message-ID: Dovid, You are correct that your message is off topic. I respectfully ask that you honor the rules of this mailing list and refrain from off topic posts. They simply add noise to an otherwise useful and highly germane experts resource. -mel beckman On Apr 23, 2019, at 1:24 PM, Dovid Bender > wrote: On Tue, Apr 23, 2019 at 4:18 PM Paul Timmins > wrote: I guarantee you that if carriers were made civilly or criminally liable for allowing robodialers to operate on their network, this sort of issue would end practically overnight. Robodialer calling patterns are obvious, and I'd imagine any tech could give you a criteria to search for in the CDR streams to identify them and shut them off in hours. Problem is, they're lucrative to provide services to, and there is immunity on the carrier's part to these sorts of issues. SHAKEN/STIR nonwithstanding (I don't think we'll see widespread adoption of this within a decade, even with a government mandate as there's still a massive embedded base of switches that can't support it and never will). It may be incredibly frustrating, but there's plenty of money to be made in prolonging the problem. That was my thought as well. From what I heard last 50% of the calls are fraud. That's a lot of money that they are collecting on origination. I also saw this https://www.multichannel.com/news/comcast-and-att-test-anti-robocalling-tech and did a test. A client owned a Comcast number and had ATT. I set the CLI to the Comcast number and it showed up on the ATT phone as I set it. You would think if ATT had the tools in place at the very least it wouldn't display the number. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Apr 23 20:58:12 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 23 Apr 2019 20:58:12 +0000 Subject: OffTopic: Telecom Fraud In-Reply-To: References: , , Message-ID: <2F3A2EFD-A8AA-4CA4-B0DF-25D2BA8CFE80@beckman.org> From the NANOG mailing list FAQ: “You can help keep NANOG's signal-to-noise ratio high by subscribing to the nanog-offtopic at lists.blank.org list, and migrating digressive conversations there. To subscribe, send mail to nanog-offtopic-subscribe at lists.blank.org and reply to the confirm message it will generate.” -mel via cell On Apr 23, 2019, at 1:53 PM, Mel Beckman > wrote: Dovid, You are correct that your message is off topic. I respectfully ask that you honor the rules of this mailing list and refrain from off topic posts. They simply add noise to an otherwise useful and highly germane experts resource. -mel beckman On Apr 23, 2019, at 1:24 PM, Dovid Bender > wrote: On Tue, Apr 23, 2019 at 4:18 PM Paul Timmins > wrote: I guarantee you that if carriers were made civilly or criminally liable for allowing robodialers to operate on their network, this sort of issue would end practically overnight. Robodialer calling patterns are obvious, and I'd imagine any tech could give you a criteria to search for in the CDR streams to identify them and shut them off in hours. Problem is, they're lucrative to provide services to, and there is immunity on the carrier's part to these sorts of issues. SHAKEN/STIR nonwithstanding (I don't think we'll see widespread adoption of this within a decade, even with a government mandate as there's still a massive embedded base of switches that can't support it and never will). It may be incredibly frustrating, but there's plenty of money to be made in prolonging the problem. That was my thought as well. From what I heard last 50% of the calls are fraud. That's a lot of money that they are collecting on origination. I also saw this https://www.multichannel.com/news/comcast-and-att-test-anti-robocalling-tech and did a test. A client owned a Comcast number and had ATT. I set the CLI to the Comcast number and it showed up on the ATT phone as I set it. You would think if ATT had the tools in place at the very least it wouldn't display the number. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at nipper.de Tue Apr 23 21:31:32 2019 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 23 Apr 2019 23:31:32 +0200 Subject: [FYI] Call for Presentations European Peering Forum 14 (EPF14) // NANOG Message-ID: Dear Community This is the Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee . Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1486607564933665/ Best regards Arnold -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From ximaera at gmail.com Tue Apr 23 23:46:36 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 24 Apr 2019 02:46:36 +0300 Subject: Comcast storing WiFi passwords in cleartext? Message-ID: Hi NANOG, Here's an issue raised today: https://security.stackexchange.com/questions/207895/how-does-comcast-know-my-wifi-password Apparently there's a concern with customers that their seemingly private passphrases, entered in their own boxes, are being shared with the upstream ISP without an explicit customer consent, and are kept in the ISP database for an unspecified period of time. Is it there by design? if so, then maybe some tweaks are necessary? -- Töma From sethm at rollernet.us Wed Apr 24 00:06:00 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 23 Apr 2019 17:06:00 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> On 4/23/19 16:46, Töma Gavrichenkov wrote: > Apparently there's a concern with customers that their seemingly > private passphrases, entered in their own boxes, are being shared with > the upstream ISP without an explicit customer consent, and are kept in > the ISP database for an unspecified period of time. Is it there by > design? > > if so, then maybe some tweaks are necessary? Don't use the built in wifi AP on a cable modem combo would be my first reaction. ~Seth From ximaera at gmail.com Wed Apr 24 00:32:39 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 24 Apr 2019 03:32:39 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> Message-ID: On Wed, Apr 24, 2019 at 3:07 AM Seth Mattinen wrote: > Don't use the built in wifi AP on a cable modem combo would be my first > reaction. Totally correct, but that's what s/he claims to have already taken care of! -- Töma From laurentfdumont at gmail.com Wed Apr 24 01:03:19 2019 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Tue, 23 Apr 2019 21:03:19 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> Message-ID: It's not exactly clear from the StackExchange post but if the end-user is also using Comcast as an ISP, then I guess the modem simply re-registered under the new customer and is happily providing the visibility to Comcast? On Tue, Apr 23, 2019 at 8:34 PM Töma Gavrichenkov wrote: > On Wed, Apr 24, 2019 at 3:07 AM Seth Mattinen wrote: > > Don't use the built in wifi AP on a cable modem combo would be my first > > reaction. > > Totally correct, but that's what s/he claims to have already taken care of! > > -- > Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lguillory at reservetele.com Wed Apr 24 01:21:46 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 24 Apr 2019 01:21:46 +0000 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> , Message-ID: <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> OP said they logged into their account and went to the security portion of the portal. So one can assume they're the ISP or I don’t see the point in asking how Comcast would know the info. Luke Ns Sent from my iPad On Apr 23, 2019, at 8:05 PM, Laurent Dumont > wrote: It's not exactly clear from the StackExchange post but if the end-user is also using Comcast as an ISP, then I guess the modem simply re-registered under the new customer and is happily providing the visibility to Comcast? On Tue, Apr 23, 2019 at 8:34 PM Töma Gavrichenkov > wrote: On Wed, Apr 24, 2019 at 3:07 AM Seth Mattinen > wrote: > Don't use the built in wifi AP on a cable modem combo would be my first > reaction. Totally correct, but that's what s/he claims to have already taken care of! -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From beckman at angryox.com Wed Apr 24 02:13:55 2019 From: beckman at angryox.com (Peter Beckman) Date: Tue, 23 Apr 2019 22:13:55 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> , <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> Message-ID: On Wed, 24 Apr 2019, Luke Guillory wrote: > OP said they logged into their account and went to the security portion > of the portal. So one can assume they're the ISP or I don’t see the point > in asking how Comcast would know the info. It is entirely possible that an account separate and hidden from the customer account would be able to access the administrative controls of the router. It is also plausible that the access does not use a username/password to authenticate but another, hopefully secure method. One could make this access secure by: 1. Ensuring any connection originated from Company-controlled IP space 2. Username/Password are not provided to the CS agent but is merely a button they press, after properly authenticating themselves as well as authenticating the customer, that would pass a one-time use token to access the device 3. Every token use was logged and regularly audited 4. Keys were regularly and in an automated fashion rotated, maybe even daily If such precautions are taken, it is their router and it is their service, seems reasonable that Comcast should be able to log into their router and change configs. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From beckman at angryox.com Wed Apr 24 02:35:04 2019 From: beckman at angryox.com (Peter Beckman) Date: Tue, 23 Apr 2019 22:35:04 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> , <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> Message-ID: On Tue, 23 Apr 2019, Peter Beckman wrote: > On Wed, 24 Apr 2019, Luke Guillory wrote: > >> OP said they logged into their account and went to the security portion >> of the portal. So one can assume they're the ISP or I don’t see the point >> in asking how Comcast would know the info. > > It is entirely possible that an account separate and hidden from the > customer account would be able to access the administrative controls of the > router. It is also plausible that the access does not use a > username/password to authenticate but another, hopefully secure method. > > One could make this access secure by: > > 1. Ensuring any connection originated from Company-controlled IP space > 2. Username/Password are not provided to the CS agent but is merely a > button they press, after properly authenticating themselves as well > as authenticating the customer, that would pass a one-time use > token to access the device > 3. Every token use was logged and regularly audited > 4. Keys were regularly and in an automated fashion rotated, maybe even > daily > > If such precautions are taken, it is their router and it is their service, > seems reasonable that Comcast should be able to log into their router and > change configs. ... such that the access of the Wifi Password which is likely stored in plain text on the router is accessed by Comcast in a secure manner and not stored in plain text in their internal databases. But I'm guessing probably it's just cached in plain text in their internal DBs. Get your own router if you're worried about your Wifi Password being known by Comcast. Or change to WPA2 Enterprise, but I'm guessing that isn't supported on the router... --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From yang.yu.list at gmail.com Wed Apr 24 03:01:14 2019 From: yang.yu.list at gmail.com (Yang Yu) Date: Tue, 23 Apr 2019 20:01:14 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: On Tue, Apr 23, 2019 at 4:48 PM Töma Gavrichenkov wrote: > Apparently there's a concern with customers that their seemingly > private passphrases, entered in their own boxes, are being shared with > the upstream ISP without an explicit customer consent, and are kept in > the ISP database for an unspecified period of time. Is it there by > design? Not sure what the concern is here. Cable model with builtin WiFi (managed WiFi) is part of the service you signed up for and you are free to use your own WiFi solutions. Chances are the CPE is rented from ISP... Are you expecting the passphrase to get stored as a one way hash? Arris Touchstone has TR-069 connecting to ACS for configuration/management. This platform is ridiculously insecure and the web interface essentially does SNMP read/write over HTTP. https://w00tsec.blogspot.com/2015/11/arris-cable-modem-has-backdoor-in.html From morrowc.lists at gmail.com Wed Apr 24 03:05:52 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Apr 2019 23:05:52 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> Message-ID: On Tue, Apr 23, 2019 at 10:35 PM Peter Beckman wrote: > ... such that the access of the Wifi Password which is likely stored in > plain text on the router is accessed by Comcast in a secure manner and not you've seen TR-069 right? :( From lguillory at reservetele.com Wed Apr 24 03:32:52 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 24 Apr 2019 03:32:52 +0000 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> , <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Yes it's in the router, accessed via the following MIB. Name arrisRouterWPAPreSharedKey OID .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2 MIB ARRIS-ROUTER-DEVICE-MIB Syntax OCTET STRING (SIZE (8..64)) Access read-write Status current Descri Sets the WPA Pre-Shared Key (PSK) used by this service set. This value MUST be either a 64 byte hexadecimal number, OR an 8 to 63 character ASCII string. Which returns the following. OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10004 Value: F2414322EE3D9263 Type: OctetString OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10003 Value: F2414322EE3D9263 Type: OctetString OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10002 Value: F2414322EE3D9263 Type: OctetString OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10001 Value: F2414322EE3D9263 Type: OctetString Ns -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Tuesday, April 23, 2019 9:35 PM To: Luke Guillory Cc: Laurent Dumont; NANOG Subject: Re: Comcast storing WiFi passwords in cleartext? On Tue, 23 Apr 2019, Peter Beckman wrote: > On Wed, 24 Apr 2019, Luke Guillory wrote: > >> OP said they logged into their account and went to the security >> portion of the portal. So one can assume they're the ISP or I don’t >> see the point in asking how Comcast would know the info. > > It is entirely possible that an account separate and hidden from the > customer account would be able to access the administrative controls > of the router. It is also plausible that the access does not use a > username/password to authenticate but another, hopefully secure method. > > One could make this access secure by: > > 1. Ensuring any connection originated from Company-controlled IP space > 2. Username/Password are not provided to the CS agent but is merely a > button they press, after properly authenticating themselves as well > as authenticating the customer, that would pass a one-time use > token to access the device > 3. Every token use was logged and regularly audited > 4. Keys were regularly and in an automated fashion rotated, maybe even > daily > > If such precautions are taken, it is their router and it is their > service, seems reasonable that Comcast should be able to log into > their router and change configs. ... such that the access of the Wifi Password which is likely stored in plain text on the router is accessed by Comcast in a secure manner and not stored in plain text in their internal databases. But I'm guessing probably it's just cached in plain text in their internal DBs. Get your own router if you're worried about your Wifi Password being known by Comcast. Or change to WPA2 Enterprise, but I'm guessing that isn't supported on the router... --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From karsten_thomann at linfre.de Wed Apr 24 08:32:23 2019 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Wed, 24 Apr 2019 01:32:23 -0700 (PDT) Subject: Cisco SCTP response packet from global instead of vrf Message-ID: <4277545.5UVyRhzKDD@linne> Hello, I've an interessting problem I've never saw before. We have two Routers (19xx and 4451) with the same configuration design: Dialer 1 and 1 LAN Interface in global table with default route over the LAN Dialer 2 and 1 LAN Interface in vrf internet, default via dialer 2 towards the core. The router is receiving a SCTP packet destined to the dialer 2 IP and sends a response packet not via the expected dialer 2 interface within the internet vrf where it was received, but sends it via the default route in global table... Does anyone know why the response is send from another routing table? The configuration is pretty basic without any leaking, just a global table for a vpn service and an internet vrf for an internet connection. Thanks in Advance Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott.helms at gmail.com Wed Apr 24 12:23:45 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Wed, 24 Apr 2019 08:23:45 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Message-ID: While it's correct that it's stored in the vendor proprietary MIB this information is commonly retrieved from the CableLabs standard MIB and via TR-181 in DSL and FTTH gear. I wrote up an answer on the security forum originally refereneced, but for convenience here is the same text. The PSK passphrase is (by design) stored in a retrievable format by the Modem vendor, in this case Arris, but the same standard is supported by many other modem vendors. In DOCSIS cable modems this is most commonly done via SNMP against this specific OID: clabWIFIAccessPointSecurityKeyPassphrase OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..63)) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is defined in TR-181 Device.WiFi.AccessPoint{i}.Security.KeyPassphrase." REFERENCE "TR-181 Device Data Model for TR-069." ::= {clabWIFIAccessPointSecurityEntry 5 This is part of the CableLabs WiFi MIB: http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt Which is is in turn based on the TR-069 sub-standard of TR-181: https://cwmp-data-models.broadband-forum.org/tr-181-2-11-0.html#D.Device:2.Device.WiFi.AccessPoint .{i}.Security.KeyPassphrase http://www.broadband-forum.org/download/TR-181_Issue-2_Amendment-2.pdf Not only does this apply to cable modems, but many DSL and FTTH endpoints will also allow the service provider to retrieve your PSK passphrases and a litany of other settings. This allows for end users to have their settings backed up in case of a device having to be replaced or much more commonly for call centers to be able to retrieve some of the settings, like the pass phrase, when a customer calls in because they can't remember it. Scott Helms On Tue, Apr 23, 2019 at 11:34 PM Luke Guillory wrote: > Yes it's in the router, accessed via the following MIB. > > > > Name arrisRouterWPAPreSharedKey > OID .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2 > MIB ARRIS-ROUTER-DEVICE-MIB > Syntax OCTET STRING (SIZE (8..64)) > Access read-write > Status current > > Descri Sets the WPA Pre-Shared Key (PSK) used by this service set. This > value MUST be either a 64 byte hexadecimal number, OR an 8 > to 63 > character ASCII string. > > > Which returns the following. > > > OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10004 > Value: F2414322EE3D9263 > Type: OctetString > > OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10003 > Value: F2414322EE3D9263 > Type: OctetString > > OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10002 > Value: F2414322EE3D9263 > Type: OctetString > > OID: .1.3.6.1.4.1.4115.1.20.1.1.3.26.1.2.10001 > Value: F2414322EE3D9263 > Type: OctetString > > > > > > Ns > > > > > > > > -----Original Message----- > From: Peter Beckman [mailto:beckman at angryox.com] > Sent: Tuesday, April 23, 2019 9:35 PM > To: Luke Guillory > Cc: Laurent Dumont; NANOG > Subject: Re: Comcast storing WiFi passwords in cleartext? > > On Tue, 23 Apr 2019, Peter Beckman wrote: > > > On Wed, 24 Apr 2019, Luke Guillory wrote: > > > >> OP said they logged into their account and went to the security > >> portion of the portal. So one can assume they're the ISP or I don’t > >> see the point in asking how Comcast would know the info. > > > > It is entirely possible that an account separate and hidden from the > > customer account would be able to access the administrative controls > > of the router. It is also plausible that the access does not use a > > username/password to authenticate but another, hopefully secure method. > > > > One could make this access secure by: > > > > 1. Ensuring any connection originated from Company-controlled IP space > > 2. Username/Password are not provided to the CS agent but is merely a > > button they press, after properly authenticating themselves as > well > > as authenticating the customer, that would pass a one-time use > > token to access the device > > 3. Every token use was logged and regularly audited > > 4. Keys were regularly and in an automated fashion rotated, maybe even > > daily > > > > If such precautions are taken, it is their router and it is their > > service, seems reasonable that Comcast should be able to log into > > their router and change configs. > > ... such that the access of the Wifi Password which is likely stored in > plain text on the router is accessed by Comcast in a secure manner and not > stored in plain text in their internal databases. > > But I'm guessing probably it's just cached in plain text in their internal > DBs. > > Get your own router if you're worried about your Wifi Password being known > by Comcast. Or change to WPA2 Enterprise, but I'm guessing that isn't > supported on the router... > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Wed Apr 24 12:26:41 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Wed, 24 Apr 2019 08:26:41 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Message-ID: I don’t really see the issue here. What was the concern of the O. P. ? That a Comcast tech will know your Wifi password? If you’re really running something that requires that kind of security you may want to get your own wireless access point. Otherwise, that’s just how it works for a multitude of reasons. From lguillory at reservetele.com Wed Apr 24 12:58:45 2019 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 24 Apr 2019 12:58:45 +0000 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5F107@RTC-EXCH01.RESERVE.LDS> Matt, I believe the thought process is that if I'm not renting the device from the MSO, why would they log said info. As Scott said, there can be many reasons as to why they would grab it and add to the users account. Same as making sure modems, whether that's MSO owned or customer owned are on the latest firmware. Luke Ns -----Original Message----- From: Matt Hoppes [mailto:mattlists at rivervalleyinternet.net] Sent: Wednesday, April 24, 2019 7:27 AM To: K. Scott Helms Cc: Luke Guillory; NANOG Subject: Re: Comcast storing WiFi passwords in cleartext? I don’t really see the issue here. What was the concern of the O. P. ? That a Comcast tech will know your Wifi password? If you’re really running something that requires that kind of security you may want to get your own wireless access point. Otherwise, that’s just how it works for a multitude of reasons. From ximaera at gmail.com Wed Apr 24 13:27:02 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 24 Apr 2019 16:27:02 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Message-ID: On Wed, Apr 24, 2019 at 3:27 PM Matt Hoppes wrote: > If you’re really running something that requires that kind > of security you may want to get your own wireless access point. Like I said: the OP claims that's what s/he did. -- Töma From Bryan at bryanfields.net Wed Apr 24 14:17:32 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 24 Apr 2019 10:17:32 -0400 Subject: who attacks the weather channel? In-Reply-To: <2FCEF7C7-46DF-4B64-9946-7FCFA053374D@isipp.com> References: <425baa9949074ee1b1c2b2c917e3c689@ford.com> <20190418152619.wusrant6vx5fpoeb@nic.fr> <072dab3a-0bd5-1b00-0e2c-b6bbb9da5fac@finchhaven.com> <2FCEF7C7-46DF-4B64-9946-7FCFA053374D@isipp.com> Message-ID: <56d2af51-8d0a-d8bc-323b-a3b7ad7f1e25@bryanfields.net> On 4/18/19 2:36 PM, Anne P. Mitchell, Esq. wrote: > I not only got it, my best friend in junior high's father was president of SDS. I know one of the authors of the Port Huron Statement. The original Port Huron Statement, not the compromised second draft. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From beecher at beecher.cc Wed Apr 24 14:24:03 2019 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 24 Apr 2019 10:24:03 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Message-ID: The Stackexchange post does NOT say that they got their own AP. It says they got their own DOCSIS Modem / Router / Wifi combo device. That's an important distinction. When I worked at Adelphia many years ago, the only distinction between customer owned CPE and company owned CPE was billing. All modems received the same DOCSIS config file when they booted up. While I have not worked in that industry for many years now, from what I am aware of the same behavior still applies. The modem management and configuration is 100% in the hands of the MSO. This is why, in my opinion, people should avoid modem/router combo units whenever possible. Any information/configuration entered into such a device could be accessible to the MSO (intentionally or otherwise) , as is happening here. I'm sure they would come back and say this is necessary to provide support for customers who pay them for WiFi service, but it clearly shows they don't turn off that functionality for customers who don't. Treat you cable modems as foreign network elements. Cause that's what they are. On Wed, Apr 24, 2019 at 9:28 AM Töma Gavrichenkov wrote: > On Wed, Apr 24, 2019 at 3:27 PM Matt Hoppes > wrote: > > If you’re really running something that requires that kind > > of security you may want to get your own wireless access point. > > Like I said: the OP claims that's what s/he did. > > -- > Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Wed Apr 24 14:33:10 2019 From: randy at psg.com (Randy Bush) Date: Wed, 24 Apr 2019 07:33:10 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> Message-ID: > you've seen TR-069 right? that was 2004, security had not been invented yet. oh wait. From list at satchell.net Wed Apr 24 15:49:49 2019 From: list at satchell.net (Stephen Satchell) Date: Wed, 24 Apr 2019 08:49:49 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> <8D89F96B7AB1B84F9E049CC7BB91BF5C027FD5D172@RTC-EXCH01.RESERVE.LDS> Message-ID: <2f0abfb4-4f0c-8609-f8db-19e9a61691d1@satchell.net> On 4/24/19 7:24 AM, Tom Beecher wrote: > This is why, in my opinion, people should avoid modem/router combo units > whenever possible. Any information/configuration entered into such a device > could be accessible to the MSO (intentionally or otherwise) , as is > happening here. I'm sure they would come back and say this is necessary to > provide support for customers who pay them for WiFi service, but it clearly > shows they don't turn off that functionality for customers who don't. > > Treat you cable modems as foreign network elements. Cause that's what they > are. +1. Encountered this with an AT&T install. AT&T provided router/wifi combo. After the installer was done, first thing I did was to turn the combo's wifi off, and hook up the access point the customer has been using for years. Verified that the MAC filtering was still correct during the post-install. Customer is happy. The next step is to build a Protectli firewall to go between the AT&T modem and the access point. Block any chance of AT&T using SNMP to sniff the access point. (Moved the Access Point's IP address for management and gateway, too.) From bjackson at napshome.net Wed Apr 24 01:32:03 2019 From: bjackson at napshome.net (Brandon Jackson) Date: Tue, 23 Apr 2019 21:32:03 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: This has been a thing for quite a while with Comcast. It is also available to a customer service rep. It is retrieved from the Gateway via SNMP if I'm not mistaken. Customer service reps can also reset your wireless password either to a default or a specific one of yours or their choosing if necessary. This is something to remember with cable modems and especially gateways. As long as it is connected to their Network it is practically thiers from a configurations standpoint, they are in complete control of the device and can get any information they need or want from said device. I'm not saying they are doing anything nefarious or packet capping the local network or anything of that nature that is a little on the tin foil hat side for me personally, but you should always consider that any information available to a cable modem Gateway or plain cable modem is available to the ISP. As many have recommended in the past always get a separate router and a plane modem. Brandon Jackson On Tue, Apr 23, 2019, 19:47 Töma Gavrichenkov wrote: > Hi NANOG, > > Here's an issue raised today: > > https://security.stackexchange.com/questions/207895/how-does-comcast-know-my-wifi-password > > Apparently there's a concern with customers that their seemingly > private passphrases, entered in their own boxes, are being shared with > the upstream ISP without an explicit customer consent, and are kept in > the ISP database for an unspecified period of time. Is it there by > design? > > if so, then maybe some tweaks are necessary? > > -- > Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at labrats.us Wed Apr 24 03:22:35 2019 From: sean at labrats.us (Sean Figgins) Date: Tue, 23 Apr 2019 21:22:35 -0600 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <9ea214c4-7553-1e55-7bd1-55e003b043b5@rollernet.us> <71746649-4526-4E0C-B70E-75B4BC84649C@reservetele.com> Message-ID: <5a60f3a2-cd1d-620f-6f26-7db592e44b8a@labrats.us> On 4/23/19 8:35 PM, Peter Beckman wrote: > Get your own router if you're worried about your Wifi Password being > known > by Comcast. Or change to WPA2 Enterprise, but I'm guessing that isn't > supported on the router... Original post seems to be someone that bought a used modem/router combo.  Since the combo is part cable model, and needs to be provisioned by the MSP, it is going to have access to parts of the config, including the wireless password.  It is unknown if the password is stored in plaintext in Comcast's database, and I doubt that someone from Comcast is going to validate that.  It is being displayed to the account owner for their benefit.  I honestly see nothing wrong with this in and of itself. At the same time, I refuse to use one of these combo modem/router/WAP.  I don't want Comcast to steal my Internet for their roaming wireless, and also don't trust their security.  I do all that myself on my own hardware, and prefer to be responsible for my own security.  I suspect most people to be lazy.  -Sean From bsisco at justassociates.com Wed Apr 24 15:13:33 2019 From: bsisco at justassociates.com (Benjamin Sisco) Date: Wed, 24 Apr 2019 15:13:33 +0000 Subject: Comcast storing WiFi passwords in cleartext? Message-ID: I think we all understand the value of using one’s own equipment and keeping the firmware up to date if one is in any way concerned about security. We all should also understand that in a managed environment such as an ISP there should be no reasonable expectation of privacy regarding the configuration of the equipment attached to the ISP's network (rented or customer owned). The bigger concern should be the cleartext portion of the subject. There’s ZERO reason to store or transmit any credentials (login, service, keys, etc.), in any location, in an unencrypted fashion regardless of their perceived value or purpose. Unless you like risk. -- Ben Confidentiality Notice: This e-mail communication and any attachments may contain confidential and privi­leged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communica­tion in error, please notify me immediately by replying to this message and deleting it from your computer. Thank you. From aaron at heyaaron.com Wed Apr 24 16:11:55 2019 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 24 Apr 2019 09:11:55 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: On Wed, Apr 24, 2019 at 9:05 AM Brandon Jackson via NANOG wrote: > I'm not saying they are doing anything nefarious or packet capping the > local network or anything of that nature that is a little on the tin foil > hat side for me personally, but you should always consider that any > information available to a cable modem Gateway or plain cable modem is > available to the ISP. > I'd wager at least 95% of Comcast's users aren't network engineers, security bros, or in some technically competent field. If you were building a system to support hundreds of thousands or millions of users who couldn't distinguish between a DVD drive and a cup holder, how would you make it easy for your front-line support staff to help them use the service they paid for? Want to walk them through factory resetting an old WTR54, hardwire a computer/laptop to it (if they have one), sign in with default creds and then properly configure wireless? I'd rather say "What do you want your wireless network name to be?" "Ok, and what do you want your password to be?" "Done. Try connecting now." In any sort of business environment you should be briding the modem and putting your own firewall in. -A -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Wed Apr 24 16:34:28 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 24 Apr 2019 09:34:28 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> On 4/24/19 8:13 AM, Benjamin Sisco wrote: > The bigger concern should be the cleartext portion of the subject. There’s ZERO reason to store or transmit any credentials (login, service, keys, etc.), in any location, in an unencrypted fashion regardless of their perceived value or purpose. Unless you like risk. That's looking at it from a technical perspective when it isn't a technical problem. People that buy "includes wifi" from their ISP often need extreme amounts of help with it, and thus the wifi credentials are stored and transmitted in plain text for tech support reasons. ~Seth From nfawcett at corp.mtco.com Wed Apr 24 20:36:29 2019 From: nfawcett at corp.mtco.com (Fawcett, Nick) Date: Wed, 24 Apr 2019 20:36:29 +0000 Subject: Brocade GRE Tunnel Message-ID: I have an MLX8e on ver 5.6.0. I am trying to establish a GRE tunnel, but I'm having an issue because the source is not in the default VRF. Any Brocade gurus out there? (config-tnif-10)#tunnel source ve 410 Error - Tunnel source interface v410 is not part of default-vrf If I try using the IP I get: (config-tnif-10)#tunnel source 1.2.3.4 Error - Tunnel Source IP 1.2.3.4 is not configured on any interface ~Nick -- Checked by SOPHOS http://www.sophos.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jk at ip-clear.de Wed Apr 24 21:00:29 2019 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Wed, 24 Apr 2019 23:00:29 +0200 Subject: Brocade GRE Tunnel In-Reply-To: References: Message-ID: Hi, you need to upgrade to a more recent version, at least 5.8.00f. (config-tnif-99)#vrf forwarding myself Error - Please configure tunnel source before configuring tunnel vrf But maybe J. On 24 Apr 2019, at 22:36, Fawcett, Nick via NANOG wrote: > I have an MLX8e on ver 5.6.0. I am trying to establish a GRE tunnel, > but I'm having an issue because the source is not in the default VRF. > Any Brocade gurus out there? > > (config-tnif-10)#tunnel source ve 410 > Error - Tunnel source interface v410 is not part of default-vrf > > If I try using the IP I get: > > (config-tnif-10)#tunnel source 1.2.3.4 > Error - Tunnel Source IP 1.2.3.4 is not configured on any interface > > > ~Nick > > -- > Checked by SOPHOS http://www.sophos.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jk at ip-clear.de Wed Apr 24 21:01:34 2019 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Wed, 24 Apr 2019 23:01:34 +0200 Subject: Brocade GRE Tunnel In-Reply-To: References: Message-ID: <8FD0CB80-B11F-48D7-ADCA-6DB828C278E8@ip-clear.de> But maybe 6.2 or 6.3 would be cool, too ;) On 24 Apr 2019, at 23:00, Jörg Kost wrote: > Hi, > > you need to upgrade to a more recent version, at least 5.8.00f. > > (config-tnif-99)#vrf forwarding myself > Error - Please configure tunnel source before configuring tunnel vrf > > But maybe > > J. > > On 24 Apr 2019, at 22:36, Fawcett, Nick via NANOG wrote: > >> I have an MLX8e on ver 5.6.0. I am trying to establish a GRE tunnel, >> but I'm having an issue because the source is not in the default VRF. >> Any Brocade gurus out there? >> >> (config-tnif-10)#tunnel source ve 410 >> Error - Tunnel source interface v410 is not part of default-vrf >> >> If I try using the IP I get: >> >> (config-tnif-10)#tunnel source 1.2.3.4 >> Error - Tunnel Source IP 1.2.3.4 is not configured on any interface >> >> >> ~Nick >> >> -- >> Checked by SOPHOS http://www.sophos.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Wed Apr 24 21:46:39 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 24 Apr 2019 17:46:39 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: <20190424214638.GA3053@gsp.org> On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote: > The bigger concern should be the cleartext portion of the subject. Yes, and the availability of all this to anyone who hacks Comcast customer support. ---rsk From blakjak at blakjak.net Wed Apr 24 22:45:06 2019 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 25 Apr 2019 10:45:06 +1200 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: <294a4b46-4f22-6d3c-6fb0-b32af38daa11@blakjak.net> On 25/04/2019 3:13 AM, Benjamin Sisco wrote: > I think we all understand the value of using one’s own equipment and keeping the firmware up to date if one is in any way concerned about security. We all should also understand that in a managed environment such as an ISP there should be no reasonable expectation of privacy regarding the configuration of the equipment attached to the ISP's network (rented or customer owned). Accepting i'm not a North American... The reasonable expectation of privacy should be that the customer knows precisely what is private, and what is not.  If the ISP makes it very clear that every configuration item on the edge device is known to, or accessible by, the ISP for support purposes, then there's no problem. At which point everyone's "reasonable expectations" are the same, and there's no issue. (Those for whom the support provided by the ISP is key, will enjoy this service. Those who don't, have the option of doing their own thing.  Even better.. provide the user the means to disable the sharing of this information by choice?? Would save buying and running additional hardware for those who don't feel the need to have their creds shared, for example). First thing i've done with all ISP-provided CPE is disable all the remote-login stuff that's enabled by default for tech support purposes. Full knowledge and disclosure is all that's needed! > > The bigger concern should be the cleartext portion of the subject. There’s ZERO reason to store or transmit any credentials (login, service, keys, etc.), in any location, in an unencrypted fashion regardless of their perceived value or purpose. Unless you like risk. As someone else said, the problem is the level of trust you're placing in your ISP and in their own security... a large aggregate of private information is just waiting to be pwned. Mark. From bill at herrin.us Thu Apr 25 00:04:22 2019 From: bill at herrin.us (William Herrin) Date: Wed, 24 Apr 2019 17:04:22 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: On Wed, Apr 24, 2019 at 9:10 AM Benjamin Sisco wrote: > There’s ZERO reason to store or transmit any credentials (login, service, keys, etc.), > in any location, in an unencrypted fashion regardless of their perceived value or > purpose. Unless you like risk. Risk is threat times vulnerability times impact. No impact, no risk. For example, if the credentials for my grocery store loyalty card are compromised, I do not actually care. It has no impact. Hence failing to encrypt the card number as it transits the store network or sits in their database carries no risk. There can be, on the other hand, substantial costs associated with using encryption. Key management infrastructure. Manpower. Business risk: loss of the keys becomes loss of the data. Mistakes yield service outages that impair business operations. Forgot to renew that key? Gotta close the store until the IT guy gets here because the cash registers don't work. These costs tie to the use of encryption regardless of the risk it mitigates. I take no position on what risk the comcast wifi passwords issue carries. I'm posting only to point out that an absolutist model which says, "stuff of type X must always be encrypted," is probably not well tuned to the customer's actual security needs. The generally accepted principle is that if you spend more money mitigating the risk than the attributable cost of the risk then you're doing it wrong. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu Apr 25 04:22:35 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 25 Apr 2019 00:22:35 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: <28895.1556166155@turing-police> On Wed, 24 Apr 2019 17:04:22 -0700, William Herrin said: > I take no position on what risk the comcast wifi passwords issue carries. > I'm posting only to point out that an absolutist model which says, "stuff > of type X must always be encrypted," is probably not well tuned to the > customer's actual security needs. I'm willing to bet that for a significant percentage of people who do at least some of their work at home, but aren't router-savvy, the risks of a borked router preventing them from working from home are a bigger issue than the relatively low risk of a database compromise leading to a miscreant getting hold of their wireless password and using their access point as free wifi. Security decisions that are "obvious" when only security-minded and technically clued people are involved become a lot less obvious when 95% of the people involved are named Joe Q. Sixpack. From mikebolitho at gmail.com Thu Apr 25 04:32:18 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Wed, 24 Apr 2019 21:32:18 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <28895.1556166155@turing-police> References: <28895.1556166155@turing-police> Message-ID: > > "than the relatively low risk of a database compromise leading to a > miscreant getting ahold of their wireless password and using their access > point as free wifi." > And this is the thing, not only does someone have to 'hack' the database, they also need to drive up to your house and sit in your driveway to get free Internet. Of all the things to worry about, this is way down on my list. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From royce at techsolvency.com Thu Apr 25 04:40:40 2019 From: royce at techsolvency.com (Royce Williams) Date: Wed, 24 Apr 2019 20:40:40 -0800 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <28895.1556166155@turing-police> Message-ID: On Wed, Apr 24, 2019 at 8:33 PM Mike Bolitho wrote: > "than the relatively low risk of a database compromise leading to a >> miscreant getting ahold of their wireless password and using their access >> point as free wifi." >> > > And this is the thing, not only does someone have to 'hack' the database, > they also need to drive up to your house and sit in your driveway to get > free Internet. Of all the things to worry about, this is way down on my > list. > They could also remotely compromise *any* device that's currently (or about to be) in range of your access point, as a stepping-stone to gaining access to your network - without having to be physically anywhere near your driveway. Perhaps, for example, to make it look as though what they're doing is coming from your house. Royce -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Apr 25 05:07:51 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Wed, 24 Apr 2019 23:07:51 -0600 Subject: Packetstream - how does this not violate just about every provider's ToS? Message-ID: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Just ran into packetstream.io: "Sell Your Unused Bandwidth Earn passive income while you sleep PacketStream is the first of its kind peer-to-peer proxy network. Packeters are compensated for sharing bandwidth on the PacketStream network and allowing users all over the world have access to content on the internet through our secure network. Customers can purchase bandwidth and browse the web from residential IPs to protect their browsing privacy. The PacketStream network routes customer traffic through PacketStream users allowing for increased privacy and access to geo-restricted content while browsing the web. Packeters on the PacketStream network share their bandwidth with PacketStream customers. The website/service receiving HTTP requests sees requests coming from real residential IPs and allows access to content that would otherwise be blocked if it had been requested from traditional datacenter VPNs or proxy networks." How can this not be a violation of the ToS of just about every major provider? Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From fergdawgster at mykolab.com Thu Apr 25 05:14:57 2019 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 24 Apr 2019 22:14:57 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/24/2019 10:07 PM, Anne P. Mitchell, Esq. wrote: > Just ran into packetstream.io: > > "Sell Your Unused Bandwidth > > Earn passive income while you sleep > What could possibly go wrong? :-) - - ferg - -- Paul Ferguson Principal, Threat Intelligence Gigamon Seattle, WA USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlzBQlEACgkQKJasdVTchbJqVwD/V3h5ZU9IyQEZq5I8aGBCtB+g hp19rjVbr8qtRPxibRoA/jsZYEIKdWNff+O3cVFnLSTNt4YuzLU5tgUPME4t9QiL =B089 -----END PGP SIGNATURE----- From job at instituut.net Thu Apr 25 05:50:03 2019 From: job at instituut.net (Job Snijders) Date: Thu, 25 Apr 2019 05:50:03 +0000 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Message-ID: <20190425055003.GA67694@vurt.meerval.net> Dear Anne, On Wed, Apr 24, 2019 at 11:07:51PM -0600, Anne P. Mitchell, Esq. wrote: > How can this not be a violation of the ToS of just about every major provider? Can you perhaps cite ToS excerpts from one or more major providers to support your assertion? > Anne P. Mitchell, > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop Are you listing all the above because you are presenting a formal position supported by all these organisations about ToS? Can you for instance clarify how signing of as a director for the Denver Internet Exchange shapes the context of your ToS message? Or, perhaps you are listing the above for some kind of self-marketing purposes? If that is the case, please note that it is fairly uncommon to use the NANOG mailing list to distribute resumes. I know numerous websites dedicated to the dissemination of work histories, perhaps you can use those instead of operational mailling list? Regards, Job ps. RFC 3676 section 4.3 From ximaera at gmail.com Thu Apr 25 07:22:46 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 25 Apr 2019 10:22:46 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: On Thu, Apr 25, 2019, 3:06 AM William Herrin wrote: > Risk is threat times vulnerability times impact. No impact, no risk. For > example, if the credentials for my grocery store loyalty card are > compromised, I do not actually care. It has no impact. > A fun fact: my employer has a product which basically does brute force protection for web forms. One of, if not the, biggest customers for that product is a grocery store chain, and exactly with their loyalty card portal. Sometimes, the impact or the absence thereof is a matter of perception. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott.helms at gmail.com Thu Apr 25 12:26:00 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 25 Apr 2019 08:26:00 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <20190424214638.GA3053@gsp.org> References: <20190424214638.GA3053@gsp.org> Message-ID: People are missing the point here. This is _not_ a Comcast "issue" this same data is available to every single cable operator in the US who deploys bundled modem/router/APs that follow the CableLabs standard. They may or may not expose the data to their end customers, but it's stored in their systems and is often available to their support teams. http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt The same thing applies to most FTTH and xDSL deployments. They use TR-069 to collect the data instead of SNMP but the object model is the same. The WiFi MIB above is explicitly built to mimic TR-181 functionality. Scott Helms On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec wrote: > On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote: > > The bigger concern should be the cleartext portion of the subject. > > Yes, and the availability of all this to anyone who hacks Comcast > customer support. > > ---rsk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.cutler at consultant.com Thu Apr 25 12:38:26 2019 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 25 Apr 2019 08:38:26 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <20190424214638.GA3053@gsp.org> Message-ID: <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> > On Apr 25, 2019, at 8:26 AM, K. Scott Helms wrote: > > People are missing the point here. This is _not_ a Comcast "issue" this same data is available to every single cable operator in the US who deploys bundled modem/router/APs that follow the CableLabs standard. They may or may not expose the data to their end customers, but it's stored in their systems and is often available to their support teams. > > http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt > > The same thing applies to most FTTH and xDSL deployments. They use TR-069 to collect the data instead of SNMP but the object model is the same. The WiFi MIB above is explicitly built to mimic TR-181 functionality. > > Scott Helms > > > > On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec > wrote: > On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote: > > The bigger concern should be the cleartext portion of the subject. > > Yes, and the availability of all this to anyone who hacks Comcast > customer support. > > —rsk I have yet to hear any discussion of the business value of access to WiFi network password, especially as compared to billing and identity data. Also, remote management of local networks by definition requires credentials stored off site from the customer. To the typical customer, loss of connectivity is much worse than a small chance of sharing the WiFi. Narrowing the discussion back to Comcast, credentials for “guest” WiFi seem to be more used than purloined SNMP MIB data. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Thu Apr 25 12:55:45 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Thu, 25 Apr 2019 05:55:45 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> References: <20190424214638.GA3053@gsp.org> <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> Message-ID: > > I have yet to hear any discussion of the business value of access to WiFi > network password, especially as compared to billing and identity data. > Grandma Smith calls in because she changed her WPA2 password two years ago. Her grandson just bought her a new iPad and she can't connect. Tier I support says "I have your 'WiFi password' right here. It's hunter22." The call take 45 seconds and you're off to solve the next question. It is all about call center metrics. Is it right? No. But that's the business driver behind it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott.helms at gmail.com Thu Apr 25 13:09:09 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 25 Apr 2019 09:09:09 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> References: <20190424214638.GA3053@gsp.org> <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> Message-ID: James, By the DOCSIS standard and every North American MSO's ToS I've seen (I've worked with or for about 200 different cable operators over the last 20 years) your cable modem is always managed and the cable operator _always_ has access to its configuration and settings via SNMP. The configuration file for a DOCSIS cable modem is nothing more than a list of SNMP OIDs with their values set the way the operator wants them. This has been true since DOCSIS 1.0 (which doesn't make it correct, just common). Now, DOCSIS is primarily deployed with SNMP version 2c though more and more operators, especially the larger ones, are moving or have to SNMPv3. I mention this because every cable modem on a given CMTS that's deployed in SNMPv2c mode will (should for proper functioning) have the same SNMP READ and WRITE strings. SNMPv2c traffic is clear text UDP with no standardized methods of encryption available to the industry. To mitigate this to an extent part of the cable modem's configuration will (best practice anyway) have filtering rules to only accept SNMP traffic from a given IP address or subnet and traffic between the CMTS and the modem should be encrypted via BPI+ for some minimal security. (A minor note, the router interface for a combo unit by CableLabs OSS standards will not respond to SNMP traffic on its public address by default and almost all of the SNMP traffic will be to the modem's RFC1918 address.) What I'm getting at is that the for DOCSIS (and FTTH and most DSL flavors as well) the service provider has and has had access to all the settings for a very long time. What's changed is that customers wanted to WiFi to be provided by the operator and importantly supported by the operator. " I have yet to hear any discussion of the business value of access to WiFi network password, especially as compared to billing and identity data. Also, remote management of local networks by definition requires credentials stored off site from the customer. To the typical customer, loss of connectivity is much worse than a small chance of sharing the WiFi." Let me provide something in this regard. The most common support call category, by a large number, is the WiFi category. In excess of 55% of all support calls (regardless of how the customer describes them) end up being WiFi issues. The most common specific call in that category is some variation of, "I've forgotten my WiFi password and I need to get my new iPad online." As a service provider your choices are to say I can reset your WiFi PSK, which allows the new device to come online but breaks everything else that was connected, or to allow the support rep and/or customer to recover the passphrase. In short, the ability to recover the passphrase is strongly preferred by end users over resetting it and frankly is much less expensive for the operator. I've helped supply this functionality to a large number of operators and in general the implementations _should_ at a minimum be able to capture the agent who recovered the passphrase, the time/date, who the agent was on the phone with, whether the agent correctly verified the identity of the caller, and if the agent followed all other procedures laid by the service provider. Scott Helms On Thu, Apr 25, 2019 at 8:38 AM James R Cutler wrote: > On Apr 25, 2019, at 8:26 AM, K. Scott Helms > wrote: > > People are missing the point here. This is _not_ a Comcast "issue" this > same data is available to every single cable operator in the US who deploys > bundled modem/router/APs that follow the CableLabs standard. They may or > may not expose the data to their end customers, but it's stored in their > systems and is often available to their support teams. > > http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt > > The same thing applies to most FTTH and xDSL deployments. They use TR-069 > to collect the data instead of SNMP but the object model is the same. The > WiFi MIB above is explicitly built to mimic TR-181 functionality. > > Scott Helms > > > > On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec wrote: > >> On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote: >> > The bigger concern should be the cleartext portion of the subject. >> >> Yes, and the availability of all this to anyone who hacks Comcast >> customer support. >> >> —rsk > > > I have yet to hear any discussion of the business value of access to WiFi > network password, especially as compared to billing and identity data. > Also, remote management of local networks by definition requires > credentials stored off site from the customer. To the typical customer, > loss of connectivity is much worse than a small chance of sharing the WiFi. > > Narrowing the discussion back to Comcast, credentials for “guest” WiFi > seem to be more used than purloined SNMP MIB data. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Thu Apr 25 13:51:51 2019 From: list at satchell.net (Stephen Satchell) Date: Thu, 25 Apr 2019 06:51:51 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <28895.1556166155@turing-police> Message-ID: <7211acdb-cacd-aeac-f886-d46689831c0c@satchell.net> On 4/24/19 9:32 PM, Mike Bolitho wrote: >> >> "than the relatively low risk of a database compromise leading to a >> miscreant getting ahold of their wireless password and using their access >> point as free wifi." >> > > And this is the thing, not only does someone have to 'hack' the database, > they also need to drive up to your house and sit in your driveway to get > free Internet. Of all the things to worry about, this is way down on my > list. Sounds like you live in a single-family home, in a low-density neighborhood. I live in an apartment complex, and WiFi Analyzer shows more than 20 beacons visible from my kitchen. Before I implemented MAC filtering, my DHCP server logs showed connections by rogue equipment. (And before you ask, my password is not a simple one.) When I leave town for an extended period, I pull the plug on the wireless. In an industrial park, I see the same dense tangle of beacons. Let alone those wireless systems that have disabled beacons. If that database of wireless passwords also has the physical location of the device, then the risks go up. So the simple solution is to use your own AP, block SNMP access from the worlds at your edge router, and the risk falls to zero. From beecher at beecher.cc Thu Apr 25 14:15:42 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 25 Apr 2019 10:15:42 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Message-ID: Obviously violates every standard “don’t resell the service” clause. ( But these are also the same TOSes that tell me I can’t VPN into the office , so they can pound sand. :p ) Doing this makes about as much sense as running a TOR exit node to me. Too much exposure to someone doing something dumb through you that you’d be left holding the bag for. On Thu, Apr 25, 2019 at 01:10 Anne P. Mitchell, Esq. wrote: > Just ran into packetstream.io: > > "Sell Your Unused Bandwidth > > Earn passive income while you sleep > > PacketStream is the first of its kind peer-to-peer proxy network. > Packeters are compensated for sharing bandwidth on the PacketStream network > and allowing users all over the world have access to content on the > internet through our secure network. Customers can purchase bandwidth and > browse the web from residential IPs to protect their browsing privacy. > > The PacketStream network routes customer traffic through PacketStream > users allowing for increased privacy and access to geo-restricted content > while browsing the web. Packeters on the PacketStream network share their > bandwidth with PacketStream customers. The website/service receiving HTTP > requests sees requests coming from real residential IPs and allows access > to content that would otherwise be blocked if it had been requested from > traditional datacenter VPNs or proxy networks." > > How can this not be a violation of the ToS of just about every major > provider? > > Anne > > Anne P. Mitchell, > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsisco at justassociates.com Thu Apr 25 14:43:49 2019 From: bsisco at justassociates.com (Benjamin Sisco) Date: Thu, 25 Apr 2019 14:43:49 +0000 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> Message-ID: On 4/24/ 2019 10:34 AM, Seth Mattinen wrote: > That's looking at it from a technical perspective when it isn't a technical problem. People that buy "includes wifi" from their ISP often need extreme amounts of help with it, and thus the wifi credentials are stored and transmitted in plain text for tech support reasons. While I agree that the underlying need is to provide fast and effective customer service - it is ultimately a technical problem. As it's been pointed out in subsequent posts WiFi is the leading cause of customer calls to an ISP offering the service. Security and "ease of use" are often at odds with each other, and implementing the former with the latter is the challenge many of us wake up to each and every day. The information should be encrypted at rest and in transit and could easily be decrypted by the CSP platform for use by customer support staff at the time of need when cusetomers call in - which would address the concern. In my experience, bad practice is easily replicated. What else is transmitted in cleartext? Today it's the WiFi password, tomorrow it's your login, port forwarding, DMZ, and other details that are far more useful to a remote attacker than your WiFi password. -----Original Message----- From: NANOG On Behalf Of Seth Mattinen Sent: Wednesday, April 24, 2019 10:34 AM To: nanog at nanog.org Subject: Re: Comcast storing WiFi passwords in cleartext? Notice: This message originated outside of Just Associates. Verify the source & exercise caution with links and attachments. On 4/24/19 8:13 AM, Benjamin Sisco wrote: > The bigger concern should be the cleartext portion of the subject. There’s ZERO reason to store or transmit any credentials (login, service, keys, etc.), in any location, in an unencrypted fashion regardless of their perceived value or purpose. Unless you like risk. That's looking at it from a technical perspective when it isn't a technical problem. People that buy "includes wifi" from their ISP often need extreme amounts of help with it, and thus the wifi credentials are stored and transmitted in plain text for tech support reasons. ~Seth Confidentiality Notice: This e-mail communication and any attachments may contain confidential and privi­leged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communica­tion in error, please notify me immediately by replying to this message and deleting it from your computer. Thank you. From kscott.helms at gmail.com Thu Apr 25 15:04:15 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 25 Apr 2019 11:04:15 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> Message-ID: Just so you know, if you have an embedded router from a service provider all of that data is _already_ being transmitted and has been for a long long time. If it's being collected via SNMPv2c it is being transmitted in the clear (though hopefully encrypted via BPI+ between the modem and the CMTS). If it's being collected via TR-069 it _may_ (should be) encrypted in transit but in my experience that isn't guaranteed and when its being sent over TLS there's often a self signed cert in the chain. Scott Helms On Thu, Apr 25, 2019 at 10:45 AM Benjamin Sisco wrote: > On 4/24/ 2019 10:34 AM, Seth Mattinen wrote: > > > That's looking at it from a technical perspective when it isn't a > technical problem. People that buy "includes wifi" from their ISP often > need extreme amounts of help with it, and thus the wifi credentials are > stored and transmitted in plain text for tech support reasons. > > While I agree that the underlying need is to provide fast and effective > customer service - it is ultimately a technical problem. As it's been > pointed out in subsequent posts WiFi is the leading cause of customer calls > to an ISP offering the service. Security and "ease of use" are often at > odds with each other, and implementing the former with the latter is the > challenge many of us wake up to each and every day. The information should > be encrypted at rest and in transit and could easily be decrypted by the > CSP platform for use by customer support staff at the time of need when > cusetomers call in - which would address the concern. > > In my experience, bad practice is easily replicated. What else is > transmitted in cleartext? Today it's the WiFi password, tomorrow it's your > login, port forwarding, DMZ, and other details that are far more useful to > a remote attacker than your WiFi password. > > > > > -----Original Message----- > From: NANOG On Behalf Of Seth Mattinen > Sent: Wednesday, April 24, 2019 10:34 AM > To: nanog at nanog.org > Subject: Re: Comcast storing WiFi passwords in cleartext? > > Notice: This message originated outside of Just Associates. Verify the > source & exercise caution with links and attachments. > > On 4/24/19 8:13 AM, Benjamin Sisco wrote: > > The bigger concern should be the cleartext portion of the subject. > There’s ZERO reason to store or transmit any credentials (login, service, > keys, etc.), in any location, in an unencrypted fashion regardless of their > perceived value or purpose. Unless you like risk. > > > That's looking at it from a technical perspective when it isn't a > technical problem. People that buy "includes wifi" from their ISP often > need extreme amounts of help with it, and thus the wifi credentials are > stored and transmitted in plain text for tech support reasons. > > ~Seth > Confidentiality Notice: This e-mail communication and any attachments may > contain confidential and privi­leged information for the use of the > designated recipients named above. If you are not the intended recipient, > you are hereby notified that you have received this communication in error > and that any review, disclosure, dissemination, distribution or copying of > it or its contents is prohibited. If you have received this communica­tion > in error, please notify me immediately by replying to this message and > deleting it from your computer. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mis at seiden.com Thu Apr 25 16:10:34 2019 From: mis at seiden.com (Mark Seiden) Date: Thu, 25 Apr 2019 09:10:34 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <20190425055003.GA67694@vurt.meerval.net> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> <20190425055003.GA67694@vurt.meerval.net> Message-ID: feeling cranky, are we, job?   (accusing an antispam expert of spamming on a mailing list by having too long a .sig?) but it’s true!  anne runs the internet, and the rest of us (except for ICANN GAC representatives) all accept that. to actually try to make a more substantial point, i am quite curious how the AUPs of carriers try to disallow bandwidth resale while permitting • cybercafe operations and other “free wifi" (where internet service might be provided for patrons in a hotel or cafe) • wireless access point schemes where you make money or get credit for allowing use of your bandwidth (e.g. Fon) • other proxy services that use bandwidth such as tor exit nodes and openvpn gateways i suppose they could just try to disallow resale or allow on-premises use even if revenue is received.  the Fon business model seems pretty comparable to me. On Apr 24, 2019, 10:51 PM -0700, Job Snijders , wrote: > Dear Anne, > > On Wed, Apr 24, 2019 at 11:07:51PM -0600, Anne P. Mitchell, Esq. wrote: > > How can this not be a violation of the ToS of just about every major provider? > > Can you perhaps cite ToS excerpts from one or more major providers to > support your assertion? > > > Anne P. Mitchell, > > Attorney at Law > > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > > Legislative Consultant > > CEO/President, Institute for Social Internet Public Policy > > Board of Directors, Denver Internet Exchange > > Board of Directors, Asilomar Microcomputer Workshop > > Legal Counsel: The CyberGreen Institute > > Legal Counsel: The Earth Law Center > > California Bar Association > > Cal. Bar Cyberspace Law Committee > > Colorado Cyber Committee > > Ret. Professor of Law, Lincoln Law School of San Jose > > Ret. Chair, Asilomar Microcomputer Workshop > > Are you listing all the above because you are presenting a formal > position supported by all these organisations about ToS? Can you for > instance clarify how signing of as a director for the Denver Internet > Exchange shapes the context of your ToS message? > > Or, perhaps you are listing the above for some kind of self-marketing > purposes? If that is the case, please note that it is fairly uncommon to > use the NANOG mailing list to distribute resumes. I know numerous > websites dedicated to the dissemination of work histories, perhaps you > can use those instead of operational mailling list? > > Regards, > > Job > > ps. RFC 3676 section 4.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Thu Apr 25 17:14:47 2019 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 25 Apr 2019 10:14:47 -0700 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> Message-ID: <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> On 4/25/19 8:04 AM, K. Scott Helms wrote: > Just so you know, if you have an embedded router from a service provider > all of that data is _already_ being transmitted and has been for a long > long time. Responding to a pseudo-random message ... If you are an average consumer and purchase a managed solution (in this case a WAP that comes as part of your package) I think it's perfectly reasonable for the vendor to manage it accordingly, even if said consumer doesn't fully understand the implications of that decision. In my mind, the problem here is not that the vendor has access to this data, it's that they are STORING it in the first place, and storing it in the clear to boot. In the hypothetical service call that we've speculated is the driver for this, the extra 15 or 20 seconds that it would take to pull the data via SNMP is in the noise. There are two mindsets that desperately need changing in the tech world: 1. Do not store data that you don't have a legitimate requirement to store 2. Do not store anything even remotely sensitive in the clear We live in a world of all breaches, all of the time. So we need to start thinking not in terms of just protecting said data from the outside, but rather in terms of limiting the attack surface to start with, and protecting the data at rest. So that WHEN there is a breach, whether from within or without, the damage will be minimal. As many have pointed out, this information is freely available via SNMP, so it's a classic example of something that didn't need to be stored in the first place. Doug From kscott.helms at gmail.com Thu Apr 25 17:53:05 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 25 Apr 2019 13:53:05 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> Message-ID: Doug, I don't disagree, but things are pretty complicated, much more so than they might seem from the outside. First, if the configuration isn't stored there's literally no way to have a backup for most of the CPE vendors so there's definitely reason to have it duplicated in the service providers' systems. Very few allow for end users to download their router configuration via the admin page and I know of none that encrypt that configuration before it is delivered to the end user's computer. (It's also relevant that the usage for those vendors that do allow end users to backup the config is vanishingly low.) If we're looking at a TR-069 based system for managing the WiFi and router components it's not really feasible to do a real time grab of that data since that process can take up to ~5 minutes depending on your periodic inform settings in your ACS. That's because TR-069 is inherently a push technology (from the CPE to the ACS) rather than a pull like SNMP. The next piece is that a DOCSIS configuration file itself, which in some cases contains these parameters, is by the standard required to be delivered via insecure protocols, namely TFTP. Newer devices have options to allow for TLS secured HTTP, but that's very rare today in production provisioning systems, and in case the secured protocols are all still optional in the spec. In general the config file itself is stored in it's text format on the provisioning systems or if the file is dynamically generated the user specific parameters are held in a database with the general ones coming from a template for that class of service. Again, I'm not disagreeing with your premise but the service providers directly control a small piece of the overall process and we're still working with standards from earlier times. Most cable operators have gotten rid of their DOCSIS 2.0 (1.0 and 1.1 as well) but it's not uncommon to find a handful of users with (mostly customer owned) D2 devices that the provisioning and OSS systems still have to deal with. DOCSIS 3.0 devices are the majority and 3.1 devices are just now being rolled out in large numbers. In short, not everything is quickly retrievable, much of the configuration is in fact generated by the service provider and must be maintained because the modem needs to download its configuration every time it reboots, and the vendors and associations in the provisioning and OSS space have more input than the operators themselves. Scott Helms On Thu, Apr 25, 2019 at 1:16 PM Doug Barton wrote: > On 4/25/19 8:04 AM, K. Scott Helms wrote: > > Just so you know, if you have an embedded router from a service provider > > all of that data is _already_ being transmitted and has been for a long > > long time. > > Responding to a pseudo-random message ... > > If you are an average consumer and purchase a managed solution (in this > case a WAP that comes as part of your package) I think it's perfectly > reasonable for the vendor to manage it accordingly, even if said > consumer doesn't fully understand the implications of that decision. > > In my mind, the problem here is not that the vendor has access to this > data, it's that they are STORING it in the first place, and storing it > in the clear to boot. In the hypothetical service call that we've > speculated is the driver for this, the extra 15 or 20 seconds that it > would take to pull the data via SNMP is in the noise. > > There are two mindsets that desperately need changing in the tech world: > > 1. Do not store data that you don't have a legitimate requirement to store > 2. Do not store anything even remotely sensitive in the clear > > We live in a world of all breaches, all of the time. So we need to start > thinking not in terms of just protecting said data from the outside, but > rather in terms of limiting the attack surface to start with, and > protecting the data at rest. So that WHEN there is a breach, whether > from within or without, the damage will be minimal. > > As many have pointed out, this information is freely available via SNMP, > so it's a classic example of something that didn't need to be stored in > the first place. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Apr 25 17:53:27 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 25 Apr 2019 13:53:27 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> Message-ID: As much as it pains me to Devil's Advocate for Comcast... Has anyone proven that they are storing this PSK in cleartext? From the original StackExchange post : " When I went to the account web page, it showed me my password. I changed the password and it instantly showed the new password on the account web page (after refresh). " The SNMP response is essentially cleartext , sure. But perhaps they are performing the query from a modem management network only accessible from the RF side, the transmission back to the CS backend is encrypted in flight, and the data is also encrypted at rest until retrieved and decrypted by a agent or the end user via the web portal. Nothing has been shown that I can recall reading that proves or disproves any of that. On Thu, Apr 25, 2019 at 1:17 PM Doug Barton wrote: > On 4/25/19 8:04 AM, K. Scott Helms wrote: > > Just so you know, if you have an embedded router from a service provider > > all of that data is _already_ being transmitted and has been for a long > > long time. > > Responding to a pseudo-random message ... > > If you are an average consumer and purchase a managed solution (in this > case a WAP that comes as part of your package) I think it's perfectly > reasonable for the vendor to manage it accordingly, even if said > consumer doesn't fully understand the implications of that decision. > > In my mind, the problem here is not that the vendor has access to this > data, it's that they are STORING it in the first place, and storing it > in the clear to boot. In the hypothetical service call that we've > speculated is the driver for this, the extra 15 or 20 seconds that it > would take to pull the data via SNMP is in the noise. > > There are two mindsets that desperately need changing in the tech world: > > 1. Do not store data that you don't have a legitimate requirement to store > 2. Do not store anything even remotely sensitive in the clear > > We live in a world of all breaches, all of the time. So we need to start > thinking not in terms of just protecting said data from the outside, but > rather in terms of limiting the attack surface to start with, and > protecting the data at rest. So that WHEN there is a breach, whether > from within or without, the damage will be minimal. > > As many have pointed out, this information is freely available via SNMP, > so it's a classic example of something that didn't need to be stored in > the first place. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott.helms at gmail.com Thu Apr 25 18:09:08 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 25 Apr 2019 14:09:08 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> Message-ID: Tom, No, and I would hope that they were storing it in an encrypted format and then decrypting it on the fly for display in the customer portal. Scott Helms On Thu, Apr 25, 2019 at 1:55 PM Tom Beecher wrote: > As much as it pains me to Devil's Advocate for Comcast... Has anyone > proven that they are storing this PSK in cleartext? From the original > StackExchange post : > > " When I went to the account web page, it showed me my password. I > changed the password and it instantly showed the new password on the > account web page (after refresh). " > > The SNMP response is essentially cleartext , sure. But perhaps they are > performing the query from a modem management network only accessible from > the RF side, the transmission back to the CS backend is encrypted in > flight, and the data is also encrypted at rest until retrieved and > decrypted by a agent or the end user via the web portal. Nothing has been > shown that I can recall reading that proves or disproves any of that. > > > > On Thu, Apr 25, 2019 at 1:17 PM Doug Barton wrote: > >> On 4/25/19 8:04 AM, K. Scott Helms wrote: >> > Just so you know, if you have an embedded router from a service >> provider >> > all of that data is _already_ being transmitted and has been for a long >> > long time. >> >> Responding to a pseudo-random message ... >> >> If you are an average consumer and purchase a managed solution (in this >> case a WAP that comes as part of your package) I think it's perfectly >> reasonable for the vendor to manage it accordingly, even if said >> consumer doesn't fully understand the implications of that decision. >> >> In my mind, the problem here is not that the vendor has access to this >> data, it's that they are STORING it in the first place, and storing it >> in the clear to boot. In the hypothetical service call that we've >> speculated is the driver for this, the extra 15 or 20 seconds that it >> would take to pull the data via SNMP is in the noise. >> >> There are two mindsets that desperately need changing in the tech world: >> >> 1. Do not store data that you don't have a legitimate requirement to store >> 2. Do not store anything even remotely sensitive in the clear >> >> We live in a world of all breaches, all of the time. So we need to start >> thinking not in terms of just protecting said data from the outside, but >> rather in terms of limiting the attack surface to start with, and >> protecting the data at rest. So that WHEN there is a breach, whether >> from within or without, the damage will be minimal. >> >> As many have pointed out, this information is freely available via SNMP, >> so it's a classic example of something that didn't need to be stored in >> the first place. >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Thu Apr 25 18:42:25 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 25 Apr 2019 21:42:25 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <20190424214638.GA3053@gsp.org> <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> Message-ID: On Thu, Apr 25, 2019, 3:57 PM Mike Bolitho wrote: > Grandma Smith calls in because she changed her WPA2 password two years > ago. Her grandson just bought her a new iPad and she can't connect. Tier I > support says "I have your 'WiFi password' right here. It's hunter22." The > call take 45 seconds and you're off to solve the next question. > Isn't it just better to have it always displayed, in a 40pt sized font, on some LAN-accessible Web page, reachable without authentication by default, so that the call center folk won't have to spend 2 more minutes telling Mrs. Smith that "yes, two is a number and hunter is in lowercase" but would rather simply point her to an URL? -- Töma. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Thu Apr 25 18:51:40 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 25 Apr 2019 14:51:40 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <20190424214638.GA3053@gsp.org> <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> Message-ID: <11358.1556218300@turing-police> On Thu, 25 Apr 2019 21:42:25 +0300, T�ma Gavrichenkov said: > Isn't it just better to have it always displayed, in a 40pt sized font, on > some LAN-accessible Web page, reachable without authentication by default, This assumes that the customer has a spare CAT-5 cable and knows how to use it. And somebody will manage to not understand that an RJ45 and an RJ11 are different, causing all sorts of hilarity. From mlm at pixelgate.net Thu Apr 25 18:55:43 2019 From: mlm at pixelgate.net (Mark Milhollan) Date: Thu, 25 Apr 2019 11:55:43 -0700 (PDT) Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Message-ID: On Wed, 24 Apr 2019, Anne P. Mitchell, Esq. wrote: > Just ran into packetstream.io: > How can this not be a violation of the ToS of just about every major provider? Sounds like a "paid" TOR. Is TOR a ToS violation too -- the EFF would probably like to hear of it if so. Or just the aspect of reselling one's service? /mark From johnl at iecc.com Thu Apr 25 19:21:27 2019 From: johnl at iecc.com (John Levine) Date: 25 Apr 2019 15:21:27 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: Message-ID: <20190425192128.13E602012EF7BF@ary.qy> In article you write: >-=-=-=-=-=- > >feeling cranky, are we, job?   (accusing an antispam expert of spamming on a mailing list by having too long a .sig?) >but it’s true!  anne runs the internet, and the rest of us (except for ICANN GAC representatives) all accept that. > >to actually try to make a more substantial point, i am quite curious how the AUPs of carriers try to disallow >bandwidth resale while permitting > >• cybercafe operations and other “free wifi" (where internet service might be provided for patrons in a >hotel or cafe) >• wireless access point schemes where you make money or get credit for allowing use of your bandwidth (e.g. Fon) >• other proxy services that use bandwidth such as tor exit nodes and openvpn gateways To belabor the fairly obvious, residential and business service are different even if the technology is the same. For example, Comcast's residential TOS says: You agree that the Service(s) and the Xfinity Equipment will be used only for personal, residential, non-commercial purposes, unless otherwise specifically authorized by us in writing. You are prohibited from reselling or permitting another to resell the Service(s) in whole or in part, ... [ long list of other forbidden things ] Their business TOS is different. It says no third party use unless your agreement permits it, so I presume they have a coffee shop plan. (The agreements don't seem to be on their web site.) I'd also observe that coffee shop wifi isn't "resale" since it's free, it's an amenity. As to how do these guys think they'll get away with it, my guess is that they heard that "disruption" means ignoring laws and contracts and someone told them that is a good thing. R's, John From kscott.helms at gmail.com Thu Apr 25 19:30:05 2019 From: kscott.helms at gmail.com (K. Scott Helms) Date: Thu, 25 Apr 2019 15:30:05 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <20190425192128.13E602012EF7BF@ary.qy> References: <20190425192128.13E602012EF7BF@ary.qy> Message-ID: After all, it worked for Napster.... Scott Helms On Thu, Apr 25, 2019 at 3:23 PM John Levine wrote: > In article you write: > >-=-=-=-=-=- > > > >feeling cranky, are we, job? (accusing an antispam expert of spamming > on a mailing list by having too long a .sig?) > >but it’s true! anne runs the internet, and the rest of us (except for > ICANN GAC representatives) all accept that. > > > >to actually try to make a more substantial point, i am quite curious how > the AUPs of carriers try to disallow > >bandwidth resale while permitting > > > >• cybercafe operations and other “free wifi" (where internet service > might be provided for patrons in a > >hotel or cafe) > >• wireless access point schemes where you make money or get credit for > allowing use of your bandwidth (e.g. Fon) > >• other proxy services that use bandwidth such as tor exit nodes and > openvpn gateways > > To belabor the fairly obvious, residential and business service are > different even if the technology is the same. For example, Comcast's > residential TOS says: > > You agree that the Service(s) and the Xfinity Equipment will be used > only for personal, residential, non-commercial purposes, unless > otherwise specifically authorized by us in writing. You are prohibited > from reselling or permitting another to resell the Service(s) in whole > or in part, ... [ long list of other forbidden things ] > > Their business TOS is different. It says no third party use unless > your agreement permits it, so I presume they have a coffee shop plan. > (The agreements don't seem to be on their web site.) I'd also observe > that coffee shop wifi isn't "resale" since it's free, it's an amenity. > > As to how do these guys think they'll get away with it, my guess is > that they heard that "disruption" means ignoring laws and contracts > and someone told them that is a good thing. > > R's, > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Apr 25 19:41:10 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 25 Apr 2019 15:41:10 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> Message-ID: It seems like just another example of liability shifting/shielding. I'll defer to Actual Lawyers obviously, but the way I see it, Packetstream doesn't have any contractual or business relationship with my ISP. I do. If I sell them my bandwidth, and my ISP decides to take action, they come after me, not Packetstream. I can plead all I want about how I was just running "someone else's software" , but that isn't gonna hold up, since I am responsible for what is running on my home network, knowingly or unknowingly. These guys likely just wrote a custom TOR client and a billing backend, and are banking on the fact that most people running as the exit aren't going to get caught by their provider. Ingenious, although shady. I do like they have the classic pyramid scheme going for "income off referrals", just so make sure you KNOW they're shady if you might have suspected otherwise. :) On Thu, Apr 25, 2019 at 3:28 PM K. Scott Helms wrote: > After all, it worked for Napster.... > > > Scott Helms > > > > On Thu, Apr 25, 2019 at 3:23 PM John Levine wrote: > >> In article you write: >> >-=-=-=-=-=- >> > >> >feeling cranky, are we, job? (accusing an antispam expert of spamming >> on a mailing list by having too long a .sig?) >> >but it’s true! anne runs the internet, and the rest of us (except for >> ICANN GAC representatives) all accept that. >> > >> >to actually try to make a more substantial point, i am quite curious how >> the AUPs of carriers try to disallow >> >bandwidth resale while permitting >> > >> >• cybercafe operations and other “free wifi" (where internet service >> might be provided for patrons in a >> >hotel or cafe) >> >• wireless access point schemes where you make money or get credit for >> allowing use of your bandwidth (e.g. Fon) >> >• other proxy services that use bandwidth such as tor exit nodes and >> openvpn gateways >> >> To belabor the fairly obvious, residential and business service are >> different even if the technology is the same. For example, Comcast's >> residential TOS says: >> >> You agree that the Service(s) and the Xfinity Equipment will be used >> only for personal, residential, non-commercial purposes, unless >> otherwise specifically authorized by us in writing. You are prohibited >> from reselling or permitting another to resell the Service(s) in whole >> or in part, ... [ long list of other forbidden things ] >> >> Their business TOS is different. It says no third party use unless >> your agreement permits it, so I presume they have a coffee shop plan. >> (The agreements don't seem to be on their web site.) I'd also observe >> that coffee shop wifi isn't "resale" since it's free, it's an amenity. >> >> As to how do these guys think they'll get away with it, my guess is >> that they heard that "disruption" means ignoring laws and contracts >> and someone told them that is a good thing. >> >> R's, >> John >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Thu Apr 25 20:06:14 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 25 Apr 2019 14:06:14 -0600 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> Message-ID: <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> > On Apr 25, 2019, at 1:41 PM, Tom Beecher wrote: > > It seems like just another example of liability shifting/shielding. I'll defer to Actual Lawyers obviously, but the way I see it, Packetstream doesn't have any contractual or business relationship with my ISP. I do. If I sell them my bandwidth, and my ISP decides to take action, they come after me, not Packetstream. I can plead all I want about how I was just running "someone else's software" , but that isn't gonna hold up, since I am responsible for what is running on my home network, knowingly or unknowingly. And *that* is *exactly* my concern. Because those users...('you' in this example)...they have *no idea* it is causing them to violate their ToS/AUP with their provider. And this in part, is my reason for bringing it up here in NANOG - because (at least some of) those big providers are here. And those big providers are in the best position to stamp this out (if they think that it needs stamping out). And: > On Apr 25, 2019, at 1:21 PM, John Levine wrote: > > As to how do these guys think they'll get away with it, my guess is > that they heard that "disruption" means ignoring laws and contracts > and someone told them that is a good thing. I would have appreciated a C&C warning on that. :-) Anne Anne P. Mitchell, Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From bjackson at napshome.net Thu Apr 25 20:10:23 2019 From: bjackson at napshome.net (Brandon Jackson) Date: Thu, 25 Apr 2019 16:10:23 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: Message-ID: That is not related to the Gateway at all, nor done on the local network are missing with the local network as I was describing. That is further Upstream. Brandon Jackson On Thu, Apr 25, 2019, 14:50 Mel Pilgrim wrote: > On 2019-04-23 18:32, Brandon Jackson via NANOG wrote: > > I'm not saying they are doing anything nefarious or packet capping the > > local network or anything of that nature that is a little on the tin > > foil hat side for me personally, > Except they (Comcast) are doing literally that. When you get close to > your data cap for the month, they inject a warning popup into > unencrypted webpages. They also modify DNS replies in flight even when > you don't use their resolvers. > > Source: direct observation > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mis at seiden.com Thu Apr 25 20:54:44 2019 From: mis at seiden.com (Mark Seiden) Date: Thu, 25 Apr 2019 13:54:44 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> Message-ID: <44a32613-a255-44eb-a094-cee68b6d088a@Spark> particularly "interesting" when someone downloads CP (or, as it now seems to be called, CSAM) using their ipaddr and causes them to become a Person of Interest. On Apr 25, 2019, 12:43 PM -0700, Tom Beecher , wrote: > It seems like just another example of liability shifting/shielding. I'll defer to Actual Lawyers obviously, but the way I see it, Packetstream doesn't have any contractual or business relationship with my ISP.  I do. If I sell them my bandwidth, and my ISP decides to take action, they come after me, not Packetstream. I can plead all I want about how I was just running "someone else's software" , but that isn't gonna hold up, since I am responsible for what is running on my home network, knowingly or unknowingly. > > These guys likely just wrote a custom TOR client and a billing backend, and are banking on the fact that most people running as the exit aren't going to get caught by their provider. Ingenious, although shady.  I do like they have the classic pyramid scheme going for "income off referrals", just so make sure you KNOW they're shady if you might have suspected otherwise. :) > > > On Thu, Apr 25, 2019 at 3:28 PM K. Scott Helms wrote: > > > After all, it worked for Napster.... > > > > > > > > > Scott Helms > > > > > > > > > > > > > On Thu, Apr 25, 2019 at 3:23 PM John Levine wrote: > > > > > In article you write: > > > > > >-=-=-=-=-=- > > > > > > > > > > > >feeling cranky, are we, job?   (accusing an antispam expert of spamming on a mailing list by having too long a .sig?) > > > > > >but it’s true!  anne runs the internet, and the rest of us (except for ICANN GAC representatives) all accept that. > > > > > > > > > > > >to actually try to make a more substantial point, i am quite curious how the AUPs of carriers try to disallow > > > > > >bandwidth resale while permitting > > > > > > > > > > > >• cybercafe operations and other “free wifi" (where internet service might be provided for patrons in a > > > > > >hotel or cafe) > > > > > >• wireless access point schemes where you make money or get credit for allowing use of your bandwidth (e.g. Fon) > > > > > >• other proxy services that use bandwidth such as tor exit nodes and openvpn gateways > > > > > > > > > > To belabor the fairly obvious, residential and business service are > > > > > different even if the technology is the same.  For example, Comcast's > > > > > residential TOS says: > > > > > > > > > >   You agree that the Service(s) and the Xfinity Equipment will be used > > > > >   only for personal, residential, non-commercial purposes, unless > > > > >   otherwise specifically authorized by us in writing. You are prohibited > > > > >   from reselling or permitting another to resell the Service(s) in whole > > > > >   or in part, ... [ long list of other forbidden things ] > > > > > > > > > > Their business TOS is different.  It says no third party use unless > > > > > your agreement permits it, so I presume they have a coffee shop plan. > > > > > (The agreements don't seem to be on their web site.)  I'd also observe > > > > > that coffee shop wifi isn't "resale" since it's free, it's an amenity. > > > > > > > > > > As to how do these guys think they'll get away with it, my guess is > > > > > that they heard that "disruption" means ignoring laws and contracts > > > > > and someone told them that is a good thing. > > > > > > > > > > R's, > > > > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Fri Apr 26 12:01:05 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Fri, 26 Apr 2019 13:01:05 +0100 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: <003d01d4fc27$ba0bb300$2e231900$@netconsultings.com> > Anne P. Mitchell, Esq. > Sent: Thursday, April 25, 2019 9:06 PM > > > > On Apr 25, 2019, at 1:41 PM, Tom Beecher wrote: > > > > It seems like just another example of liability shifting/shielding. I'll defer to > Actual Lawyers obviously, but the way I see it, Packetstream doesn't have > any contractual or business relationship with my ISP. I do. If I sell them my > bandwidth, and my ISP decides to take action, they come after me, not > Packetstream. I can plead all I want about how I was just running "someone > else's software" , but that isn't gonna hold up, since I am responsible for > what is running on my home network, knowingly or unknowingly. > > And *that* is *exactly* my concern. Because those users...('you' in this > example)...they have *no idea* it is causing them to violate their ToS/AUP > with their provider. > But isn't there a law in US that protects oblivious or outright simple-mined population from falling for these type of "easy money" schemes by prohibiting these types of business? I believe there's something like that in EU (rendering pyramid schemes or lending money with extreme interests illegal for example). Although I appreciate that in this particular case the exact formulation would be rather cumbersome to define. adam From matthew at matthew.at Fri Apr 26 12:10:36 2019 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 26 Apr 2019 05:10:36 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: On Thu, Apr 25, 2019 at 1:09 PM Anne P. Mitchell, Esq. wrote: > > > > On Apr 25, 2019, at 1:41 PM, Tom Beecher wrote: > > > > It seems like just another example of liability shifting/shielding. I'll > defer to Actual Lawyers obviously, but the way I see it, Packetstream > doesn't have any contractual or business relationship with my ISP. I do. > If I sell them my bandwidth, and my ISP decides to take action, they come > after me, not Packetstream. I can plead all I want about how I was just > running "someone else's software" , but that isn't gonna hold up, since I > am responsible for what is running on my home network, knowingly or > unknowingly. > > And *that* is *exactly* my concern. Because those users...('you' in this > example)...they have *no idea* it is causing them to violate their ToS/AUP > with their provider. > > And this in part, is my reason for bringing it up here in NANOG - because > (at least some of) those big providers are here. And those big providers > are in the best position to stamp this out (if they think that it needs > stamping out). So providers should stamp this out (because it is “bad”) and support customers who are running TOR nodes (because those are “good”). Did I get that right? Matthew Kaufman > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t0pe5p0h at meo.ws Fri Apr 26 11:25:27 2019 From: t0pe5p0h at meo.ws (Katie Holly) Date: Fri, 26 Apr 2019 13:25:27 +0200 Subject: SoftLayer NOC contact to get two IP prefixes de-announced Message-ID: <2219d3b2-f10e-7150-3ac1-bf82ce36cf6b@meo.ws> Hi, anyone from SoftLayer (AS36351) around or someone with a contact to their NOC? They have been announcing two /24's from us without permission and we'd like them to remove the announcement immediately. Emails were sent to ipadmin at softlayer.com, abuse at ibm.com and ipreg at us.ibm.com without success hence I'm reaching out to this list as a last resort. Thanks -- Best regards Katie Holly From beecher at beecher.cc Fri Apr 26 13:44:29 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 26 Apr 2019 09:44:29 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: And that is the conundrum here I think. It's very difficult (for me) to reconcile "NET NEUTRALITY!! PROVIDERS SHOULD BE DUMB PIPES!" with "Hey providers, this company is trying to do something sketchy, you should take action to stop it from working." Reselling bandwidth/access to your residential internet connection isn't (to my knowledge) breaking any criminal LAWS. It's only violating the ToS between you and your provider, to which they have a remedy of canceling your account if they decide to. (Maybe there's civil action there? I dunno.) So for anything not violating laws I'm not sure I want ISPs interfering with traffic at all. On the flip side, maybe ISPs can be pragmatic about this, and send warnings to people who may start using this..."service". Give them a heads up that they appear to be doing something that is in violation of the ToS, and if they continue, their account might be canceled. Be a nicer method than just 0 to canceled in one go. On Fri, Apr 26, 2019 at 8:12 AM Matthew Kaufman wrote: > > > On Thu, Apr 25, 2019 at 1:09 PM Anne P. Mitchell, Esq. < > amitchell at isipp.com> wrote: > >> >> >> > On Apr 25, 2019, at 1:41 PM, Tom Beecher wrote: >> > >> > It seems like just another example of liability shifting/shielding. >> I'll defer to Actual Lawyers obviously, but the way I see it, Packetstream >> doesn't have any contractual or business relationship with my ISP. I do. >> If I sell them my bandwidth, and my ISP decides to take action, they come >> after me, not Packetstream. I can plead all I want about how I was just >> running "someone else's software" , but that isn't gonna hold up, since I >> am responsible for what is running on my home network, knowingly or >> unknowingly. >> >> And *that* is *exactly* my concern. Because those users...('you' in this >> example)...they have *no idea* it is causing them to violate their ToS/AUP >> with their provider. >> >> And this in part, is my reason for bringing it up here in NANOG - because >> (at least some of) those big providers are here. And those big providers >> are in the best position to stamp this out (if they think that it needs >> stamping out). > > > So providers should stamp this out (because it is “bad”) and support > customers who are running TOR nodes (because those are “good”). Did I get > that right? > > Matthew Kaufman > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Apr 26 13:48:15 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Apr 2019 08:48:15 -0500 (CDT) Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: <570478722.2367.1556286492788.JavaMail.mhammett@ThunderFuck> Great... someone brought up Net Neutrality. I guess it's time to unsubscribe from the list for a few days until the shit show disappears. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher" To: "Matthew Kaufman" Cc: "J. Hellenthal via NANOG" Sent: Friday, April 26, 2019 8:44:29 AM Subject: Re: Packetstream - how does this not violate just about every provider's ToS? And that is the conundrum here I think. It's very difficult (for me) to reconcile "NET NEUTRALITY!! PROVIDERS SHOULD BE DUMB PIPES!" with "Hey providers, this company is trying to do something sketchy, you should take action to stop it from working." Reselling bandwidth/access to your residential internet connection isn't (to my knowledge) breaking any criminal LAWS. It's only violating the ToS between you and your provider, to which they have a remedy of canceling your account if they decide to. (Maybe there's civil action there? I dunno.) So for anything not violating laws I'm not sure I want ISPs interfering with traffic at all. On the flip side, maybe ISPs can be pragmatic about this, and send warnings to people who may start using this..."service". Give them a heads up that they appear to be doing something that is in violation of the ToS, and if they continue, their account might be canceled. Be a nicer method than just 0 to canceled in one go. On Fri, Apr 26, 2019 at 8:12 AM Matthew Kaufman < matthew at matthew.at > wrote: On Thu, Apr 25, 2019 at 1:09 PM Anne P. Mitchell, Esq. < amitchell at isipp.com > wrote:
> On Apr 25, 2019, at 1:41 PM, Tom Beecher wrote: > > It seems like just another example of liability shifting/shielding. I'll defer to Actual Lawyers obviously, but the way I see it, Packetstream doesn't have any contractual or business relationship with my ISP. I do. If I sell them my bandwidth, and my ISP decides to take action, they come after me, not Packetstream. I can plead all I want about how I was just running "someone else's software" , but that isn't gonna hold up, since I am responsible for what is running on my home network, knowingly or unknowingly. And *that* is *exactly* my concern. Because those users...('you' in this example)...they have *no idea* it is causing them to violate their ToS/AUP with their provider. And this in part, is my reason for bringing it up here in NANOG - because (at least some of) those big providers are here. And those big providers are in the best position to stamp this out (if they think that it needs stamping out).
So providers should stamp this out (because it is “bad”) and support customers who are running TOR nodes (because those are “good”). Did I get that right? Matthew Kaufman
-------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Fri Apr 26 14:40:46 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 26 Apr 2019 08:40:46 -0600 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: <3AF4E5E4-349A-4B3B-852C-FABE04872096@isipp.com> > On Apr 26, 2019, at 6:10 AM, Matthew Kaufman wrote: > > So providers should stamp this out (because it is “bad”) and support customers who are running TOR nodes (because those are “good”). Did I get that right? If that is how you see it, then it's right for you. At no time did I mention TOR, nor will I get dragged into that discussion. Anne Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose From mel at beckman.org Fri Apr 26 15:24:51 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 26 Apr 2019 15:24:51 +0000 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <3AF4E5E4-349A-4B3B-852C-FABE04872096@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> , <3AF4E5E4-349A-4B3B-852C-FABE04872096@isipp.com> Message-ID: Anne, With all due respect, you haven’t yet cited an example of an ISP TOS at “every provider” that this new company’s product violates. I’m not asking you to critique TORs, I’m asking that you tell us the TOS restriction that you believe is so obvious to everyone? Because it’s not obvious to me, and I own an ISP. -mel via cell > On Apr 26, 2019, at 7:41 AM, Anne P. Mitchell, Esq. wrote: > > > >> On Apr 26, 2019, at 6:10 AM, Matthew Kaufman wrote: >> >> So providers should stamp this out (because it is “bad”) and support customers who are running TOR nodes (because those are “good”). Did I get that right? > > If that is how you see it, then it's right for you. At no time did I mention TOR, nor will I get dragged into that discussion. > > Anne > > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Former Counsel: Mail Abuse Prevention System (MAPS > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > > From amitchell at isipp.com Fri Apr 26 15:47:26 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 26 Apr 2019 09:47:26 -0600 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> <3AF4E5E4-349A-4B3B-852C-FABE04872096@isipp.com> Message-ID: <2FA16F2B-ED51-42FE-9CB7-B7B1743130D0@isipp.com> > On Apr 26, 2019, at 9:24 AM, Mel Beckman wrote: > > With all due respect, you haven’t yet cited an example of an ISP TOS at “every provider” that this new company’s product violates. I’m not asking you to critique TORs, I’m asking that you tell us the TOS restriction that you believe is so obvious to everyone? Because it’s not obvious to me, and I own an ISP. A few examples: Comcast: You are prohibited from reselling or permitting another to resell the Service(s) in whole or in part, or using or permitting another to use the Xfinity Equipment or the Service(s), directly or indirectly, for any unlawful purpose, including, but not limited to, in violation of any policy we post applicable to the Service(s). https://www.xfinity.com/Corporate/Customers/Policies/SubscriberAgreement --- CenturyLink: Also, you agree not to use the Service for high volume or excessive use, in a business or for any commercial purpose if your Service is a residential service, or in a way that impacts CenturyLink network resources or CenturyLink’s ability to provide services. You agree not to: (i) offer public information services (unlimited usage or otherwise), or (ii) permit more than one high-speed Internet log-on session to be active at one time, except if using a roaming account when traveling, in which case 2 sessions may be active. A log-on session represents an active connection to your Internet access provider. The active session may be shared to connect multiple computers/devices within a single home or office location or within a single unit within a multiple dwelling unit (e.g., single apartment or office within an apartment complex) to your modem and/or router to access the Service (including the establishment of a wireless fidelity (“WiFi”) hotspot), but the Service may only be used at the single home or office location or single unit within a multiple dwelling unit for which Service is provisioned by CenturyLink. http://www.centurylink.com/legal/en/highspeedinternetsubscriberagreement_LQ.html --- Google: you agree not to use or allow third parties to use the Services provided to you for any of the following purposes: ... • To make the Services available to anyone outside the property to which the Services are delivered, to resell the Services directly or indirectly, except as explicitly approved by Google Fiber in writing, or to create substitute or related services through the use of or access to the Services (for example, to provide Wi-Fi services to third parties outside of your residence). https://fiber.google.com/legal/accepteduse/residential/ --- Anne Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose From ximaera at gmail.com Fri Apr 26 15:56:04 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 26 Apr 2019 18:56:04 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <11358.1556218300@turing-police> References: <20190424214638.GA3053@gsp.org> <2518C7A9-3436-446D-B76E-1A0C4C9B5AB8@consultant.com> <11358.1556218300@turing-police> Message-ID: On Thu, Apr 25, 2019, 9:51 PM Valdis Klētnieks wrote: > This assumes that the customer has a spare CAT-5 cable and knows how to > use it. > This is assuming that no customer's device has an access to the same network, in which case you just happily reset the password or even the device as a whole, either remotely or by telling the customer to push and hold a button on the device. Though I understand that this could be less convenient in certain scenarios. Most of the time though[citation needed], at least a couple of devices with the wireless network access are there. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Fri Apr 26 16:06:40 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 26 Apr 2019 19:06:40 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <7211acdb-cacd-aeac-f886-d46689831c0c@satchell.net> References: <28895.1556166155@turing-police> <7211acdb-cacd-aeac-f886-d46689831c0c@satchell.net> Message-ID: Peace, On Thu, Apr 25, 2019, 4:53 PM Stephen Satchell wrote: > > not only does someone have to 'hack' the database, > > they also need to drive up to your house and sit in your driveway to get > > free Internet. > > Sounds like you live in a single-family home, in a low-density > neighborhood. I live in an apartment complex, and WiFi Analyzer shows > more than 20 beacons visible from my kitchen. Also, I've seen people who use the same password (sometimes with few easily reversible modifications) for virtually all the purposes, from the WiFi router up to their e-mail and banking accounts. Which is why today, if you store nearly anything close in a sense to a passphrase in your database in cleartext, then you might be at risk just because of that. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Fri Apr 26 16:27:53 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 26 Apr 2019 17:27:53 +0100 (WEST) Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) Message-ID: Hi, Just to let everybody know that a petition was started in order to try to enable a policy discussion about "BGP Hijacking is an ARIN Policy Violation". If you would like to read the proposal, it is available at: https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/ Discussions are already ongoing at RIPE and LACNIC. Best Regards, Carlos (sorry for the duplicates, if you also receive arin-ppml at arin.net) ---------- Forwarded message ---------- Date: Fri, 26 Apr 2019 17:13:12 From: ARIN To: arin-ppml at arin.net Subject: [arin-ppml] Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation A petition has been initiated for the following: ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation This proposal was rejected due to scope at the 10 April meeting of the Advisory Council. Anyone may take part in this petition. Per the Policy Development Process (PDP), a successful petition against a rejected Proposal requires the support of ten individuals from ten organizations. To support this petition, simply send a response to the Public Policy Mailing list stating your support, name, and organization. This petition window will remain open for five days, closing 1 May. If successful, the petition will result in the Board of Trustees considering the Proposal's scope at their next meeting. For more information on the PDP, visit: https://www.arin.net/participate/policy/pdp/ Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From alan.buxey at gmail.com Fri Apr 26 16:34:35 2019 From: alan.buxey at gmail.com (Alan Buxey) Date: Fri, 26 Apr 2019 17:34:35 +0100 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Message-ID: hi, > Just ran into packetstream.io: Had a quick look but doesn't seem to mention Blockchain at all - therefore it can't be that good! ;-) alan From matt at netfire.net Fri Apr 26 16:41:18 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 26 Apr 2019 11:41:18 -0500 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, Apr 26, 2019 at 11:28 AM Carlos Friaças via NANOG wrote: > > Hi, > > Just to let everybody know that a petition was started in order to try > to enable a policy discussion about "BGP Hijacking is an ARIN Policy > Violation". > > If you would like to read the proposal, it is available at: > https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/ > > Discussions are already ongoing at RIPE and LACNIC. > > Best Regards, > Carlos > Hey Carlos, Can you (or someone else on the list, perhaps even someone who was involved in voting this down) provide some more details as to why it was rejected? What were the arguments in favor of rejecting the proposal? This seems like an interesting idea to me, and one that I can't immediately come up with any arguments against from my own perspective. There's probably some room for discussing and tuning specifics, but ultimately the concept seems reasonable to me. What am I missing here? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-post at rsuc.gweep.net Fri Apr 26 16:47:20 2019 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 26 Apr 2019 12:47:20 -0400 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: <20190426164719.GA85521@gweep.net> On Fri, Apr 26, 2019 at 11:41:18AM -0500, Matt Harris wrote: [snip] > Can you (or someone else on the list, perhaps even someone who was involved > in voting this down) provide some more details as to why it was rejected? > What were the arguments in favor of rejecting the proposal? This seems > like an interesting idea to me, and one that I can't immediately come up > with any arguments against from my own perspective. There's probably some > room for discussing and tuning specifics, but ultimately the concept seems > reasonable to me. What am I missing here? Speaking solely for myself, it would be reasonable to start any discussion based upon the on-record rationales for its rejection. As such I would direct interested parties to the Draft Advisory Council Meeting minutes from April 10 https://www.arin.net/about/welcome/ac/meetings/2019_0410/ and most specifically on that page "16. ARIN-Prop-266: BGP Hijacking is an ARIN Policy Violation" Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From cfriacas at fccn.pt Fri Apr 26 16:50:42 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 26 Apr 2019 17:50:42 +0100 (WEST) Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, 26 Apr 2019, Matt Harris wrote: > On Fri, Apr 26, 2019 at 11:28 AM Carlos Friaças via NANOG wrote: > > Hi, > > Just to let everybody know that a petition was started in order to try > to enable a policy discussion about "BGP Hijacking is an ARIN Policy > Violation". > > If you would like to read the proposal, it is available at: > https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/ > > Discussions are already ongoing at RIPE and LACNIC. > > Best Regards, > Carlos > > > Hey Carlos,Can you (or someone else on the list, perhaps even someone who was involved in voting this down) provide some more > details as to why it was rejected?  What were the arguments in favor of rejecting the proposal?  This seems like an interesting > idea to me, and one that I can't immediately come up with any arguments against from my own perspective.  There's probably some > room for discussing and tuning specifics, but ultimately the concept seems reasonable to me.  What am I missing here?   Hi, Sure... https://www.arin.net/about/welcome/ac/meetings/2019_0410 (Meeting of the ARIN Advisory Council - 10 April 2019) You can also find the RIPE and LACNIC URLs here: + https://www.ripe.net/participate/policies/proposals/2019-03 + https://politicas.lacnic.net/politicas/detail/id/LAC-2019-5?language=en Best Regards, Carlos > Thanks, > Matt > > > From bill at herrin.us Fri Apr 26 17:48:52 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Apr 2019 10:48:52 -0700 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, Apr 26, 2019 at 9:41 AM Matt Harris wrote: > Can you (or someone else on the list, perhaps even someone who was > involved in voting this down) provide some more details as to why it was > rejected? > Hi Matt, As I understand it (someone with better knowledge feel free to correct me) the proposal was ruled out of scope for ARIN because ARIN registers numbers, it doesn't decide how they're allowed to be routed. ISPs do that. I personally support the petition. I think the out of scope reasoning is flawed. By enforcing minimum assignment sizes, ARIN has long acted as a gatekeeper to the routing system, controlling who can and can not participate. For better or worse, that puts the proposal in scope. I personally think it's for worse. I oppose the proposal itself. I'd just as soon ARIN not act as a gatekeeper to BGP and certain don't want to see it expand that role. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Fri Apr 26 17:57:04 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 26 Apr 2019 17:57:04 +0000 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <2FA16F2B-ED51-42FE-9CB7-B7B1743130D0@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> <3AF4E5E4-349A-4B3B-852C-FABE04872096@isipp.com> , <2FA16F2B-ED51-42FE-9CB7-B7B1743130D0@isipp.com> Message-ID: <4692714B-A831-41DC-9165-576747D84B5D@beckman.org> Anne, As a lawyer, I’m sure you realize those overly broad policies are unenforceable on their face. Phrases such as “resell...directly or indirectly” could just as easily be interpreted to mean you can’t perform paid consulting work by email over a residential link — something patently ridiculous. Can you cite any case law where these restrictions have been enforced? I believe if a case every cane to court, the defense would have an excellent argument that the plain meaning of these restrictions is to prevent others from buying direct Internet access from another communications channel (e.g., WiFi) from the residence, not passing data through the residence. -mel via cell > On Apr 26, 2019, at 8:48 AM, Anne P. Mitchell, Esq. wrote: > > > >> On Apr 26, 2019, at 9:24 AM, Mel Beckman wrote: >> >> With all due respect, you haven’t yet cited an example of an ISP TOS at “every provider” that this new company’s product violates. I’m not asking you to critique TORs, I’m asking that you tell us the TOS restriction that you believe is so obvious to everyone? Because it’s not obvious to me, and I own an ISP. > > A few examples: > > Comcast: > > You are prohibited from reselling or permitting another to resell the Service(s) in whole or in part, or using or permitting another to use the Xfinity Equipment or the Service(s), directly or indirectly, for any unlawful purpose, including, but not limited to, in violation of any policy we post applicable to the Service(s). > > https://www.xfinity.com/Corporate/Customers/Policies/SubscriberAgreement > > --- > > CenturyLink: > > Also, you agree not to use the Service for high volume or excessive use, in a business or for any commercial purpose if your Service is a residential service, or in a way that impacts CenturyLink network resources or CenturyLink’s ability to provide services. You agree not to: (i) offer public information services (unlimited usage or otherwise), or (ii) permit more than one high-speed Internet log-on session to be active at one time, except if using a roaming account when traveling, in which case 2 sessions may be active. A log-on session represents an active connection to your Internet access provider. The active session may be shared to connect multiple computers/devices within a single home or office location or within a single unit within a multiple dwelling unit (e.g., single apartment or office within an apartment complex) to your modem and/or router to access the Service (including the establishment of a wireless fidelity (“WiFi”) hotspot), but the Service may only be used at the single home or office location or single unit within a multiple dwelling unit for which Service is provisioned by CenturyLink. > > http://www.centurylink.com/legal/en/highspeedinternetsubscriberagreement_LQ.html > > --- > > Google: > > you agree not to use or allow third parties to use the Services provided to you for any of the following purposes: > > ... > > • To make the Services available to anyone outside the property to which the Services are delivered, to resell the Services directly or indirectly, except as explicitly approved by Google Fiber in writing, or to create substitute or related services through the use of or access to the Services (for example, to provide Wi-Fi services to third parties outside of your residence). > > https://fiber.google.com/legal/accepteduse/residential/ > > --- > > Anne > > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Former Counsel: Mail Abuse Prevention System (MAPS > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > > > > From amitchell at isipp.com Fri Apr 26 18:01:48 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 26 Apr 2019 12:01:48 -0600 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <4692714B-A831-41DC-9165-576747D84B5D@beckman.org> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> <3AF4E5E4-349A-4B3B-852C-FABE04872096@isipp.com> <2FA16F2B-ED51-42FE-9CB7-B7B1743130D0@isipp.com> <4692714B-A831-41DC-9165-576747D84B5D@beckman.org> Message-ID: <5A9647EE-B43A-494A-8F22-3DEE500C9D4B@isipp.com> > On Apr 26, 2019, at 11:57 AM, Mel Beckman wrote: > > Anne, > > As a lawyer, I’m sure you realize those overly broad policies are unenforceable on their face. Phrases such as “resell...directly or indirectly” could just as easily be interpreted to mean you can’t perform paid consulting work by email over a residential link — something patently ridiculous. > > Can you cite any case law where these restrictions have been enforced? I believe if a case every cane to court, the defense would have an excellent argument that the plain meaning of these restrictions is to prevent others from buying direct Internet access from another communications channel (e.g., WiFi) from the residence, not passing data through the residence. Mel, we will have to agree to disagree. I know that if I were representing any of these providers, I know what arguments I'd make, and we would almost certainly win. Courts don't look kindly on breach of contract (nor on inducing breach of contract, as Packetstream is), and the ToSs very clearly state you cannot *resell* your residential bandwidth, which is precisely what is going on here (there is no legal theory of which I am aware under which that could be interpreted to mean "can’t perform paid consulting work by email over a residential link", novel though your theory is. Performing paid consulting work is *not* 'reselling bandwidth"). Anne Attorney at Law GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS California Bar Association Cal. Bar Cyberspace Law Committee Colorado Cyber Committee Ret. Professor of Law, Lincoln Law School of San Jose From cscora at apnic.net Fri Apr 26 18:03:20 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Apr 2019 04:03:20 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190426180320.308CEC55B5@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 Apr, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 748157 Prefixes after maximum aggregation (per Origin AS): 287073 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 360249 Total ASes present in the Internet Routing Table: 63999 Prefixes per ASN: 11.69 Origin-only ASes present in the Internet Routing Table: 55033 Origin ASes announcing only one prefix: 23727 Transit ASes present in the Internet Routing Table: 8966 Transit-only ASes present in the Internet Routing Table: 278 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 40 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 24 Number of instances of unregistered ASNs: 27 Number of 32-bit ASNs allocated by the RIRs: 26729 Number of 32-bit ASNs visible in the Routing Table: 21812 Prefixes from 32-bit ASNs in the Routing Table: 95805 Number of bogon 32-bit ASNs visible in the Routing Table: 20 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 236 Number of addresses announced to Internet: 2850096512 Equivalent to 169 /8s, 225 /16s and 5 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.2 Total number of prefixes smaller than registry allocations: 250340 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 201578 Total APNIC prefixes after maximum aggregation: 58375 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 198234 Unique aggregates announced from the APNIC address blocks: 82785 APNIC Region origin ASes present in the Internet Routing Table: 9678 APNIC Prefixes per ASN: 20.48 APNIC Region origin ASes announcing only one prefix: 2708 APNIC Region transit ASes present in the Internet Routing Table: 1440 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4677 Number of APNIC addresses announced to Internet: 773820800 Equivalent to 46 /8s, 31 /16s and 145 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-139577 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 222607 Total ARIN prefixes after maximum aggregation: 104561 ARIN Deaggregation factor: 2.13 Prefixes being announced from the ARIN address blocks: 221648 Unique aggregates announced from the ARIN address blocks: 105453 ARIN Region origin ASes present in the Internet Routing Table: 18445 ARIN Prefixes per ASN: 12.02 ARIN Region origin ASes announcing only one prefix: 6851 ARIN Region transit ASes present in the Internet Routing Table: 1907 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 40 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2678 Number of ARIN addresses announced to Internet: 1078683008 Equivalent to 64 /8s, 75 /16s and 101 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 206049 Total RIPE prefixes after maximum aggregation: 98153 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 202399 Unique aggregates announced from the RIPE address blocks: 120183 RIPE Region origin ASes present in the Internet Routing Table: 25990 RIPE Prefixes per ASN: 7.79 RIPE Region origin ASes announcing only one prefix: 11533 RIPE Region transit ASes present in the Internet Routing Table: 3705 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8042 Number of RIPE addresses announced to Internet: 718891648 Equivalent to 42 /8s, 217 /16s and 106 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 96408 Total LACNIC prefixes after maximum aggregation: 21667 LACNIC Deaggregation factor: 4.45 Prefixes being announced from the LACNIC address blocks: 97780 Unique aggregates announced from the LACNIC address blocks: 42467 LACNIC Region origin ASes present in the Internet Routing Table: 8315 LACNIC Prefixes per ASN: 11.76 LACNIC Region origin ASes announcing only one prefix: 2194 LACNIC Region transit ASes present in the Internet Routing Table: 1537 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5861 Number of LACNIC addresses announced to Internet: 173704448 Equivalent to 10 /8s, 90 /16s and 133 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 21490 Total AfriNIC prefixes after maximum aggregation: 4298 AfriNIC Deaggregation factor: 5.00 Prefixes being announced from the AfriNIC address blocks: 27860 Unique aggregates announced from the AfriNIC address blocks: 9142 AfriNIC Region origin ASes present in the Internet Routing Table: 1277 AfriNIC Prefixes per ASN: 21.82 AfriNIC Region origin ASes announcing only one prefix: 441 AfriNIC Region transit ASes present in the Internet Routing Table: 245 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 554 Number of AfriNIC addresses announced to Internet: 104743936 Equivalent to 6 /8s, 62 /16s and 68 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4733 546 552 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4708 4192 74 ERX-CERNET-BKB China Education and Rese 7552 3134 1307 54 VIETEL-AS-AP Viettel Group, VN 45899 3014 1738 112 VNPT-AS-VN VNPT Corp, VN 9829 2733 1496 551 BSNL-NIB National Internet Backbone, IN 4766 2547 11120 761 KIXS-AS-KR Korea Telecom, KR 9808 2448 8699 27 CMNET-GD Guangdong Mobile Communication 9394 2176 4898 27 CTTNET China TieTong Telecommunications 4755 2147 429 185 TATACOMM-AS TATA Communications formerl 9498 2049 427 171 BBIL-AP BHARTI Airtel Ltd., 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 11492 3645 238 584 CABLEONE - CABLE ONE, INC., US 6327 3615 1325 93 SHAW - Shaw Communications Inc., CA 22773 3399 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2677 5944 1122 AMAZON-02 - Amazon.com, Inc., US 16625 2409 1320 1821 AKAMAI-AS - Akamai Technologies, Inc., 7155 2239 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 30036 2174 356 112 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2148 2751 525 CHARTER-20115 - Charter Communications, 18566 2107 405 108 MEGAPATH5-US - MegaPath Corporation, US 5650 2086 3074 1462 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5432 1629 140 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3233 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2634 525 1908 AKAMAI-ASN1, US 12389 2247 2222 650 ROSTELECOM-AS, RU 34984 2078 343 540 TELLCOM-AS, TR 9121 1669 1692 18 TTNET, TR 13188 1605 100 47 TRIOLAN, UA 9009 1422 148 773 M247, GB 8402 1236 545 15 CORBINA-AS OJSC "Vimpelcom", RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5708 3346 599 Uninet S.A. de C.V., MX 10620 3446 538 377 Telmex Colombia S.A., CO 11830 2708 384 34 Instituto Costarricense de Electricidad 7303 1475 1012 251 Telecom Argentina S.A., AR 28573 1344 2226 202 CLARO S.A., BR 6503 1258 433 53 Axtel, S.A.B. de C.V., MX 6147 1158 377 30 Telefonica del Peru S.A.A., PE 3816 1083 515 141 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 955 144 64 Alestra, S. de R.L. de C.V., MX 13999 952 512 241 Mega Cable, S.A. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1225 393 21 LINKdotNET-AS, EG 37611 896 107 9 Afrihost, ZA 24835 888 648 21 RAYA-AS, EG 36992 852 1531 68 ETISALAT-MISR, EG 36903 827 416 126 MT-MPLS, MA 8452 705 1731 19 TE-AS TE-AS, EG 29571 514 70 12 ORANGE-COTE-IVOIRE, CI 37492 470 470 57 ORANGE-, TN 15706 421 32 6 Sudatel, SD 37342 420 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5708 3346 599 Uninet S.A. de C.V., MX 12479 5432 1629 140 UNI2-AS, ES 7545 4733 546 552 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4708 4192 74 ERX-CERNET-BKB China Education and Rese 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3645 238 584 CABLEONE - CABLE ONE, INC., US 6327 3615 1325 93 SHAW - Shaw Communications Inc., CA 10620 3446 538 377 Telmex Colombia S.A., CO 22773 3399 2976 161 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3233 378 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5432 5292 UNI2-AS, ES 4538 4708 4634 ERX-CERNET-BKB China Education and Research Net 7545 4733 4181 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3615 3522 SHAW - Shaw Communications Inc., CA 22773 3399 3238 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3233 3188 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3134 3080 VIETEL-AS-AP Viettel Group, VN 10620 3446 3069 Telmex Colombia S.A., CO 11492 3645 3061 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& 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 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:12 /9:10 /10:37 /11:100 /12:294 /13:569 /14:1131 /15:1908 /16:13381 /17:7974 /18:13916 /19:25655 /20:40189 /21:46290 /22:93515 /23:75952 /24:426191 /25:1033 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4356 5432 UNI2-AS, ES 6327 3390 3615 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2854 3645 CABLEONE - CABLE ONE, INC., US 8551 2687 3233 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2634 3399 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2053 2708 Instituto Costarricense de Electricidad y Telec 18566 2002 2107 MEGAPATH5-US - MegaPath Corporation, US 30036 1921 2174 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 7155 1913 2239 VIASAT-SP-BACKBONE - ViaSat,Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1597 2:984 3:6 4:21 5:3124 6:45 7:1 8:1286 9:1 12:1802 13:334 14:1981 15:36 16:4 17:252 18:58 20:50 23:2673 24:2497 25:2 27:2483 31:1977 32:100 35:36 36:853 37:3031 38:1735 39:297 40:121 41:3293 42:780 43:2026 44:149 45:7378 46:3261 47:262 49:1366 50:1109 51:322 52:1015 54:283 55:704 56:6 57:43 58:1792 59:1075 60:501 61:2124 62:2128 63:1831 64:4948 65:2226 66:4836 67:2760 68:1178 69:3530 70:1335 71:617 72:2521 74:2754 75:693 76:543 77:1762 78:1811 79:2290 80:1807 81:1510 82:1127 83:934 84:1134 85:2275 86:523 87:1543 88:1054 89:2597 90:216 91:6571 92:1378 93:2476 94:2516 95:3248 96:941 97:344 98:956 99:508 100:87 101:1157 102:544 103:21062 104:3545 105:256 106:782 107:1787 108:686 109:3723 110:1655 111:1973 112:1486 113:1404 114:1142 115:1723 116:1749 117:1904 118:2189 119:1626 120:1021 121:1042 122:2356 123:1650 124:1470 125:1958 128:1232 129:832 130:536 131:1805 132:794 133:222 134:1088 135:241 136:570 137:749 138:2056 139:864 140:645 141:875 142:801 143:1048 144:890 145:494 146:1261 147:831 148:1717 149:831 150:788 151:1012 152:1059 153:335 154:2901 155:917 156:1635 157:964 158:657 159:1948 160:1602 161:927 162:2757 163:811 164:1198 165:1589 166:434 167:1392 168:3269 169:876 170:4115 171:579 172:1251 173:2211 174:1041 175:923 176:2325 177:4150 178:2544 179:1396 180:2092 181:2418 182:2676 183:1090 184:1709 185:14999 186:3683 187:2445 188:2949 189:1981 190:8272 191:1594 192:10063 193:6654 194:5419 195:4116 196:3151 197:1777 198:5897 199:5989 200:7134 201:5092 202:10413 203:10091 204:4554 205:3039 206:3232 207:3232 208:3959 209:4241 210:3923 211:2009 212:3145 213:2919 214:1108 215:55 216:5922 217:2235 218:882 219:584 220:1857 221:968 222:992 223:1369 End of report From matt at netfire.net Fri Apr 26 18:22:35 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 26 Apr 2019 13:22:35 -0500 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, Apr 26, 2019 at 12:49 PM William Herrin wrote: > I personally support the petition. I think the out of scope reasoning is > flawed. By enforcing minimum assignment sizes, ARIN has long acted as a > gatekeeper to the routing system, controlling who can and can not > participate. For better or worse, that puts the proposal in scope. > > I personally think it's for worse. I oppose the proposal itself. I'd just > as soon ARIN not act as a gatekeeper to BGP and certain don't want to see > it expand that role. > A couple of things spring to mind here now that I've given this a few more minutes' thought. I agree with your reasoning as to why it makes sense for this to be considered in scope for ARIN. As far as expanding roles goes... Over the past few decades, we've all watched as the internet became less and less "wild wild west" and more and more controlled (sometimes centrally, sometimes in a more or less decentralized way) by various organizations and entities. In various and sundry ways, bad actors could get away with plenty of things in 1990 that they cannot so easily today. It may be the case that this problem will be "solved" in some way by someone, but that "someone" may end up being a less engaged community or a less democratic organization than ARIN is. Ultimately, ARIN does a better job than some other internet governance bodies of promoting stakeholder and community interaction and some degree of democracy. We have to consider the question: if some organization is going to expand into this role, is it better that ARIN be the organization to do so instead of one which may be ultimately less democratic and more problematic? One major problem with the proposal, having given it a couple of minutes thought, that I can see as of now would be enforcement being dependent on knowing whom the perpetrator is. If I decide to announce to some other networks some IP space owned by Carlos, but I prepend Bill's ASN to my announcement, how does Carlos know that I'm the bad actor and not Bill? Having good communication between network operators to determine where the issue actually lies is critical. Unfortunately, that doesn't always happen. When we talk about leveraging ARIN's authority or potentially applying penalties of any sort to bad behavior, we have to be able to be certain whom the bad actor is so that the penalties are not inappropriately applied to an uninvolved or innocent third party. Additionally, a question of scope does arise with regard to which resources ARIN would be able to enforce any such policy with regard to. Indeed, the proposal as written currently calls for a "pool of worldwide experts" despite being a proposal submitted to an RIR which is explicitly not worldwide in scope. For example, if a network with an ASN assigned by ARIN is "hijacking" address space that is allocated by APNIC (or any other RIR) to an entity outside of ARIN's region, would this be an issue for ARIN to consider? What if ARIN-registered address space is being "hijacked" by an entity with a RIPE ASN and which is not located within ARIN territory? I suspect that for this proposal to have any meaningful enforcement mechanisms, it would require inter-RIR cooperation on enforcement, and that's a very large can of worms. Not one that is impossible to overcome, but likely one which will require several years of scrutiny, discussion, and negotiation prior to any real world implementation. Ultimately, I don't think I can support a proposal this vague, either. For something like this I think we need a lot more objective language and a lot more specifics and details. We must make policies easy to comply with, and at all costs avoid vagueness which may allow for anything less than completely fair and objective enforcement - regardless of how simple the concept may seem to us on the outset. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Fri Apr 26 18:30:22 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Apr 2019 14:30:22 -0400 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: References: <28895.1556166155@turing-police> <7211acdb-cacd-aeac-f886-d46689831c0c@satchell.net> Message-ID: <20190426183022.GC9117@gsp.org> On Fri, Apr 26, 2019 at 07:06:40PM +0300, T??ma Gavrichenkov wrote: > Also, I've seen people who use the same password (sometimes with few easily > reversible modifications) for virtually all the purposes, from the WiFi > router up to their e-mail and banking accounts. This is one of the many risks incurred here: password re-use is amazingly common (sometimes, as you note, with a few easily reversible modifications). Accruing a database full of these means building a target, and the bigger it is, the more valuable target it will become. Also, given that this is a public mailing list, lots of people who didn't know the target existed last week could certainly know it now. I hear all the arguments in favor of convenience but it's worth noting that making things convenient for support ops in this fashion has the unpleasant side effect of making them convenient for attackers. ---rsk From cfriacas at fccn.pt Fri Apr 26 18:32:55 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 26 Apr 2019 19:32:55 +0100 (WEST) Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: Hi, (please see inline) On Fri, 26 Apr 2019, Matt Harris wrote: (...) > As far as expanding roles goes... Over the past few decades, we've all watched as the internet became less and less "wild wild > west" and more and more controlled (sometimes centrally, sometimes in a more or less decentralized way) by various organizations > and entities.   In various and sundry ways, bad actors could get away with plenty of things in 1990 that they cannot so easily > today.  It may be the case that this problem will be "solved" in some way by someone, but that "someone" may end up being a less > engaged community or a less democratic organization than ARIN is.  Ultimately, ARIN does a better job than some other internet > governance bodies of promoting stakeholder and community interaction and some degree of democracy.  We have to consider the > question: if some organization is going to expand into this role, is it better that ARIN be the organization to do so instead of > one which may be ultimately less democratic and more problematic?   Good point. The same goes for RIPE NCC, LACNIC, AFRINIC and APNIC... > One major problem with the proposal, having given it a couple of minutes thought, that I can see as of now would be enforcement > being dependent on knowing whom the perpetrator is.  If I decide to announce to some other networks some IP space owned by > Carlos, but I prepend Bill's ASN to my announcement, how does Carlos know that I'm the bad actor and not Bill?  Having good > communication between network operators to determine where the issue actually lies is critical.  Unfortunately, that doesn't > always happen.  When we talk about leveraging ARIN's authority or potentially applying penalties of any sort to bad behavior, we > have to be able to be certain whom the bad actor is so that the penalties are not inappropriately applied to an uninvolved or > innocent third party.   There are various sources of public routing data. But yes, sharing more routing views will increase the capacity to look at cases... An uninvolved innocent third party should be able to show it was uninvolved (either by pointing out to public routing data, or by providing their own routing views if needed...) In any case, if there is reasonable doubt, a case should always be dismissed. > Additionally, a question of scope does arise with regard to which resources ARIN would be able to enforce any such policy with > regard to.  Indeed, the proposal as written currently calls for a "pool of worldwide experts" despite being a proposal submitted > to an RIR which is explicitly not worldwide in scope.  For example, if a network with an ASN assigned by ARIN is "hijacking" > address space that is allocated by APNIC (or any other RIR) to an entity outside of ARIN's region, would this be an issue for > ARIN to consider?  What if ARIN-registered address space is being "hijacked" by an entity with a RIPE ASN and which is not > located within ARIN territory?  I suspect that for this proposal to have any meaningful enforcement mechanisms, it would require > inter-RIR cooperation on enforcement, and that's a very large can of worms.  Not one that is impossible to overcome, but likely > one which will require several years of scrutiny, discussion, and negotiation prior to any real world implementation.   Yes, this needs to be in place in every RIR to maximize efectiveness. The idea of a "pool of worldwide experts" was to allow any RIR to use people from the same (larger) pool. > Ultimately, I don't think I can support a proposal this vague, either.  For something like this I think we need a lot more > objective language and a lot more specifics and details.  We must make policies easy to comply with, and at all costs avoid > vagueness which may allow for anything less than completely fair and objective enforcement - regardless of how simple the > concept may seem to us on the outset.   Your comment in pretty much inline with some comments opposing version 1.0 in RIPE. Hopefully version 2.0 will be published next week. And it's a bit more "extensive" regarding details... :-) Regards, Carlos > Take care, > Matt > > > From bill at herrin.us Fri Apr 26 18:44:04 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Apr 2019 11:44:04 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: On Thu, Apr 25, 2019 at 1:06 PM Anne P. Mitchell, Esq. wrote: > > On Apr 25, 2019, at 1:41 PM, Tom Beecher wrote: > > > > It seems like just another example of liability shifting/shielding. I'll defer to Actual Lawyers obviously, but the way I see it, Packetstream doesn't have any contractual or business relationship with my ISP. I do. If I sell them my bandwidth, and my ISP decides to take action, they come after me, not Packetstream. I can plead all I want about how I was just running "someone else's software" , but that isn't gonna hold up, since I am responsible for what is running on my home network, knowingly or unknowingly. > > And *that* is *exactly* my concern. Because those users...('you' in this example)...they have *no idea* it is causing them to violate their ToS/AUP with their provider. If you put your apartment on airbnb without knowing whether subletting is against the terms of your lease... well, there's just no cure for stupid. > Anne P. Mitchell, > Attorney at Law > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Former Counsel: Mail Abuse Prevention System (MAPS) > California Bar Association > Cal. Bar Cyberspace Law Committee > Colorado Cyber Committee > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop That is an obnoxious signature block. Just sayin'. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Fri Apr 26 18:57:03 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 26 Apr 2019 21:57:03 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> References: <4d358bcf-79b4-57cd-13a2-465ab376d2ad@rollernet.us> <4a09ecce-5522-95ad-68d0-782720dd0de6@dougbarton.us> Message-ID: On Thu, 25 Apr 2019 at 20:17, Doug Barton wrote: > There are two mindsets that desperately need changing in the tech world: > > 1. Do not store data that you don't have a legitimate requirement to store > 2. Do not store anything even remotely sensitive in the clear #2 might be quite complex There might be all kind of instrumentation built by people who don't realise or have no easy ability to discriminate what is sensitive data. Like someone might build really great JVM/Beam/GraalVM instrumentation to monitor for performance regressions and deep analytics, some of the analytic data collected potentially could be sensitive. Or you might have some database where you store all exception traces and core dumps and machine analyse them, those could contain sensitive data. Or you could have analytics on UX, how people interact with the software. Or you could have internal network tap/sflow with decryption to better understand where network I/O bottlenecks are or something else that can't even think of now, but will be obvious after I read about it. Looking at the late Facebook 'clear text PW', it doesn't read to me like they had user auth data in database in plain text, it reads to me like they had some debugging on for one specific application, and people using that application to authenticate to facebook had their PW with other debugging data stored somewhere. I don't think it's tenable to hope that your sensitive data is being handle as sensitive data or assume it is outlier when it is not. I assume every sufficiently large and old company has my password stored somewhere in clear text right now without them realising it and they might come public when they realise it in few years time. We're particularly vulnerable when we think it as simple problem as hash in database and we would never do something so stupid as store cleartext in DB. -- ++ytti From jordi.palet at consulintel.es Fri Apr 26 19:11:30 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Apr 2019 21:11:30 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: El 26/4/19 20:25, "NANOG en nombre de Matt Harris" escribió: On Fri, Apr 26, 2019 at 12:49 PM William Herrin wrote: I personally support the petition. I think the out of scope reasoning is flawed. By enforcing minimum assignment sizes, ARIN has long acted as a gatekeeper to the routing system, controlling who can and can not participate. For better or worse, that puts the proposal in scope. I personally think it's for worse. I oppose the proposal itself. I'd just as soon ARIN not act as a gatekeeper to BGP and certain don't want to see it expand that role. A couple of things spring to mind here now that I've given this a few more minutes' thought. I agree with your reasoning as to why it makes sense for this to be considered in scope for ARIN. As far as expanding roles goes... Over the past few decades, we've all watched as the internet became less and less "wild wild west" and more and more controlled (sometimes centrally, sometimes in a more or less decentralized way) by various organizations and entities. In various and sundry ways, bad actors could get away with plenty of things in 1990 that they cannot so easily today. It may be the case that this problem will be "solved" in some way by someone, but that "someone" may end up being a less engaged community or a less democratic organization than ARIN is. Ultimately, ARIN does a better job than some other internet governance bodies of promoting stakeholder and community interaction and some degree of democracy. We have to consider the question: if some organization is going to expand into this role, is it better that ARIN be the organization to do so instead of one which may be ultimately less democratic and more problematic? Exactly, one of our thoughts (as co-authors) is: if we do nothing, some other governmental bodies will take care of it, even courts, taking irrational judgments. One major problem with the proposal, having given it a couple of minutes thought, that I can see as of now would be enforcement being dependent on knowing whom the perpetrator is. If I decide to announce to some other networks some IP space owned by Carlos, but I prepend Bill's ASN to my announcement, how does Carlos know that I'm the bad actor and not Bill? Having good communication between network operators to determine where the issue actually lies is critical. Unfortunately, that doesn't always happen. When we talk about leveraging ARIN's authority or potentially applying penalties of any sort to bad behavior, we have to be able to be certain whom the bad actor is so that the penalties are not inappropriately applied to an uninvolved or innocent third party. The proposal is “guarantor”, or at least that’s our intent. Is not ARIN taking the decision, is the community by means of experts. We have improved it in the v2 that will be posted in a matter of days in RIPE, but we can’t improve it in ARIN because simply discussing it is not allowed by the AC decision. One thing to clarify, is that the policy is basically saying something that is written in all the RIRs documents: “if you get resources from us, you have the exclusive right to use them or your authorized customers”. Now if another ARIN member is misusing your resources (not by an operational mistake, but repeatedly), ARIN is not going to do anything about it? In any membership association, members are bound to the rules (policies in the case of RIRs), and members can’t act against the rights of OTHER members. If you don’t follow the rules, you can get a warning, or even lose your membership. If you go to courts because you lost your membership, courts will confirm “you have not followed the rules, so the association has the right to get you out”. Is not a problem or ARIN becoming the “routing police”. This has been completely misunderstood by the AC. Is about ARIN making sure that the rights of the members are respected by other members. And again, it must be clear that it is intentional, not a mistake, not fat fingers. Without clear rules, other members can do whatever they want with resources allocated to another member. Additionally, a question of scope does arise with regard to which resources ARIN would be able to enforce any such policy with regard to. Indeed, the proposal as written currently calls for a "pool of worldwide experts" despite being a proposal submitted to an RIR which is explicitly not worldwide in scope. For example, if a network with an ASN assigned by ARIN is "hijacking" address space that is allocated by APNIC (or any other RIR) to an entity outside of ARIN's region, would this be an issue for ARIN to consider? What if ARIN-registered address space is being "hijacked" by an entity with a RIPE ASN and which is not located within ARIN territory? I suspect that for this proposal to have any meaningful enforcement mechanisms, it would require inter-RIR cooperation on enforcement, and that's a very large can of worms. Not one that is impossible to overcome, but likely one which will require several years of scrutiny, discussion, and negotiation prior to any real world implementation. This has been clarified in v2 that I mention before, to be publish in RIPE. The idea is that the claim is done in the region where the hijacker is a member (assuming that we get the policy going thru all the regions). Note that we are submitting the same policy proposal adapted to each of the 5 RIRs. Ultimately, I don't think I can support a proposal this vague, either. For something like this I think we need a lot more objective language and a lot more specifics and details. We must make policies easy to comply with, and at all costs avoid vagueness which may allow for anything less than completely fair and objective enforcement - regardless of how simple the concept may seem to us on the outset. Right, we have a more complete v2 with many procedural details, which we can’t even discuss in ARIN, and obviously the idea of the PDP is to allow the policy proposals to be discussed until we reach a text that we can agree. So please, if you want to get this discussion going on in the right place subscribe to ARIN PPML (https://lists.arin.net/mailman/listinfo/arin-ppml) and respond to the attached email, just to support the discussion (no need to agree at all now with the text). Thanks! Jordi Take care, Matt ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: JORDI PALET MARTINEZ via ARIN-PPML Subject: [arin-ppml] Discussion Petition (Proposal has not been accepted as a Draft Policy) Date: Fri, 26 Apr 2019 17:22:17 +0200 Size: 9361 URL: From chrisp at us.ibm.com Fri Apr 26 18:23:55 2019 From: chrisp at us.ibm.com (Christopher Papandreou) Date: Fri, 26 Apr 2019 13:23:55 -0500 Subject: SoftLayer NOC contact to get two IP prefixes de-announced In-Reply-To: <2219d3b2-f10e-7150-3ac1-bf82ce36cf6b@meo.ws> References: <2219d3b2-f10e-7150-3ac1-bf82ce36cf6b@meo.ws> Message-ID: Hi Katie, Can you send me an email off list please? I'm going to see if I can get some movement on this for you. Thanks, ChrisP. From: Katie Holly To: NANOG list Date: 04/26/2019 08:03 AM Subject: SoftLayer NOC contact to get two IP prefixes de-announced Sent by: "NANOG" Hi, anyone from SoftLayer (AS36351) around or someone with a contact to their NOC? They have been announcing two /24's from us without permission and we'd like them to remove the announcement immediately. Emails were sent to ipadmin at softlayer.com, abuse at ibm.com and ipreg at us.ibm.com without success hence I'm reaching out to this list as a last resort. Thanks -- Best regards Katie Holly -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Fri Apr 26 20:06:59 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 26 Apr 2019 23:06:59 +0300 Subject: Comcast storing WiFi passwords in cleartext? In-Reply-To: <20190426183022.GC9117@gsp.org> References: <28895.1556166155@turing-police> <7211acdb-cacd-aeac-f886-d46689831c0c@satchell.net> <20190426183022.GC9117@gsp.org> Message-ID: On Fri, Apr 26, 2019, 9:31 PM Rich Kulawiec wrote: > Also, given that this is a public mailing list, lots of people who didn't > know the target existed last week could certainly know it now. > Yup, the dependency on an obscurity was inadvertently broken here. Sorry for that. Hope no one was really relying on it though. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Fri Apr 26 20:28:06 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Apr 2019 16:28:06 -0400 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: <20190426164719.GA85521@gweep.net> References: <20190426164719.GA85521@gweep.net> Message-ID: <89E360B4-1AF7-415F-A641-82F44D2B2B7E@puck.nether.net> There are factual errors in the ARIN meeting minutes. It really is a disservice that people on the AC don’t have facts about ARIN and the function of their routing registry (for example). It would be good if the ARIN AC had people that were more aware of the functions ARIN provides. If you control vote of resources by ARIN I encourage you to use this as part of your process. Sent from my iCar > On Apr 26, 2019, at 12:47 PM, Joe Provo wrote: > >> On Fri, Apr 26, 2019 at 11:41:18AM -0500, Matt Harris wrote: >> [snip] >> Can you (or someone else on the list, perhaps even someone who was involved >> in voting this down) provide some more details as to why it was rejected? >> What were the arguments in favor of rejecting the proposal? This seems >> like an interesting idea to me, and one that I can't immediately come up >> with any arguments against from my own perspective. There's probably some >> room for discussing and tuning specifics, but ultimately the concept seems >> reasonable to me. What am I missing here? > > Speaking solely for myself, it would be reasonable to start > any discussion based upon the on-record rationales for its > rejection. As such I would direct interested parties to the > Draft Advisory Council Meeting minutes from April 10 > https://www.arin.net/about/welcome/ac/meetings/2019_0410/ > > and most specifically on that page > "16. ARIN-Prop-266: BGP Hijacking is an ARIN Policy Violation" > > Cheers, > > Joe > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling From amitchell at isipp.com Fri Apr 26 20:55:32 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 26 Apr 2019 14:55:32 -0600 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> Message-ID: <9ABF3D64-6251-4FEF-B626-4E0CFB37CA87@isipp.com> Apparently, after many, many years of using essentially the same .sig here, it is now an issue of contention. (Well, 3 people probably does not contention make, but still...). However, as one person decided I was trying to market myself, let me address why I have all of that info in there: Primarily I leave in all of my background because people (at least those here in the states) tend to a) assume that attorneys are all just "corporate suits" with no understanding of or experience with deep Internet issues, and b) attorneys are generally disliked. ;-) Over the years I've found that it's best to include my chops right up front, so folks can be reassured that I'm not only on the right (white hat) side of things, but that I actually do know what I'm talking about. I can tell you absolutely that the pushback I get from people in our industries who *don't* know my background, when I provide information based on that background and my expertise, is far greater, and bordering at times on abusive (come to think of it, not unlike some of the pushback I got when I first arrived at MAPS, from a certain volunteer ;-)). I'm open to suggestions (other than the suggestion to sod off). Anne [This .sig space open to suggestions.] From amitchell at isipp.com Fri Apr 26 20:58:30 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 26 Apr 2019 14:58:30 -0600 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) In-Reply-To: <9ABF3D64-6251-4FEF-B626-4E0CFB37CA87@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> <9ABF3D64-6251-4FEF-B626-4E0CFB37CA87@isipp.com> Message-ID: <97D257D2-D144-4F73-B697-4C971C30641C@isipp.com> Oops..sorry to follow up on myself (and before anybody says anything about this, sorry/not sorry for top-posting - it's on myself after all)..but I'd meant to include this: Case in point: This very (original) thread, about Packetstream - if I had just posted the original thread, about how it's inducing users to violate their providers' ToS, how that's a breach of contract, etc... how many here would have a) not given a second thought, writing it off as the rantings of at best someone who doesn't know anything, and at worst a troll, or b) would have challenged me to explain my credentials - which would have take up far more space than my .sig :-( Anne > On Apr 26, 2019, at 2:55 PM, Anne P. Mitchell, Esq. wrote: > > Apparently, after many, many years of using essentially the same .sig here, it is now an issue of contention. (Well, 3 people probably does not contention make, but still...). > > However, as one person decided I was trying to market myself, let me address why I have all of that info in there: > > Primarily I leave in all of my background because people (at least those here in the states) tend to a) assume that attorneys are all just "corporate suits" with no understanding of or experience with deep Internet issues, and b) attorneys are generally disliked. ;-) Over the years I've found that it's best to include my chops right up front, so folks can be reassured that I'm not only on the right (white hat) side of things, but that I actually do know what I'm talking about. > > I can tell you absolutely that the pushback I get from people in our industries who *don't* know my background, when I provide information based on that background and my expertise, is far greater, and bordering at times on abusive (come to think of it, not unlike some of the pushback I got when I first arrived at MAPS, from a certain volunteer ;-)). > > I'm open to suggestions (other than the suggestion to sod off). > > Anne > > [This .sig space open to suggestions.] > From ross at tajvar.io Fri Apr 26 21:14:00 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 26 Apr 2019 17:14:00 -0400 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) In-Reply-To: <97D257D2-D144-4F73-B697-4C971C30641C@isipp.com> References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> <9ABF3D64-6251-4FEF-B626-4E0CFB37CA87@isipp.com> <97D257D2-D144-4F73-B697-4C971C30641C@isipp.com> Message-ID: I want to clarify that while I didn't say anything (since it wasn't on-topic in the other thread), I also found the long signature annoying. I did not read it beyond the first 1-2 lines. I expect many more than the few people who spoke up share this opinion. While I don't feel it's appropriate for people to complain about something so trivial as an email signature in a pseudo-professional setting, apparently we're doing it today. I don't like email signatures in general, but since you asked for suggestions, I suggest using your name and one title that seems most relevant/important. On another note: I don't think you need credentials to be taken seriously here as long as you present a respectful and coherent argument. I would not have questioned your background if you had posted this without credentials, or if anyone else had posted it. I don't recognize the names of most of the "top talkers" or know their credentials, other than my assumption that they are network operators of some sort. I'm sorry that you've had negative experiences re: your background. Ultimately, it is up to each individual whether they choose to respect others and for what reasons. There is little we can do to influence that. On Fri, Apr 26, 2019 at 5:01 PM Anne P. Mitchell, Esq. wrote: > Oops..sorry to follow up on myself (and before anybody says anything about > this, sorry/not sorry for top-posting - it's on myself after all)..but I'd > meant to include this: > > > Case in point: This very (original) thread, about Packetstream - if I had > just posted the original thread, about how it's inducing users to violate > their providers' ToS, how that's a breach of contract, etc... how many here > would have a) not given a second thought, writing it off as the rantings of > at best someone who doesn't know anything, and at worst a troll, or b) > would have challenged me to explain my credentials - which would have take > up far more space than my .sig :-( > > Anne > > > On Apr 26, 2019, at 2:55 PM, Anne P. Mitchell, Esq. > wrote: > > > > Apparently, after many, many years of using essentially the same .sig > here, it is now an issue of contention. (Well, 3 people probably does not > contention make, but still...). > > > > However, as one person decided I was trying to market myself, let me > address why I have all of that info in there: > > > > Primarily I leave in all of my background because people (at least those > here in the states) tend to a) assume that attorneys are all just > "corporate suits" with no understanding of or experience with deep Internet > issues, and b) attorneys are generally disliked. ;-) Over the years I've > found that it's best to include my chops right up front, so folks can be > reassured that I'm not only on the right (white hat) side of things, but > that I actually do know what I'm talking about. > > > > I can tell you absolutely that the pushback I get from people in our > industries who *don't* know my background, when I provide information based > on that background and my expertise, is far greater, and bordering at times > on abusive (come to think of it, not unlike some of the pushback I got when > I first arrived at MAPS, from a certain volunteer ;-)). > > > > I'm open to suggestions (other than the suggestion to sod off). > > > > Anne > > > > [This .sig space open to suggestions.] > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Fri Apr 26 21:23:34 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 26 Apr 2019 16:23:34 -0500 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: On 4/12/19 2:31 PM, Chris Grundemann wrote: > > > > On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger > wrote: > > An article mentioned BAMTech's platform which is what NHL, MLB, and > HBO GO are built on. The bits from the first two come from Akamai > and Level3 CDNs. I haven't looked into where HBO Go comes from. > > > Yep, they decided to buy BAMTech and build their own: > https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > So, on a practical level, with whom should I peer so as not to jack up my transit costs? From ross at tajvar.io Fri Apr 26 21:33:36 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 26 Apr 2019 17:33:36 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: Looks like Disney has an ASN for their streaming service: https://www.peeringdb.com/net/15627 On Fri, Apr 26, 2019 at 5:26 PM Bryan Holloway wrote: > > On 4/12/19 2:31 PM, Chris Grundemann wrote: > > > > > > > > On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger > > wrote: > > > > An article mentioned BAMTech's platform which is what NHL, MLB, and > > HBO GO are built on. The bits from the first two come from Akamai > > and Level3 CDNs. I haven't looked into where HBO Go comes from. > > > > > > Yep, they decided to buy BAMTech and build their own: > > > https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/ > > > > So, on a practical level, with whom should I peer so as not to jack up > my transit costs? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Fri Apr 26 21:36:01 2019 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 26 Apr 2019 17:36:01 -0400 (EDT) Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, 26 Apr 2019, William Herrin wrote: > On Fri, Apr 26, 2019 at 9:41 AM Matt Harris wrote: > Can you (or someone else on the list, perhaps even someone who was involved in voting this down) provide some more details as to why it was rejected? > > > Hi Matt, > > As I understand it (someone with better knowledge feel free to correct me) the proposal was ruled out of scope for ARIN because ARIN registers numbers, it doesn't > decide how they're allowed to be routed. ISPs do that.  > > I personally support the petition. I think the out of scope reasoning is flawed. By enforcing minimum assignment sizes, ARIN has long acted as a gatekeeper to the > routing system, controlling who can and can not participate. For better or worse, that puts the proposal in scope. > > I personally think it's for worse. I oppose the proposal itself. I'd just as soon ARIN not act as a gatekeeper to BGP and certain don't want to see it expand that > role.  Maybe I missed it in the proposal, but I don't see that it actually says what ARIN will do other than produce a report "Yep, our expert panel says this is hijacked.". What's the expected result (other than the report)? i.e. What action is ARIN expected to take after it's determined a route advertisement is a hijacking that will make a difference? Anecdotally, ARIN has, in the past, gotten involved in this sort of thing. Many years ago, during an acquisition that went sour at the last minute, the renegging seller went to ARIN complaining that we were hijacking his IP space. ARIN contacted our upstreams and pressured them to pressure us to stop advertising the IP space. Perhaps there's no official policy, and perhaps they wouldn't do this today without one? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bryan at shout.net Fri Apr 26 21:37:38 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 26 Apr 2019 16:37:38 -0500 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: On 4/26/19 4:33 PM, Ross Tajvar wrote: > Looks like Disney has an ASN for their streaming service: > https://www.peeringdb.com/net/15627 > Helluva entry ... *crickets* *tumbleweeds* From beecher at beecher.cc Fri Apr 26 21:39:14 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 26 Apr 2019 17:39:14 -0400 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) In-Reply-To: References: <20190425192128.13E602012EF7BF@ary.qy> <3CB6E8F3-2D4E-4489-AFD2-080E43E7205A@isipp.com> <9ABF3D64-6251-4FEF-B626-4E0CFB37CA87@isipp.com> <97D257D2-D144-4F73-B697-4C971C30641C@isipp.com> Message-ID: I respect the viewpoints of those who made comments about your sig, but I do not agree. There are many things to be annoyed about. I don’t think your email signature is one of them. On Fri, Apr 26, 2019 at 17:16 Ross Tajvar wrote: > I want to clarify that while I didn't say anything (since it wasn't > on-topic in the other thread), I also found the long signature annoying. I > did not read it beyond the first 1-2 lines. I expect many more than the few > people who spoke up share this opinion. > > While I don't feel it's appropriate for people to complain about something > so trivial as an email signature in a pseudo-professional > setting, apparently we're doing it today. > > I don't like email signatures in general, but since you asked for > suggestions, I suggest using your name and one title that seems most > relevant/important. > > On another note: I don't think you need credentials to be taken seriously > here as long as you present a respectful and coherent argument. I would not > have questioned your background if you had posted this without credentials, > or if anyone else had posted it. I don't recognize the names of most of the > "top talkers" or know their credentials, other than my assumption that they > are network operators of some sort. > > I'm sorry that you've had negative experiences re: your background. > Ultimately, it is up to each individual whether they choose to respect > others and for what reasons. There is little we can do to influence that. > > On Fri, Apr 26, 2019 at 5:01 PM Anne P. Mitchell, Esq. < > amitchell at isipp.com> wrote: > >> Oops..sorry to follow up on myself (and before anybody says anything >> about this, sorry/not sorry for top-posting - it's on myself after >> all)..but I'd meant to include this: >> >> >> Case in point: This very (original) thread, about Packetstream - if I >> had just posted the original thread, about how it's inducing users to >> violate their providers' ToS, how that's a breach of contract, etc... how >> many here would have a) not given a second thought, writing it off as the >> rantings of at best someone who doesn't know anything, and at worst a >> troll, or b) would have challenged me to explain my credentials - which >> would have take up far more space than my .sig :-( >> >> Anne >> >> > On Apr 26, 2019, at 2:55 PM, Anne P. Mitchell, Esq. < >> amitchell at isipp.com> wrote: >> > >> > Apparently, after many, many years of using essentially the same .sig >> here, it is now an issue of contention. (Well, 3 people probably does not >> contention make, but still...). >> > >> > However, as one person decided I was trying to market myself, let me >> address why I have all of that info in there: >> > >> > Primarily I leave in all of my background because people (at least >> those here in the states) tend to a) assume that attorneys are all just >> "corporate suits" with no understanding of or experience with deep Internet >> issues, and b) attorneys are generally disliked. ;-) Over the years I've >> found that it's best to include my chops right up front, so folks can be >> reassured that I'm not only on the right (white hat) side of things, but >> that I actually do know what I'm talking about. >> > >> > I can tell you absolutely that the pushback I get from people in our >> industries who *don't* know my background, when I provide information based >> on that background and my expertise, is far greater, and bordering at times >> on abusive (come to think of it, not unlike some of the pushback I got when >> I first arrived at MAPS, from a certain volunteer ;-)). >> > >> > I'm open to suggestions (other than the suggestion to sod off). >> > >> > Anne >> > >> > [This .sig space open to suggestions.] >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Apr 26 21:41:39 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 26 Apr 2019 17:41:39 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: Yeah, I'm going to send them an email and see if I can get ahold of their peering policy. I'm hoping they will update it as they get more attention from other networks. They may just be procrastinating setting things up. According to bgp.he.net they are only announcing one v4 /24 and one v6 /48, which *could* be enough IPs, but seems a little on the small side. On Fri, Apr 26, 2019 at 5:37 PM Bryan Holloway wrote: > > > On 4/26/19 4:33 PM, Ross Tajvar wrote: > > Looks like Disney has an ASN for their streaming service: > > https://www.peeringdb.com/net/15627 > > > > Helluva entry ... > > *crickets* > *tumbleweeds* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Apr 26 21:45:05 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 26 Apr 2019 17:45:05 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: Sorry for the double email but I wanted to add - the ARIN org was only created in November 2018: OrgName: Disney Streaming Services OrgId: DSTL-2 Address: 75 9th Ave. Address: 6th Floor City: New York StateProv: NY PostalCode: 10011 Country: US RegDate: 2018-11-15 Updated: 2018-11-15 Ref: https://rdap.arin.net/registry/entity/DSTL-2 On Fri, Apr 26, 2019 at 5:41 PM Ross Tajvar wrote: > Yeah, I'm going to send them an email and see if I can get ahold of their > peering policy. > > I'm hoping they will update it as they get more attention from other > networks. They may just be procrastinating setting things up. According to > bgp.he.net they are only announcing one v4 /24 and one v6 /48, which > *could* be enough IPs, but seems a little on the small side. > > On Fri, Apr 26, 2019 at 5:37 PM Bryan Holloway wrote: > >> >> >> On 4/26/19 4:33 PM, Ross Tajvar wrote: >> > Looks like Disney has an ASN for their streaming service: >> > https://www.peeringdb.com/net/15627 >> > >> >> Helluva entry ... >> >> *crickets* >> *tumbleweeds* >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Apr 26 21:49:33 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 26 Apr 2019 16:49:33 -0500 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, Apr 26, 2019 at 4:37 PM Jon Lewis wrote: > > Anecdotally, ARIN has, in the past, gotten involved in this sort of thing. > Many years ago, during an acquisition that went sour at the last minute, > the renegging seller went to ARIN complaining that we were hijacking his > IP space. ARIN contacted our upstreams and pressured them to pressure us > to stop advertising the IP space. Perhaps there's no official policy, and > perhaps they wouldn't do this today without one? > I would argue that action without an explicit official policy that outlines the circumstances under which what action is taken is just asking for awkward situations to arise. - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Apr 26 21:49:28 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Apr 2019 23:49:28 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: <89E360B4-1AF7-415F-A641-82F44D2B2B7E@puck.nether.net> References: <20190426164719.GA85521@gweep.net> <89E360B4-1AF7-415F-A641-82F44D2B2B7E@puck.nether.net> Message-ID: Not only that. I really think they have not invested enough time to read the proposal, check with the authors and then take a decision. We have got some email exchange, but clearly not sufficient. I also must state that the staff has been very helpful and diligent to clarify and support the petition process. Just the point is, should have never been needed, it exposes how bad (in my opinion) is the ARIN AC model. Some details: This is absolutely fake: "AP stated that at the LACNIC meeting has discussed it and they dismissed it as out of scope." LACNIC will have the first meeting where this topic will be discussed in two weeks from now. How come an AC member can lie such way? If I'm an AC member, or any other similar team, I will make sure to inform myself before stating something like that. In this case there is no excuse, you just need to visit a web page for the LACNIC policy proposals, similar in every RIR. Then I continue reading this: "AP stated that she believed that the author was using ARIN to solve their problem." How come somebody that doesn't know me, can state that? In my country, at least, this is an illegal (criminal) act (slander, ad hominem, etc.), unless you can prove that what you're suggesting is *actually true*. I don't want to make a problem with that or even consider to go to courts with the case, but I really think that before saying that from someone, you must talk to him before. I'm a very open and transparent guy, and I *never ever* did a policy proposal for *any* personal or even business motivation. I did that because if I discover an issue, and I believe I can contribute to resolve it and it will be good for the community, I just go for it. Even in several occasions my own proposal has been ***against*** my personal point of view and when I presented those policies I *clearly* stated that (for example when I was presenting policy proposals in all the 5 RIRs for IPv6 PI and I can find the videos if somebody doubt what I'm saying). And by the way, I'm not new on this. A month ago, during the IETF meeting in Prague, somebody asked me how many proposals I've submitted to all the RIRs (since my first one around 2003 or so). I didn't know, no idea at all, so I decided to count them, and then I discovered that I authored over 75 (a few of them with other co-authors). And this isn't including an average of 3-4 versions of each one, or many other documents in IETF (and the "n" number of versions of each one as well). I do this at the cost of my own personal pocket for traveling to the RIR meetings, I contribute as much as I can with tutorials, workshops, presentations, all kind of documents, articles, sharing my *own* time. So, reading that is really exasperating and frustrating. And just to be clear, let me state that I don't have anything against anyone in the AC or ARIN. In fact, I've been always convinced that the AC model for the PDP in ARIN is a bad one, and this is demonstrating that. Authors and comminity lose the control on a policy proposal at some point (and in this case is even rejected before starting). Speaking in general, even if a proposal don't reach consensus, I'm sure any open discussion is always very productive and can bring new ideas, or new approaches to the problem. In the Internet RIRs system, I don't think we need a kind of "representative democracy". The community is able to use, in any of the 5 RIRs, a very simple process to work on achieving (or not) consensus in policy proposals: a mailing list. Regards, Jordi El 26/4/19 22:35, "NANOG en nombre de Jared Mauch" escribió: There are factual errors in the ARIN meeting minutes. It really is a disservice that people on the AC don’t have facts about ARIN and the function of their routing registry (for example). It would be good if the ARIN AC had people that were more aware of the functions ARIN provides. If you control vote of resources by ARIN I encourage you to use this as part of your process. Sent from my iCar > On Apr 26, 2019, at 12:47 PM, Joe Provo wrote: > >> On Fri, Apr 26, 2019 at 11:41:18AM -0500, Matt Harris wrote: >> [snip] >> Can you (or someone else on the list, perhaps even someone who was involved >> in voting this down) provide some more details as to why it was rejected? >> What were the arguments in favor of rejecting the proposal? This seems >> like an interesting idea to me, and one that I can't immediately come up >> with any arguments against from my own perspective. There's probably some >> room for discussing and tuning specifics, but ultimately the concept seems >> reasonable to me. What am I missing here? > > Speaking solely for myself, it would be reasonable to start > any discussion based upon the on-record rationales for its > rejection. As such I would direct interested parties to the > Draft Advisory Council Meeting minutes from April 10 > https://www.arin.net/about/welcome/ac/meetings/2019_0410/ > > and most specifically on that page > "16. ARIN-Prop-266: BGP Hijacking is an ARIN Policy Violation" > > Cheers, > > Joe > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jlewis at lewis.org Fri Apr 26 21:51:58 2019 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 26 Apr 2019 17:51:58 -0400 (EDT) Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: On Fri, 26 Apr 2019, Ross Tajvar wrote: > Yeah, I'm going to send them an email and see if I can get ahold of their peering policy. > I'm hoping they will update it as they get more attention from other networks. They may just be procrastinating > setting things up. According to bgp.he.net they are only announcing one v4 /24 and one v6 /48, which could be > enough IPs, but seems a little on the small side. I'd be much more worried about only being on one IX than only advertising a single /24 and /48. I'm guessing they've just not fully fleshed out the peeringdb entry and maybe not fully built out the network infrastructure yet. A CDN, with everything coming from one POP in NY is not going to cut it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jordi.palet at consulintel.es Fri Apr 26 21:58:00 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 26 Apr 2019 23:58:00 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> The intent is to clearly state that this is a violation of the policies. The membership documents/bylaws or the RSA, your account may be closed. I looked at it when adapting the policy from RIPE to ARIN, don't have this information right in my mind, but I'm sure it was there. Otherwise, if needed another policy should state something like "if you keep violating policies" this and that may happen. This should be something generic for *any* policy violation not in general. We have this in RIPE and LACNIC, and I'm also convinced that in APNIC and AFRINIC (still working on those versions). Regards, Jordi El 26/4/19 23:41, "NANOG en nombre de Jon Lewis" escribió: On Fri, 26 Apr 2019, William Herrin wrote: > On Fri, Apr 26, 2019 at 9:41 AM Matt Harris wrote: > Can you (or someone else on the list, perhaps even someone who was involved in voting this down) provide some more details as to why it was rejected? > > > Hi Matt, > > As I understand it (someone with better knowledge feel free to correct me) the proposal was ruled out of scope for ARIN because ARIN registers numbers, it doesn't > decide how they're allowed to be routed. ISPs do that. > > I personally support the petition. I think the out of scope reasoning is flawed. By enforcing minimum assignment sizes, ARIN has long acted as a gatekeeper to the > routing system, controlling who can and can not participate. For better or worse, that puts the proposal in scope. > > I personally think it's for worse. I oppose the proposal itself. I'd just as soon ARIN not act as a gatekeeper to BGP and certain don't want to see it expand that > role. Maybe I missed it in the proposal, but I don't see that it actually says what ARIN will do other than produce a report "Yep, our expert panel says this is hijacked.". What's the expected result (other than the report)? i.e. What action is ARIN expected to take after it's determined a route advertisement is a hijacking that will make a difference? Anecdotally, ARIN has, in the past, gotten involved in this sort of thing. Many years ago, during an acquisition that went sour at the last minute, the renegging seller went to ARIN complaining that we were hijacking his IP space. ARIN contacted our upstreams and pressured them to pressure us to stop advertising the IP space. Perhaps there's no official policy, and perhaps they wouldn't do this today without one? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Fri Apr 26 22:05:33 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Apr 2019 00:05:33 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> References: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> Message-ID: <5F599E73-9AC5-437B-9398-254E0A8A5077@consulintel.es> By the way, even if ARIN (or the community) decides to do *nothing* in case of a policy violation, clearly the victim will have a better situation to defend the case in courts, and not rely in the judgement of inexperienced folks that will know nothing about what is an Internet Resource, BGP, etc., etc. Regards, Jordi El 27/4/19 0:03, "NANOG en nombre de JORDI PALET MARTINEZ via NANOG" escribió: The intent is to clearly state that this is a violation of the policies. The membership documents/bylaws or the RSA, your account may be closed. I looked at it when adapting the policy from RIPE to ARIN, don't have this information right in my mind, but I'm sure it was there. Otherwise, if needed another policy should state something like "if you keep violating policies" this and that may happen. This should be something generic for *any* policy violation not in general. We have this in RIPE and LACNIC, and I'm also convinced that in APNIC and AFRINIC (still working on those versions). Regards, Jordi El 26/4/19 23:41, "NANOG en nombre de Jon Lewis" escribió: On Fri, 26 Apr 2019, William Herrin wrote: > On Fri, Apr 26, 2019 at 9:41 AM Matt Harris wrote: > Can you (or someone else on the list, perhaps even someone who was involved in voting this down) provide some more details as to why it was rejected? > > > Hi Matt, > > As I understand it (someone with better knowledge feel free to correct me) the proposal was ruled out of scope for ARIN because ARIN registers numbers, it doesn't > decide how they're allowed to be routed. ISPs do that. > > I personally support the petition. I think the out of scope reasoning is flawed. By enforcing minimum assignment sizes, ARIN has long acted as a gatekeeper to the > routing system, controlling who can and can not participate. For better or worse, that puts the proposal in scope. > > I personally think it's for worse. I oppose the proposal itself. I'd just as soon ARIN not act as a gatekeeper to BGP and certain don't want to see it expand that > role. Maybe I missed it in the proposal, but I don't see that it actually says what ARIN will do other than produce a report "Yep, our expert panel says this is hijacked.". What's the expected result (other than the report)? i.e. What action is ARIN expected to take after it's determined a route advertisement is a hijacking that will make a difference? Anecdotally, ARIN has, in the past, gotten involved in this sort of thing. Many years ago, during an acquisition that went sour at the last minute, the renegging seller went to ARIN complaining that we were hijacking his IP space. ARIN contacted our upstreams and pressured them to pressure us to stop advertising the IP space. Perhaps there's no official policy, and perhaps they wouldn't do this today without one? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From ross at tajvar.io Fri Apr 26 22:06:09 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 26 Apr 2019 18:06:09 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: Agreed, I noticed the single IX as well and asked them about it in my email. If they don't expand aggressively in the next ~6 months, they're going to have a very problematic launch. On Fri, Apr 26, 2019 at 5:59 PM Jon Lewis wrote: > On Fri, 26 Apr 2019, Ross Tajvar wrote: > > > Yeah, I'm going to send them an email and see if I can get ahold of > their peering policy. > > I'm hoping they will update it as they get more attention from other > networks. They may just be procrastinating > > setting things up. According to bgp.he.net they are only announcing one > v4 /24 and one v6 /48, which could be > > enough IPs, but seems a little on the small side. > > I'd be much more worried about only being on one IX than only advertising > a single /24 and /48. I'm guessing they've just not fully fleshed out the > peeringdb entry and maybe not fully built out the network infrastructure > yet. A CDN, with everything coming from one POP in NY is not going to cut > it. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at lewis.org Fri Apr 26 22:08:24 2019 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 26 Apr 2019 18:08:24 -0400 (EDT) Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> References: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> Message-ID: On Fri, 26 Apr 2019, JORDI PALET MARTINEZ wrote: > The intent is to clearly state that this is a violation of the policies. > > The membership documents/bylaws or the RSA, your account may be closed. > I looked at it when adapting the policy from RIPE to ARIN, don't have > this information right in my mind, but I'm sure it was there. > > Otherwise, if needed another policy should state something like "if you > keep violating policies" this and that may happen. This should be > something generic for *any* policy violation not in general. We have > this in RIPE and LACNIC, and I'm also convinced that in APNIC and > AFRINIC (still working on those versions). Not swip'ing your IPs is also a violation of the agreement, but until you go back to ARIN for more IPs (opps, they're out), that's not an issue. I see this policy as pointless as written because it doesn't say that ARIN will take any action other than publishing an opinion. I think you're also assuming there's a pool of experts standing by willing to investigate every alleged hijacking (for free?). Maybe there are. If there aren't, or once they get tired of investigating allegations, what then? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jared at puck.nether.net Fri Apr 26 22:24:24 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Apr 2019 18:24:24 -0400 Subject: Disney+ CDN In-Reply-To: References: <001c01d4f0ec$30b28160$92178420$@gvtc.com> Message-ID: <0D4E9C55-1C4C-42A5-94A4-8CF7D75CC38F@puck.nether.net> I doubt it. If they use the BAM stuff and launch in October (after World Series) the timing might be right. Sent from my iCar > On Apr 26, 2019, at 6:06 PM, Ross Tajvar wrote: > > Agreed, I noticed the single IX as well and asked them about it in my email. If they don't expand aggressively in the next ~6 months, they're going to have a very problematic launch. > >> On Fri, Apr 26, 2019 at 5:59 PM Jon Lewis wrote: >> On Fri, 26 Apr 2019, Ross Tajvar wrote: >> >> > Yeah, I'm going to send them an email and see if I can get ahold of their peering policy. >> > I'm hoping they will update it as they get more attention from other networks. They may just be procrastinating >> > setting things up. According to bgp.he.net they are only announcing one v4 /24 and one v6 /48, which could be >> > enough IPs, but seems a little on the small side. >> >> I'd be much more worried about only being on one IX than only advertising >> a single /24 and /48. I'm guessing they've just not fully fleshed out the >> peeringdb entry and maybe not fully built out the network infrastructure >> yet. A CDN, with everything coming from one POP in NY is not going to cut >> it. >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> | therefore you are >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Apr 26 22:26:18 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Apr 2019 00:26:18 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> Message-ID: A policy proposal typically is not perfect when submitted. However, not having the discussion, doesn't allow to improve it and maybe then, reach consensus. It may happen that the end of the discussion is, instead of a group of experts, we need something different, or may be a compensation for them is needed, or instead of a complex policy we need a simple one, in the line of: "The resources are allocated for the exclusive use of the recipient. Consequently, other members can't use them (unless authorized by the legitimate resource-holder) and not following this rule is a policy violation". El 27/4/19 0:08, "Jon Lewis" escribió: On Fri, 26 Apr 2019, JORDI PALET MARTINEZ wrote: > The intent is to clearly state that this is a violation of the policies. > > The membership documents/bylaws or the RSA, your account may be closed. > I looked at it when adapting the policy from RIPE to ARIN, don't have > this information right in my mind, but I'm sure it was there. > > Otherwise, if needed another policy should state something like "if you > keep violating policies" this and that may happen. This should be > something generic for *any* policy violation not in general. We have > this in RIPE and LACNIC, and I'm also convinced that in APNIC and > AFRINIC (still working on those versions). Not swip'ing your IPs is also a violation of the agreement, but until you go back to ARIN for more IPs (opps, they're out), that's not an issue. I see this policy as pointless as written because it doesn't say that ARIN will take any action other than publishing an opinion. I think you're also assuming there's a pool of experts standing by willing to investigate every alleged hijacking (for free?). Maybe there are. If there aren't, or once they get tired of investigating allegations, what then? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nanog at ics-il.net Fri Apr 26 22:36:10 2019 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 26 Apr 2019 17:36:10 -0500 (CDT) Subject: Disney+ CDN In-Reply-To: References: Message-ID: <1674303332.3339.1556318167734.JavaMail.mhammett@ThunderFuck> but hey... they're getting transit from VZB\MCI\UUNET... so it'll be great! ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jon Lewis" To: "NANOG" Sent: Friday, April 26, 2019 4:51:58 PM Subject: Re: Disney+ CDN On Fri, 26 Apr 2019, Ross Tajvar wrote: > Yeah, I'm going to send them an email and see if I can get ahold of their peering policy. > I'm hoping they will update it as they get more attention from other networks. They may just be procrastinating > setting things up. According to bgp.he.net they are only announcing one v4 /24 and one v6 /48, which could be > enough IPs, but seems a little on the small side. I'd be much more worried about only being on one IX than only advertising a single /24 and /48. I'm guessing they've just not fully fleshed out the peeringdb entry and maybe not fully built out the network infrastructure yet. A CDN, with everything coming from one POP in NY is not going to cut it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From t0pe5p0h at meo.ws Fri Apr 26 22:45:50 2019 From: t0pe5p0h at meo.ws (Katie Holly) Date: Sat, 27 Apr 2019 00:45:50 +0200 Subject: SoftLayer NOC contact to get two IP prefixes de-announced In-Reply-To: <110BD255-8BE7-4E7E-ACDA-DEA485DB6C6C@tislabs.com> References: <2219d3b2-f10e-7150-3ac1-bf82ce36cf6b@meo.ws> <110BD255-8BE7-4E7E-ACDA-DEA485DB6C6C@tislabs.com> Message-ID: <5bf8b860-a816-ce5b-1fd5-d6232b8bcb2f@meo.ws> Hi, the prefixes in question (144.48.82.0/24 and 185.121.178.0/24) are no longer announced today after forwarding the original email to NetworkSupportEngineers-SoftLayer-WW at wwpdl.vnet.ibm.com and peering at softlayer.com Thanks Best regards Katie Holly On 4/26/19 10:57 PM, Sandra Murphy wrote: > Hi! > > I try to keep track of prefix mis-originations that I see announced publicly. > > For this one, you did not mention the prefixes involved, so I tried to discover the prefixes you might hold, based only on the info gleaned from your message. > > I’ve found a handful of prefixes associated in some way. None of them seem to be originated by AS36351. They are all originated by AS204136. > > Would you be willing to confirm whether any of these are the prefixes in question? > > 185.121.177.0/24 > 185.121.163.0/24 > 5.253.85.0/24 > 103.230.141.0/24 > > 185.140.114.0/24 > 185.140.115.0/24 > 169.239.202.0/24 > > —Sandy Murphy > > (6 of the 7 are protected by an RPKI ROA, which is good.) > > btw. I typed meo.ws into a web browser, expecting only to receive a list web search results, but I found that meo.ws replies - with what looks like a set of info and references you find generally useful. > >> On Apr 26, 2019, at 7:25 AM, Katie Holly wrote: >> >> Hi, >> >> anyone from SoftLayer (AS36351) around or someone with a contact to their NOC? They have been announcing two /24's from us without permission and we'd like them to remove the announcement immediately. >> >> Emails were sent to ipadmin at softlayer.com, abuse at ibm.com and ipreg at us.ibm.com without success hence I'm reaching out to this list as a last resort. >> >> Thanks >> >> -- >> Best regards >> >> Katie Holly > From bill at herrin.us Fri Apr 26 22:55:17 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Apr 2019 15:55:17 -0700 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: On Fri, Apr 26, 2019 at 2:36 PM Jon Lewis wrote: > Maybe I missed it in the proposal, but I don't see that it actually says > what ARIN will do other than produce a report "Yep, our expert panel says > this is hijacked.". What's the expected result (other than the report)? > i.e. What action is ARIN expected to take after it's determined a route > advertisement is a hijacking that will make a difference? > Tough question! If the author's petition succeeds so he's not cut off at the knees by the Advisory Council's out-of-scope ruling, I'll look forward to hearing how he answers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Apr 26 23:25:33 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Apr 2019 01:25:33 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: RSA (https://www.arin.net/about/corporate/agreements/rsa.pdf) clearly state that the services are subject to the terms and conditions stated in the policy manual. There is explicit text in case of lack of payment. Not so clear what to do if there is a policy violation, but it looks like at a minimum, you will not get further services neither further resources. Bylaws (https://www.arin.net/about/corporate/bylaws/#bylaws-of-american-registry-for-internet-numbers-ltd) don’t explicitly talk about the obligations of members. This may be related to US law, that you don’t need to explicitly say that behavior against other members is forbidden. In some countries, it is evident that if a member of an association is not following the rules (policies) or is acting against the rights of other members, it can be expelled. As I said before, we may need another policy proposal to stated what to do. Why a different policy proposal? Because the same policy section must be related to other policy violations (may be with warnings in case of policy violations and resource recovery only in extreme cases or repetitive misbehavior – this is the case in RIPE), if that’s not clear already in the bylaws, US laws, or RSA. For me, it is obvious that an association MUST protect members about *any* misbehavior of other members. Regards, Jordi El 27/4/19 0:58, "NANOG en nombre de William Herrin" escribió: On Fri, Apr 26, 2019 at 2:36 PM Jon Lewis wrote: Maybe I missed it in the proposal, but I don't see that it actually says what ARIN will do other than produce a report "Yep, our expert panel says this is hijacked.". What's the expected result (other than the report)? i.e. What action is ARIN expected to take after it's determined a route advertisement is a hijacking that will make a difference? Tough question! If the author's petition succeeds so he's not cut off at the knees by the Advisory Council's out-of-scope ruling, I'll look forward to hearing how he answers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Fri Apr 26 23:35:01 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Apr 2019 19:35:01 -0400 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: <20190426164719.GA85521@gweep.net> <89E360B4-1AF7-415F-A641-82F44D2B2B7E@puck.nether.net> Message-ID: <71823A08-CBB6-4760-B132-95310B8FB556@puck.nether.net> > On Apr 26, 2019, at 5:49 PM, JORDI PALET MARTINEZ wrote: > > "AP stated that at the LACNIC meeting has discussed it and they dismissed it as out of scope." > > LACNIC will have the first meeting where this topic will be discussed in two weeks from now. How come an AC member can lie such way? > > If I'm an AC member, or any other similar team, I will make sure to inform myself before stating something like that. In this case there is no excuse, you just need to visit a web page for the LACNIC policy proposals, similar in every RIR. > > Then I continue reading this: "AP stated that she believed that the author was using ARIN to solve their problem." > > How come somebody that doesn't know me, can state that? I’m not going to go in depth on the above comments. I’ve received at least one off-list inquiry and I’ll also assume no explicit malice here, but as you point out, it doesn’t smell tide fresh :) The linked AC minutes page does say "These minutes are DRAFT. They have been reviewed by the ARIN Advisory Council prior to posting. These minutes will remain draft until they are reviewed and approved by the ARIN Advisory Council at their next regularly scheduled meeting.” I have pointed out another area that I consider suspect off-list, I will set a calendar item to watch for new minutes to see if they are approved with revisions. Hopefully there’s misunderstandings here, but I’m also not confident as much of the conversation seems to have a disjoint with operational realities. (This isn’t anything new with ARIN btw, they’ve long been concerned about interacting with systems that are operational as doing that may mean staffing for on call or other functions). I’m hoping to see some updates/corrections to the text, so taking a snapshot may be useful to watch for the corrections to the draft minutes. I’m also debating if I spend the weekend with family or pinging everyone I know on the AC (which is more than one) about these issues. Either way, I’ll pick this up “soon” on my side. I do consider that abuse of ARIN allocated resources (coke/pepsi for numbering or other integers for AS4_PATH) something that ARIN can efforts to enforce revocation in the case of violation of the RSA. - Jared From surfer at mauigateway.com Fri Apr 26 23:37:23 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 26 Apr 2019 16:37:23 -0700 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) Message-ID: <20190426163723.4C85723E@m0117164.ppops.net> --- amitchell at isipp.com wrote: From: "Anne P. Mitchell, Esq." [This .sig space open to suggestions.] ----------------------------------------------- I don't really care about your .sig, but in general... %s/\[This .sig space open to suggestions.\]//g scott From owen at delong.com Sat Apr 27 00:07:19 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Apr 2019 17:07:19 -0700 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: <5DCE14C4-EE8F-496E-B6E6-CD556D1FF41B@delong.com> > I personally support the petition. I think the out of scope reasoning is flawed. By enforcing minimum assignment sizes, ARIN has long acted as a gatekeeper to the routing system, controlling who can and can not participate. For better or worse, that puts the proposal in scope. Speaking only for myself and not as a representative of the ARIN AC… I believe this is a distortion of the realities of the situation and of the history. ARIN actually led the charge to lengthen the maximum IPv6 prefix accepted by ISPs (from /32 all the way to /48). ARIN prefix size limits have almost always been equal to or longer than those accepted by a majority of providers on the internet and in almost all cases where those limits changed, ARIN changed first, with providers changing as a result of the pressure that created. As to how those were decided within the ARIN process, please note that it was community consensus that drove those changes (and resisted them in the earlier days). Nonetheless, the reason for having those limits had to do with how ARIN was managing the resources on behalf of the community. Any impact or lack thereof on the routing table was a secondary effect. The policy was in scope because it affected how ARIN managed the registry. The current proposal doesn’t actually affect any action ARIN takes in managing the registry. It attempts to expand the scope of ARIN’s mission to include some vague form of policing routing. It doesn’t provide any real information about how this new mission should be accomplished, nor does it take into account the fact that since ARIN controls only a small handful of routers, it has little to no ability to make any decisive or useful action in this regard. It seems to assume that those hijacking resources are ARIN members (or at least ARIN resource holders who signed an RSA subjecting them to ARIN policy). It is utterly untested waters as to whether ARIN has any ability to take any action against a party that hasn’t got a contract with ARIN for violating the rights of a party that does have a contract with ARIN. To be useful, this policy would, IMHO, need to somehow empower ARIN to do that. I am not a lawyer, but I doubt such empowerment can come from anything short of regulation, thus certainly out of scope of ARIN policy. I agree with Bill that such empowerment would not be a good thing anyway, so it’s not like I want to see that regulation come about, but until it does, I don’t see an in-scope effect from this proposal. Owen From johnl at iecc.com Sat Apr 27 01:00:41 2019 From: johnl at iecc.com (John Levine) Date: 26 Apr 2019 21:00:41 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <44a32613-a255-44eb-a094-cee68b6d088a@Spark> Message-ID: <20190427010041.D77262012FFB4F@ary.qy> In article <44a32613-a255-44eb-a094-cee68b6d088a at Spark> you write: >-=-=-=-=-=- > >particularly "interesting" when someone downloads CP (or, as it now seems to be called, CSAM) using their >ipaddr and causes them to become a Person of Interest. I was thinking the same thing, that'll do it. Or maybe videos showing how to behead members of religious or cultural groups against whom someone holds a grudge. From johnl at iecc.com Sat Apr 27 01:05:26 2019 From: johnl at iecc.com (John Levine) Date: 26 Apr 2019 21:05:26 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <003d01d4fc27$ba0bb300$2e231900$@netconsultings.com> Message-ID: <20190427010526.76E042012FFC2D@ary.qy> In article <003d01d4fc27$ba0bb300$2e231900$@netconsultings.com> you write: >But isn't there a law in US that protects oblivious or outright simple-mined >population from falling for these type of "easy money" schemes by >prohibiting these types of business? If it became popular enough to be annoying I expect that the large cable or phone providers could claim tortious interference by inducing their customers to violate their contracts. I assumed that something this sleazy would be offshore, but their terms of service say they're in Los Angeles. From ops.lists at gmail.com Sat Apr 27 01:06:50 2019 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 27 Apr 2019 01:06:50 +0000 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: <242A9C5B-B0CA-4124-95EA-F9B68EC6A7DA@consulintel.es> , Message-ID: Even among the network security community the number of people who track bgp hijacks and gather data is quite small yet such people do exist and have been active in speaking for this proposal when the same thing was discussed on the ripe anti abuse wg to an expected chorus of "we are not the internet police" --srs ________________________________ From: NANOG on behalf of JORDI PALET MARTINEZ via NANOG Sent: Saturday, April 27, 2019 3:58 AM To: Jon Lewis Cc: North American Network Operators' Group Subject: Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation It may happen that the end of the discussion is, instead of a group of experts, we need something different, or may be a compensation for them is needed, or instead of a complex policy we need a simple one, in the line of: "The resources are allocated for the exclusive use of the recipient. Consequently, other members can't use them (unless authorized by the legitimate resource-holder) and not following this rule is a policy violation".  -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Apr 27 01:31:08 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Apr 2019 18:31:08 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <20190427010526.76E042012FFC2D@ary.qy> References: <003d01d4fc27$ba0bb300$2e231900$@netconsultings.com> <20190427010526.76E042012FFC2D@ary.qy> Message-ID: On Fri, Apr 26, 2019 at 6:06 PM John Levine wrote: > I assumed that something this sleazy would be offshore, but their > terms of service say they're in Los Angeles. > They tricked you. https://packetstream.io/legal/privacy PacketStream 8605 Santa Monica Blvd Los Angeles, CA, 90069 support at packetstream.io https://www.earthclassmail.com/addresses/ca/west-hollywood "Get a real West Hollywood address at 8605 Santa Monica Blvd, West Hollywood, CA 90069-4109, US for your business, then get your mail online - as easy as..." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Apr 27 02:46:51 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Apr 2019 19:46:51 -0700 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: > The proposal is “guarantor”, or at least that’s our intent. Is not ARIN taking the decision, is the community by means of experts. We have improved it in the v2 that will be posted in a matter of days in RIPE, but we can’t improve it in ARIN because simply discussing it is not allowed by the AC decision. This isn’t entirely correct as I understand it. Any policy or potential policy can be discussed on PPML even if it is not actually on the Advisory Council Docket. You are certainly free to discuss the proposal as well as the petition there. > Now if another ARIN member is misusing your resources (not by an operational mistake, but repeatedly), ARIN is not going to do anything about it? Do you honestly believe that hijackings are being committed by ARIN members or even ARIN resource holders that have signed RSAs with ARIN? > Is not a problem or ARIN becoming the “routing police”. This has been completely misunderstood by the AC. Is about ARIN making sure that the rights of the members are respected by other members. Please provide some evidence that this has happened. My understanding is that the intentional repetitive hijackings to which you refer are almost always (possibly always) committed by people using not only fraudulent address space, but also fraudulent ASNs. > Without clear rules, other members can do whatever they want with resources allocated to another member. I’m pretty certain that’s already clear from the RSA… Section 2 of RSA version 12.0 / LRSA Version 4.0 covers this reasonably well: 2. CONDITIONS OF SERVICE (a) Compliance. In receiving or using any of the Services, Holder must comply with the Service Terms. (b) Provision of Services and Rights. Subject to Holder’s on-going compliance with its obligations under the Service Terms, including, without limitation, the payment of the fees (as set forth in Section 4), ARIN shall (i) provide the Services to Holder in accordance with the Service Terms and (ii) grant to Holder the following specified rights: (1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database; (2) The right to use the Included Number Resources within the ARIN database; and (3) The right to transfer the registration of the Included Number Resources pursuant to the Policies. Holder acknowledges that other registrants with ARIN have rights that intersect or otherwise impact Holder’s rights and/or use of the Included Number Resources, including, but not limited to, other registrants benefiting from visibility into the public portions of registrations of the Included Number Resources as further described in the Policies. (c) redacted — not relevant here and long (d) Prohibited Conduct By Holder. In using any of the Services, Holder shall not: (i) disrupt or interfere with the security or use of any of the Services; (ii) violate any applicable laws, statutes, rules, or regulations; or (iii) assist any third party in engaging in any activity prohibited by any Service Terms. What does the policy proposal offer in terms of rules that aren’t already enshrined in the above text? Your claim is that without clear rules, there is a problem. I claim we have clear rules that go as far as your policy and that the problem isn’t RIR members in general anyway, but bad actors who are generally NOT RIR members. > Additionally, a question of scope does arise with regard to which resources ARIN would be able to enforce any such policy with regard to. Indeed, the proposal as written currently calls for a "pool of worldwide experts" despite being a proposal submitted to an RIR which is explicitly not worldwide in scope. For example, if a network with an ASN assigned by ARIN is "hijacking" address space that is allocated by APNIC (or any other RIR) to an entity outside of ARIN's region, would this be an issue for ARIN to consider? What if ARIN-registered address space is being "hijacked" by an entity with a RIPE ASN and which is not located within ARIN territory? I suspect that for this proposal to have any meaningful enforcement mechanisms, it would require inter-RIR cooperation on enforcement, and that's a very large can of worms. Not one that is impossible to overcome, but likely one which will require several years of scrutiny, discussion, and negotiation prior to any real world implementation. > > This has been clarified in v2 that I mention before, to be publish in RIPE. The idea is that the claim is done in the region where the hijacker is a member (assuming that we get the policy going thru all the regions). And also assuming that the hijacker is a member of any RIR at all… A dubious claim, IMHO. > Right, we have a more complete v2 with many procedural details, which we can’t even discuss in ARIN, and obviously the idea of the PDP is to allow the policy proposals to be discussed until we reach a text that we can agree. To the best of my knowledge, you are free to discuss any policy or potential policy in the ARIN region regardless of AC action on any particular proposal. To be clear, the AC’s action does not preclude discussion (to the best of my knowledge). The decision made by the AC was not to accept it on to the AC docket as a draft policy because as written it was out of scope. (See official announcement from AC and ARIN staff for a more nuanced and detailed description). This does not preclude discussing further work on the subject on PPML and it does not preclude submission of a different proposal that addresses a problem within ARIN’s scope. > So please, if you want to get this discussion going on in the right place subscribe to ARIN PPML (https://lists.arin.net/mailman/listinfo/arin-ppml ) and respond to the attached email, just to support the discussion (no need to agree at all now with the text). That’s not actually what the current petition will do. I quote from the ARIN Policy Development Process: 2.1. Petition against Abandonment, Delay, or Rejection due to Scope The Advisory Council’s decision to abandon a Policy Proposal, Draft Policy or Recommended Draft Policy may be petitioned. Petitions may be initiated within the 5 days following the announcement date of an Advisory Council abandonment of a specific Policy Proposal or any Draft Policy. For sake of clarity, the “announcement date” of an action shall be the publication date of the action in the ARIN AC draft minutes. Additionally, Policy Proposals that have not been accepted as a Draft Policy after 60 days may also be petitioned to Draft Policy status at anytime. For a Policy Proposal that has been rejected due to being out of scope of the PDP, a successful petition will refer the question of whether the Policy Proposal is in scope to the ARIN Board of Trustees for consideration. For all other petitions against abandonment or delay, a successful petition will result in the Draft Policy being placed back on the Advisory Council docket under control of the petitioner and scheduled for public policy consultation at the next PPM. After the public consultation, control returns to the Advisory Council and subsequently may be revised or abandoned per the normal Policy Development Process. Emphasis of the third paragraph is mine since it is the relevant section to this discussion. Thus, your petition, as I understand the above text is to get the board to make a ruling on whether or not the proposal is within scope of the ARIN Policy Development Process. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Apr 27 03:15:32 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Apr 2019 20:15:32 -0700 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> <20190425055003.GA67694@vurt.meerval.net> Message-ID: <4919DA8E-CB41-4AA9-9F6A-52006FC61D4E@delong.com> > On Apr 25, 2019, at 09:10 , Mark Seiden wrote: > > feeling cranky, are we, job? (accusing an antispam expert of spamming on a mailing list by having too long a .sig?) > but it’s true! anne runs the internet, and the rest of us (except for ICANN GAC representatives) all accept that. > > to actually try to make a more substantial point, i am quite curious how the AUPs of carriers try to disallow bandwidth resale while permitting > cybercafe operations and other “free wifi" (where internet service might be provided for patrons in a hotel or cafe) Business internet contracts usually don’t prohibit resale, or, they place different limits on it. Residential contracts usually flat out prohibit it. At least in theory, I would expect most cybercafe and other such operations to have a business class of service from the ISP. > wireless access point schemes where you make money or get credit for allowing use of your bandwidth (e.g. Fon) For residential end users, it probably does violate the ToS, but it’s unlikely such violation would be easily detected or enforced. > other proxy services that use bandwidth such as tor exit nodes and openvpn gateways Unless you’re doing something illegal or making money selling your bandwidth, most things like this probably aren’t technically violations of the ToS. > i suppose they could just try to disallow resale or allow on-premises use even if revenue is received. the Fon business model seems pretty comparable to me. I agree — I’m pretty sure that both the Fon model and the packetstream model are probably ToS violations for most residential services. Fon is unlikely to get noticed by most ISPs. Packetstream seems a lot more risky, IMHO. Owen > On Apr 24, 2019, 10:51 PM -0700, Job Snijders , wrote: >> Dear Anne, >> >> On Wed, Apr 24, 2019 at 11:07:51PM -0600, Anne P. Mitchell, Esq. wrote: >>> How can this not be a violation of the ToS of just about every major provider? >> >> Can you perhaps cite ToS excerpts from one or more major providers to >> support your assertion? >> >>> Anne P. Mitchell, >>> Attorney at Law >>> GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant >>> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) >>> Legislative Consultant >>> CEO/President, Institute for Social Internet Public Policy >>> Board of Directors, Denver Internet Exchange >>> Board of Directors, Asilomar Microcomputer Workshop >>> Legal Counsel: The CyberGreen Institute >>> Legal Counsel: The Earth Law Center >>> California Bar Association >>> Cal. Bar Cyberspace Law Committee >>> Colorado Cyber Committee >>> Ret. Professor of Law, Lincoln Law School of San Jose >>> Ret. Chair, Asilomar Microcomputer Workshop >> >> Are you listing all the above because you are presenting a formal >> position supported by all these organisations about ToS? Can you for >> instance clarify how signing of as a director for the Denver Internet >> Exchange shapes the context of your ToS message? >> >> Or, perhaps you are listing the above for some kind of self-marketing >> purposes? If that is the case, please note that it is fairly uncommon to >> use the NANOG mailing list to distribute resumes. I know numerous >> websites dedicated to the dissemination of work histories, perhaps you >> can use those instead of operational mailling list? >> >> Regards, >> >> Job >> >> ps. RFC 3676 section 4.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.cutler at consultant.com Sat Apr 27 03:36:15 2019 From: james.cutler at consultant.com (James R Cutler) Date: Fri, 26 Apr 2019 23:36:15 -0400 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) Message-ID: --- amitchell at isipp.com wrote: From: "Anne P. Mitchell, Esq." > [This .sig space open to suggestions.] Just to continue this clearly trivial discussion: I enjoy your signature. It always leaves no question regarding the posting identity. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Apr 27 03:44:12 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Apr 2019 20:44:12 -0700 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: On Fri, Apr 26, 2019 at 7:48 PM Owen DeLong wrote: > Do you honestly believe that hijackings are being committed by ARIN members or even ARIN resource holders that have signed RSAs with ARIN? Wasn't Softlayer (an ARIN resource holder) called out on this list about 14 hours ago for hijacking a couple /24s? And honest mistake no doubt but come on man, the hijackings happen. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat Apr 27 05:04:56 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Apr 2019 22:04:56 -0700 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: <2902619D-BD96-4D02-BB5C-455BE4EFD6A1@delong.com> The policy specifically states that it’s not intended towards honest mistakes, but repeated deliberate persistent behavior. Do you know of any such case involving resource holders that have signed RSAs with ARIN or any other RIR for that matter? Owen > On Apr 26, 2019, at 20:44 , William Herrin wrote: > > On Fri, Apr 26, 2019 at 7:48 PM Owen DeLong > wrote: > > Do you honestly believe that hijackings are being committed by ARIN members or even ARIN resource holders that have signed RSAs with ARIN? > > Wasn't Softlayer (an ARIN resource holder) called out on this list about 14 hours ago for hijacking a couple /24s? And honest mistake no doubt but come on man, the hijackings happen. > > -Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Sat Apr 27 05:56:29 2019 From: tj at pcguys.us (TJ Trout) Date: Fri, 26 Apr 2019 22:56:29 -0700 Subject: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?) In-Reply-To: References: Message-ID: Your sig is fine, anyone who says otherwise needs to obtain gainful employment to occupy more free time On Fri, Apr 26, 2019 at 8:36 PM James R Cutler wrote: > --- amitchell at isipp.com wrote: > From: "Anne P. Mitchell, Esq." > > [This .sig space open to suggestions.] > > Just to continue this clearly trivial discussion: > > I enjoy your signature. It always leaves no question regarding the posting > identity. > > James R. Cutler > James.cutler at consultant.com > GPG keys: hkps://hkps.pool.sks-keyservers.net > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sat Apr 27 07:12:12 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 27 Apr 2019 09:12:12 +0200 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: <71823A08-CBB6-4760-B132-95310B8FB556@puck.nether.net> References: <20190426164719.GA85521@gweep.net> <89E360B4-1AF7-415F-A641-82F44D2B2B7E@puck.nether.net> <71823A08-CBB6-4760-B132-95310B8FB556@puck.nether.net> Message-ID: <273D76FB-64FE-41DA-9255-BD38CAB8C885@consulintel.es> Hi, El 27/4/19 1:35, "Jared Mauch" escribió: > On Apr 26, 2019, at 5:49 PM, JORDI PALET MARTINEZ wrote: > > "AP stated that at the LACNIC meeting has discussed it and they dismissed it as out of scope." > > LACNIC will have the first meeting where this topic will be discussed in two weeks from now. How come an AC member can lie such way? > > If I'm an AC member, or any other similar team, I will make sure to inform myself before stating something like that. In this case there is no excuse, you just need to visit a web page for the LACNIC policy proposals, similar in every RIR. > > Then I continue reading this: "AP stated that she believed that the author was using ARIN to solve their problem." > > How come somebody that doesn't know me, can state that? I’m not going to go in depth on the above comments. I’ve received at least one off-list inquiry and I’ll also assume no explicit malice here, but as you point out, it doesn’t smell tide fresh :) -> And I'm also convinced there is not any malice, but is wrong doing this kind of accusations or providing such false information. The linked AC minutes page does say "These minutes are DRAFT. They have been reviewed by the ARIN Advisory Council prior to posting. These minutes will remain draft until they are reviewed and approved by the ARIN Advisory Council at their next regularly scheduled meeting.” I have pointed out another area that I consider suspect off-list, I will set a calendar item to watch for new minutes to see if they are approved with revisions. Hopefully there’s misunderstandings here, but I’m also not confident as much of the conversation seems to have a disjoint with operational realities. (This isn’t anything new with ARIN btw, they’ve long been concerned about interacting with systems that are operational as doing that may mean staffing for on call or other functions). I’m hoping to see some updates/corrections to the text, so taking a snapshot may be useful to watch for the corrections to the draft minutes. -> If this is changed in the final minutes, then it will be very suspicious that the AC is empowered to change something that in reality happened. I call this manipulation and the community need to be aware of such things if it happen. Minutes should reflect the reality of what happened in the meeting. I really thing the right way is that they use a side note or whatever to ack it was mistakes, lack of knowledge, lack of chat with the authors, whatever, but never an alternation of the minutes. I’m also debating if I spend the weekend with family or pinging everyone I know on the AC (which is more than one) about these issues. Either way, I’ll pick this up “soon” on my side. I do consider that abuse of ARIN allocated resources (coke/pepsi for numbering or other integers for AS4_PATH) something that ARIN can efforts to enforce revocation in the case of violation of the RSA. - Jared ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jcurran at arin.net Sat Apr 27 13:43:32 2019 From: jcurran at arin.net (John Curran) Date: Sat, 27 Apr 2019 13:43:32 +0000 Subject: Regarding the ARIN Advisory Council and ARIN PDP (was: Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation) In-Reply-To: References: <20190426164719.GA85521@gweep.net> <89E360B4-1AF7-415F-A641-82F44D2B2B7E@puck.nether.net> Message-ID: On 26 Apr 2019, at 5:49 PM, JORDI PALET MARTINEZ via NANOG wrote: > ... > Not only that. I really think they have not invested enough time to read the proposal, check with the authors and then take a decision. We have got some email exchange, but clearly not sufficient. I also must state that the staff has been very helpful and diligent to clarify and support the petition process. Just the point is, should have never been needed, it exposes how bad (in my opinion) is the ARIN AC model. Jordi - I have no views on the particular policy proposal or the petition action, but want to be clear regarding some of your characterizations of the ARIN Policy Development Process (ARIN PDP). It is correct that the ARIN Advisory Council (a body elected by the ARIN membership) is in charge of administering the policy development process, including working with submitters to get their proposals accepted as draft policies and revising draft policies based on the community discussion. In general, policy proposals are discussed at length between the submitter and the assigned ARIN Advisory Council (ARIN AC) members, with the goal of making a clear and understandable statement of the problem in number resource policy that is to be addressed – as that is the required criteria for a Draft Policy. Once a policy proposal has a clear problem statement, the ARIN AC accepts it as a Draft Policy and it is discussed (often at length) on the ARIN Public Policy Mailing List. The ARIN AC works diligently with submitters to make sure that their proposals are clear and adopted as Draft Policies, and this occurs even when the assigned AC members don’t necessarily support the merits of the particular proposal. The strength of the ARIN PDP process is that nearly anyone can submit an idea for changes to our number resource policy (even with no knowledge of ARIN's policy development process) and the ARIN AC becomes their advocate in getting a clear draft policy put before the community for discussion. We have had policy proposals made by several segments of the Internet community that are not deeply involved in the RIR system or the network operator community, but have insight into specific problems in number resource policy that they were able to get addressed. There is an exception to this process, i.e. a case where the ARIN AC doesn’t work on a policy proposal, and it occurs with proposals which lie outside the scope of number resource policy. The ARIN AC does make an initial determination of whether the policy proposal is within scope – the reason for such an evaluation is to make sure that the community doesn’t spend its time working on proposals which aren’t germane to how ARIN administers number resources, and I will note the overwhelming majority of policy proposals meet this criteria with ease. Additionally, ARIN’s Policy Development Process contains many “checks and balances” to provide for the development of fair and impartial policy, and as you are aware, in the case of a policy proposal out of scope, there is a petition with a very low threshold (10 supporters) to provide for referral to ARIN’s Board of Trustees for review and final determination. Having the Board of Trustees handle such determinations makes perfect sense, as they are ultimately responsible for determining the scope of ARIN’s mission. I understand that your policy proposal has been deemed out of scope, but I’d like to point of that such events are a very rare occurrence, and do not reflect the circumstances that the vast majority of submitters face when working with the ARIN AC and the ARIN Policy Development Process. You might not see the merits of the ARIN Advisory Council administration of ARIN’s policy development process, but their efforts are almost universally in support of those submitting policy proposals, and the effectiveness of their advocacy demonstrated by the long line of clear, technically sound and useful policy changes in the ARIN region. Thanks! /John John Curran President and CEO American Registry for Internet Numbers From rsk at gsp.org Sat Apr 27 15:34:44 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 27 Apr 2019 11:34:44 -0400 Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: References: <003d01d4fc27$ba0bb300$2e231900$@netconsultings.com> <20190427010526.76E042012FFC2D@ary.qy> Message-ID: <20190427153444.GA5401@gsp.org> On Fri, Apr 26, 2019 at 06:31:08PM -0700, William Herrin wrote: > On Fri, Apr 26, 2019 at 6:06 PM John Levine wrote: > > > I assumed that something this sleazy would be offshore, but their > > terms of service say they're in Los Angeles. > > > > They tricked you. [snip] Also, unless I'm misreading their site, they expect users to download/run an application program of unknown provenance and function, from an operation that has gone to great lengths to conceal its location and principals. What could possibly go wrong? ---rsk From nanog at ics-il.net Sat Apr 27 17:33:37 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 27 Apr 2019 12:33:37 -0500 (CDT) Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <20190427153444.GA5401@gsp.org> References: <003d01d4fc27$ba0bb300$2e231900$@netconsultings.com> <20190427010526.76E042012FFC2D@ary.qy> <20190427153444.GA5401@gsp.org> Message-ID: <1608944453.3922.1556386414296.JavaMail.mhammett@ThunderFuck> Welcome to the Internet. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Rich Kulawiec" To: nanog at nanog.org Sent: Saturday, April 27, 2019 10:34:44 AM Subject: Re: Packetstream - how does this not violate just about every provider's ToS? On Fri, Apr 26, 2019 at 06:31:08PM -0700, William Herrin wrote: > On Fri, Apr 26, 2019 at 6:06 PM John Levine wrote: > > > I assumed that something this sleazy would be offshore, but their > > terms of service say they're in Los Angeles. > > > > They tricked you. [snip] Also, unless I'm misreading their site, they expect users to download/run an application program of unknown provenance and function, from an operation that has gone to great lengths to conceal its location and principals. What could possibly go wrong? ---rsk -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Sat Apr 27 20:20:23 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 27 Apr 2019 23:20:23 +0300 Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation In-Reply-To: References: Message-ID: On 27/04/2019 06:44, William Herrin wrote: > On Fri, Apr 26, 2019 at 7:48 PM Owen DeLong > wrote: > > Do you honestly believe that hijackings are being committed by ARIN > members or even ARIN resource holders that have signed RSAs with ARIN? > > Wasn't Softlayer (an ARIN resource holder) called out on this list > about 14 hours ago for hijacking a couple /24s? And honest mistake no > doubt but come on man, the hijackings happen. I don't think the proposal is talking about valid mistakes.  The proposal is talking about active, repetitive, BGP hijacking.  If you disagree with the proposal, can you state what your proposed solution is for BGP hijacks?  What should we as a community do to prevent them from happening before some government/int'l agency mandates what they consider would be their solution?    Or do we just continue to drumbeat MANRS, post major BGP hijacks on NANOG and carry-on as we have for the past decade? -Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at temk.in Sun Apr 28 14:53:11 2019 From: dave at temk.in (Dave Temkin) Date: Sun, 28 Apr 2019 10:53:11 -0400 Subject: Disney+ CDN In-Reply-To: <1674303332.3339.1556318167734.JavaMail.mhammett@ThunderFuck> References: <1674303332.3339.1556318167734.JavaMail.mhammett@ThunderFuck> Message-ID: My understanding is that they are launching using commercial CDNs. Highly likely those CDNs don't know what their traffic share will be like just yet. The ASN you're seeing pop up is a mid tier, not for delivery. On Fri, Apr 26, 2019 at 6:38 PM Mike Hammett wrote: > but hey... they're getting transit from VZB\MCI\UUNET... so it'll be > great! > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Jon Lewis" > *To: *"NANOG" > *Sent: *Friday, April 26, 2019 4:51:58 PM > *Subject: *Re: Disney+ CDN > > On Fri, 26 Apr 2019, Ross Tajvar wrote: > > > Yeah, I'm going to send them an email and see if I can get ahold of > their peering policy. > > I'm hoping they will update it as they get more attention from other > networks. They may just be procrastinating > > setting things up. According to bgp.he.net they are only announcing one > v4 /24 and one v6 /48, which could be > > enough IPs, but seems a little on the small side. > > I'd be much more worried about only being on one IX than only advertising > a single /24 and /48. I'm guessing they've just not fully fleshed out the > peeringdb entry and maybe not fully built out the network infrastructure > yet. A CDN, with everything coming from one POP in NY is not going to cut > it. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.lists at gmail.com Mon Apr 29 01:29:47 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Sun, 28 Apr 2019 21:29:47 -0400 Subject: IEEE CNS (co-located w/ NANOG) and lectures/notes on cyber-sec, routing Message-ID: Hi NANOG, two activities I'm involved in which may be of some interest/use to some of you: 1. IEEE CNS - Wash. DC, June 10-12 (yes, co-located with NANOG'76 - unfortunately, completely uncoordinated, and being TPC co-chair for CNS, this lack of coordination is frustrating and hard to justify). But maybe some of us will find ways to benefit from the co-location anyway (e.g., drop by to some CNS session, e.g., the session on Internet Infrastructure security - June 10 afternoon). Or organize joint dinner of interested people... or something. 2. While already announcing stuff let me mention that I'm working on pretty extensive text and set of lectures on `foundations of cyber-security' with emphasis on the network-security and crypto aspects. Part I is crypto and much of it is already usable, part II is on network security and currently mainly contains questions/exercises (a fair number and quite challenging). But lectures (pptx) are already available on most topics, incl. routing security. Hope some of you may find these of some use; feedback welcome (probably by private mail would be better). Best, Amir -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Foundations of Cybersecurity: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security Homepage: https://sites.google.com/site/amirherzberg/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nerdbynature.de Sun Apr 28 02:43:06 2019 From: lists at nerdbynature.de (Christian Kujau) Date: Sat, 27 Apr 2019 19:43:06 -0700 (PDT) Subject: Packetstream - how does this not violate just about every provider's ToS? In-Reply-To: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> References: <48A46F24-3D0C-4362-91EA-2804D9ED17C8@isipp.com> Message-ID: On Wed, 24 Apr 2019, Anne P. Mitchell, Esq. wrote: > How can this not be a violation of the ToS of just about every major provider? https://packetstream.io/support#q33 > Customers should ensure that their use case does not violate the ToS of > the service they are using. So, I guess it's up the the customer caring about that... C. -- BOFH excuse #107: The keyboard isn't plugged in From robertyin at yandex.com Sun Apr 28 21:18:04 2019 From: robertyin at yandex.com (Robert yin) Date: Mon, 29 Apr 2019 00:18:04 +0300 Subject: which would be better multicast solution - BIER Vs Tree-SID Message-ID: <5452471556486284@myt5-9da6df248f4a.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From marka at isc.org Mon Apr 29 02:52:22 2019 From: marka at isc.org (Mark Andrews) Date: Mon, 29 Apr 2019 12:52:22 +1000 Subject: Microsoft have releases a fix for the misbehaviour of their DNS servers. Message-ID: If you are using Microsoft for your DNS servers you really should update to a version that includes this fix from March 19, 2019 monthly updates. • Addresses minor issues with unknown options (unknown OPT) in the Extension Mechanisms for DNS (EDNS) for the Windows DNS Server role. https://support.microsoft.com/en-nz/help/4489893/windows-8-1-update-kb4489893 Older versions have even more egregious misbehaviour, with really old versions (pre-EDNS support) being flagged as dead by recursive servers as they do not respond consistently to EDNS queries. They respond a single time then do not respond at all for a period of time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mjl at luckie.org.nz Mon Apr 29 02:58:01 2019 From: mjl at luckie.org.nz (Matthew Luckie) Date: Mon, 29 Apr 2019 14:58:01 +1200 Subject: looking for hostname router identifier validation Message-ID: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Hi NANOG, To support Internet topology analysis efforts, I have been working on an algorithm to automatically detect router names inside hostnames (PTR records) for router interfaces, and build regular expressions (regexes) to extract them. By "router name" inside the hostname, I mean a substring, or set of non-contiguous substrings, that is common among interfaces on a router. For example, suppose we had the following three routers in the savvis.net domain suffix, each with two interfaces: das1-v3005.nj2.savvis.net das1-v3006.nj2.savvis.net das1-v3005.oc2.savvis.net das1-v3007.oc2.savvis.net das2-v3009.nj2.savvis.net das2-v3012.nj2.savvis.net We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, respectively, and captured by the regex: ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ After much refinement based on smaller sets of ground truth, I'm asking for broader feedback from operators. I've placed a webpage at https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm made for 2523 domains. If you operate one of the domains in that list, I would appreciate it if you could comment (private is probably better but public is fine with me) on whether the regex my algorithm inferred represents your naming intent. In the first instance, I am most interested in feedback for the suffix / date combinations for suffixes that are colored green, i.e. appear to be reasonable. Each suffix / date combination links to a page that contains the naming convention and corresponding inferences. The colored part of each hostname is the inferred router name. The green hostnames appear to be correct, at least as far as the algorithm determined. Some suffixes have errors due to either stale hostnames or incorrect training data, and those hostnames are colored red or orange. If anyone is interested in sets of hostnames the algorithm may have inferred as 'stale' for their network, because for some operators it was an oversight and they were grateful to learn about it, I can provide that information. Thanks, Matthew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From Jacques.Latour at cira.ca Mon Apr 29 13:45:05 2019 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Mon, 29 Apr 2019 13:45:05 +0000 Subject: Call for Presentations ICANN65 Marrakesh - June 24, 2019 Message-ID: <109a0d64dc5e43be9e9bb16a9b689caa@cira.ca> Hi all! Call for Presentations ICANN65 Marrakesh Call for Presentations 39th TechDay at ICANN 65 in Marrakesh The ICANN Tech Working Group is again planning a technical workshop at the ICANN 65 meeting in Marrakesh on Monday 2019-06-24, Blocks 3-5, starting 13:30. The TechDay workshop has been a part of ICANN meetings since 2006 and has provided a forum for both experienced and new people to meet, present and discuss technical topics related to registry and DNS work and security. We are specially interested in: 1. IDN 2. Disaster Planning and Mitigation 3. Techniques for fighting abuse 4. DNSSEC In particular: Getting Africa signed) 5. RDAP - what is it, implementing, authentication, challenges 6. IDNA2008 - emoji 7. In addition, we welcome suggestions for additional topics. If you are interested in presenting, please email ccNSO-techday at icann.org We hope that you can join us and request that you disseminate this Request to other lists where it might of interest. Greetings, Jacques, on behalf of the TechDay program Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Mon Apr 29 16:35:23 2019 From: john at essenz.com (John Von Essen) Date: Mon, 29 Apr 2019 12:35:23 -0400 Subject: Bing news feeds stale for 5 days (api.cognitive.microsoft.com) Message-ID: <0B962145-FFE6-47BA-AA5F-0724DE6F37E1@essenz.com> Any Bing engineers on here? I work with a major search affiliate partner, and starting this morning news feeds from api.cognitive.microsoft.com were coming in stale, nothing new in the past 5 days. However, this was only effecting API calls originating outside the USA. In the US, api.cognitive.microsoft.com returns fresh news, but globally through GeoDNS, that URL resolves to different IPs, those IPs (Europe, Singapore, etc.,.) are returning 5 day old news. Sorry if this is slightly off-topic, but we dont have a good PoC at Bing for this… I figure there is a very good chance someone here could escalate. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon Apr 29 18:01:23 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 29 Apr 2019 14:01:23 -0400 Subject: Bing news feeds stale for 5 days (api.cognitive.microsoft.com) In-Reply-To: <0B962145-FFE6-47BA-AA5F-0724DE6F37E1@essenz.com> References: <0B962145-FFE6-47BA-AA5F-0724DE6F37E1@essenz.com> Message-ID: <10891.1556560883@turing-police> On Mon, 29 Apr 2019 12:35:23 -0400, John Von Essen said: > I work with a major search affiliate partner, and starting this morning news > feeds from api.cognitive.microsoft.com > were coming in stale, nothing new in the past 5 days. Wait, what? So yesterday, it returned news for Sunday, but this morning, it's only returning news from Wed or before? (It's one thing to fail to have updates, rolling back already done updates takes a more convoluted failure mode...) From eric.kuhnke at gmail.com Mon Apr 29 20:13:38 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 29 Apr 2019 13:13:38 -0700 Subject: looking for hostname router identifier validation In-Reply-To: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: I would caution against putting much faith in the validity of geolocation or site ID by reverse DNS PTR records. There are a vast number of unmaintained, ancient, stale, erroneous or wildly wrong PTR records out there. I can name at least a half dozen ISPs that have absorbed other ASes, some of those which also acquired other ASes earlier in their history, forming a turducken of obsolete PTR records that has things with ISP domain names last in use in the year 2002. On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie wrote: > Hi NANOG, > > To support Internet topology analysis efforts, I have been working on > an algorithm to automatically detect router names inside hostnames > (PTR records) for router interfaces, and build regular expressions > (regexes) to extract them. By "router name" inside the hostname, I > mean a substring, or set of non-contiguous substrings, that is common > among interfaces on a router. For example, suppose we had the > following three routers in the savvis.net domain suffix, each with two > interfaces: > > das1-v3005.nj2.savvis.net > das1-v3006.nj2.savvis.net > > das1-v3005.oc2.savvis.net > das1-v3007.oc2.savvis.net > > das2-v3009.nj2.savvis.net > das2-v3012.nj2.savvis.net > > We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, > respectively, and captured by the regex: > ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ > > After much refinement based on smaller sets of ground truth, I'm > asking for broader feedback from operators. I've placed a webpage at > https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm > made for 2523 domains. If you operate one of the domains in that > list, I would appreciate it if you could comment (private is probably > better but public is fine with me) on whether the regex my algorithm > inferred represents your naming intent. In the first instance, I am > most interested in feedback for the suffix / date combinations for > suffixes that are colored green, i.e. appear to be reasonable. > > Each suffix / date combination links to a page that contains the > naming convention and corresponding inferences. The colored part of > each hostname is the inferred router name. The green hostnames appear > to be correct, at least as far as the algorithm determined. Some > suffixes have errors due to either stale hostnames or incorrect > training data, and those hostnames are colored red or orange. > > If anyone is interested in sets of hostnames the algorithm may have > inferred as 'stale' for their network, because for some operators it > was an oversight and they were grateful to learn about it, I can > provide that information. > > Thanks, > > Matthew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Mon Apr 29 21:16:06 2019 From: bryan at shout.net (Bryan Holloway) Date: Mon, 29 Apr 2019 16:16:06 -0500 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: On 4/29/19 3:13 PM, Eric Kuhnke wrote: > I would caution against putting much faith in the validity of > geolocation or site ID by reverse DNS PTR records. There are a vast > number of unmaintained, ancient, stale, erroneous or wildly wrong PTR > records out there. I can name at least a half dozen ISPs that have > absorbed other ASes, some of those which also acquired other ASes > earlier in their history, forming a turducken of obsolete PTR records > that has things with ISP domain names last in use in the year 2002. I still see references to UUNet in some reverse PTRs. So, uh, yeah. From list-nanog2 at dragon.net Mon Apr 29 21:22:16 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 29 Apr 2019 15:22:16 -0600 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: <20190429212216.AAB2D12C76DC@fafnir.remote.dragon.net> ekuhnke> I would caution against putting much faith in the validity of ekuhnke> geolocation or site ID by reverse DNS PTR records. There are a ekuhnke> vast number of unmaintained, ancient, stale, erroneous or ekuhnke> wildly wrong PTR records out there. I can name at least a half ekuhnke> dozen ISPs that have absorbed other ASes, some of those which ekuhnke> also acquired other ASes earlier in their history, forming a ekuhnke> turducken of obsolete PTR records that has things with ISP ekuhnke> domain names last in use in the year 2002. That's because the version of perl required to run the perl script that creates the ascii text PTR zone file is 4.x. perhaps? :) bryan> I still see references to UUNet in some reverse PTRs. bryan> So, uh, yeah. The uu.net PTRs should mostly have been service machines, like ns.uu.net, auth00.ns.uu.net (which horrifyingly do still resolve). Routers should have been in alter.net, which I do still see in traceroutes. From valdis.kletnieks at vt.edu Tue Apr 30 00:21:14 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 29 Apr 2019 20:21:14 -0400 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: <31470.1556583674@turing-police> On Mon, 29 Apr 2019 16:16:06 -0500, Bryan Holloway said: > I still see references to UUNet in some reverse PTRs. > > So, uh, yeah. I wonder what year we'll get to a point where less than half of NANOG's membership was around when UUNet was. We're probably there already. And likely coming up on when less than half the people know what it was, other than myth and legend.... From cma at cmadams.net Tue Apr 30 00:38:09 2019 From: cma at cmadams.net (Chris Adams) Date: Mon, 29 Apr 2019 19:38:09 -0500 Subject: looking for hostname router identifier validation In-Reply-To: <31470.1556583674@turing-police> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> Message-ID: <20190430003809.GA13549@cmadams.net> Once upon a time, Valdis Klētnieks said: > I wonder what year we'll get to a point where less than half of NANOG's > membership was around when UUNet was. We're probably there already. > And likely coming up on when less than half the people know what it > was, other than myth and legend.... I still refer to ASes by companies that haven't existed in ages... 701 is UUNet, 3561 is MCI, 1 is BBN, etc. :) I don't handle name changes well (I also refer to one of the main roads where I live by a name it hasn't had in close to 20 years). -- Chris Adams From large.hadron.collider at gmx.com Tue Apr 30 01:18:53 2019 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Mon, 29 Apr 2019 18:18:53 -0700 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: I legit guffawed. On 19-04-29 13 h 13, Eric Kuhnke wrote: > I would caution against putting much faith in the validity of > geolocation or site ID by reverse DNS PTR records. There are a vast > number of unmaintained, ancient, stale, erroneous or wildly wrong PTR > records out there. I can name at least a half dozen ISPs that have > absorbed other ASes, some of those which also acquired other ASes > earlier in their history, forming a turducken of obsolete PTR records > that has things with ISP domain names last in use in the year 2002. > > > > On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie > wrote: > > Hi NANOG, > > To support Internet topology analysis efforts, I have been working on > an algorithm to automatically detect router names inside hostnames > (PTR records) for router interfaces, and build regular expressions > (regexes) to extract them.  By "router name" inside the hostname, I > mean a substring, or set of non-contiguous substrings, that is common > among interfaces on a router.  For example, suppose we had the > following three routers in the savvis.net > domain suffix, each with two > interfaces: > > das1-v3005.nj2.savvis.net > das1-v3006.nj2.savvis.net > > das1-v3005.oc2.savvis.net > das1-v3007.oc2.savvis.net > > das2-v3009.nj2.savvis.net > das2-v3012.nj2.savvis.net > > We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, > respectively, and captured by the regex: > ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ > > After much refinement based on smaller sets of ground truth, I'm > asking for broader feedback from operators.  I've placed a webpage at > https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm > made for 2523 domains.  If you operate one of the domains in that > list, I would appreciate it if you could comment (private is probably > better but public is fine with me) on whether the regex my algorithm > inferred represents your naming intent.  In the first instance, I am > most interested in feedback for the suffix / date combinations for > suffixes that are colored green, i.e. appear to be reasonable. > > Each suffix / date combination links to a page that contains the > naming convention and corresponding inferences.  The colored part of > each hostname is the inferred router name.  The green hostnames appear > to be correct, at least as far as the algorithm determined. Some > suffixes have errors due to either stale hostnames or incorrect > training data, and those hostnames are colored red or orange. > > If anyone is interested in sets of hostnames the algorithm may have > inferred as 'stale' for their network, because for some operators it > was an oversight and they were grateful to learn about it, I can > provide that information. > > Thanks, > > Matthew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From large.hadron.collider at gmx.com Tue Apr 30 01:21:06 2019 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Mon, 29 Apr 2019 18:21:06 -0700 Subject: looking for hostname router identifier validation In-Reply-To: <20190430003809.GA13549@cmadams.net> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> <20190430003809.GA13549@cmadams.net> Message-ID: And 666 is Nero Caesar :-) On 19-04-29 17 h 38, Chris Adams wrote: > Once upon a time, Valdis Klētnieks said: >> I wonder what year we'll get to a point where less than half of NANOG's >> membership was around when UUNet was. We're probably there already. >> And likely coming up on when less than half the people know what it >> was, other than myth and legend.... > I still refer to ASes by companies that haven't existed in ages... 701 > is UUNet, 3561 is MCI, 1 is BBN, etc. :) I don't handle name changes > well (I also refer to one of the main roads where I live by a name it > hasn't had in close to 20 years). From surfer at mauigateway.com Tue Apr 30 01:28:07 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 29 Apr 2019 18:28:07 -0700 Subject: looking for hostname router identifier validation Message-ID: <20190429182807.4C84D794@m0117164.ppops.net> --- large.hadron.collider at gmx.com wrote: And 666 is Nero Caesar :-) ---------------------------------------------- It's the US Army. scott From list-nanog2 at dragon.net Tue Apr 30 01:36:41 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 29 Apr 2019 19:36:41 -0600 Subject: looking for hostname router identifier validation In-Reply-To: <20190429182807.4C84D794@m0117164.ppops.net> References: <20190429182807.4C84D794@m0117164.ppops.net> Message-ID: <20190430013642.0ADA912CA72A@fafnir.remote.dragon.net> lg.hadron> And 666 is Nero Caesar :-) surfer> It's the US Army. Same same... :) From cfriacas at fccn.pt Tue Apr 30 07:19:56 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 30 Apr 2019 08:19:56 +0100 (WEST) Subject: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd) In-Reply-To: References: Message-ID: Hi Everyone, Just a gentle reminder that May 1st is the last day to express support for this Open Petition at ARIN's Public Policy Mailing List (arin-ppml). Best Regards, Carlos On Fri, 26 Apr 2019, Carlos Friaças via NANOG wrote: > > Hi, > > Just to let everybody know that a petition was started in order to try to > enable a policy discussion about "BGP Hijacking is an ARIN Policy Violation". > > If you would like to read the proposal, it is available at: > https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/ > > Discussions are already ongoing at RIPE and LACNIC. > > Best Regards, > Carlos > > (sorry for the duplicates, if you also receive arin-ppml at arin.net) > > ---------- Forwarded message ---------- > Date: Fri, 26 Apr 2019 17:13:12 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] Open Petition for ARIN-prop-266: BGP Hijacking is an > ARIN > Policy Violation > > A petition has been initiated for the following: > > ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation > > This proposal was rejected due to scope at the 10 April meeting of the > Advisory Council. > > Anyone may take part in this petition. Per the Policy Development Process > (PDP), a successful petition against a rejected Proposal requires the support > of ten individuals from ten organizations. > > To support this petition, simply send a response to the Public Policy Mailing > list stating your support, name, and organization. > > This petition window will remain open for five days, closing 1 May. > > If successful, the petition will result in the Board of Trustees considering > the Proposal's scope at their next meeting. > > For more information on the PDP, visit: > https://www.arin.net/participate/policy/pdp/ > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From nanog at studio442.com.au Tue Apr 30 11:04:14 2019 From: nanog at studio442.com.au (Julien Goodwin) Date: Tue, 30 Apr 2019 21:04:14 +1000 Subject: looking for hostname router identifier validation In-Reply-To: <20190430003809.GA13549@cmadams.net> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> <20190430003809.GA13549@cmadams.net> Message-ID: <853886ad-e55f-44c4-048f-01c23ebc46e5@studio442.com.au> On 30/4/19 10:38 am, Chris Adams wrote: > I still refer to ASes by companies that haven't existed in ages... 701 > is UUNet, 3561 is MCI, 1 is BBN, etc. :) I don't handle name changes > well (I also refer to one of the main roads where I live by a name it > hasn't had in close to 20 years). This is especially true with acquisitions, AS3549 will be GBLX for me until it finally goes offline, and AS3356 likewise L3. From jared at puck.nether.net Tue Apr 30 12:12:05 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 30 Apr 2019 08:12:05 -0400 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: <32855B94-1A0E-4813-A251-171E57FE6673@puck.nether.net> While at NTT and at Akamai we have managed to publish sane PTR records and make the forward work as well. You need to automate it by pulling from your router configuration database and publish to your DNS database. If you are still doing either by hand then it’s time to make the switch ASAP. Sent from my iCar > On Apr 29, 2019, at 4:13 PM, Eric Kuhnke wrote: > > I would caution against putting much faith in the validity of geolocation or site ID by reverse DNS PTR records. There are a vast number of unmaintained, ancient, stale, erroneous or wildly wrong PTR records out there. I can name at least a half dozen ISPs that have absorbed other ASes, some of those which also acquired other ASes earlier in their history, forming a turducken of obsolete PTR records that has things with ISP domain names last in use in the year 2002. > > > >> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie wrote: >> Hi NANOG, >> >> To support Internet topology analysis efforts, I have been working on >> an algorithm to automatically detect router names inside hostnames >> (PTR records) for router interfaces, and build regular expressions >> (regexes) to extract them. By "router name" inside the hostname, I >> mean a substring, or set of non-contiguous substrings, that is common >> among interfaces on a router. For example, suppose we had the >> following three routers in the savvis.net domain suffix, each with two >> interfaces: >> >> das1-v3005.nj2.savvis.net >> das1-v3006.nj2.savvis.net >> >> das1-v3005.oc2.savvis.net >> das1-v3007.oc2.savvis.net >> >> das2-v3009.nj2.savvis.net >> das2-v3012.nj2.savvis.net >> >> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, >> respectively, and captured by the regex: >> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ >> >> After much refinement based on smaller sets of ground truth, I'm >> asking for broader feedback from operators. I've placed a webpage at >> https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm >> made for 2523 domains. If you operate one of the domains in that >> list, I would appreciate it if you could comment (private is probably >> better but public is fine with me) on whether the regex my algorithm >> inferred represents your naming intent. In the first instance, I am >> most interested in feedback for the suffix / date combinations for >> suffixes that are colored green, i.e. appear to be reasonable. >> >> Each suffix / date combination links to a page that contains the >> naming convention and corresponding inferences. The colored part of >> each hostname is the inferred router name. The green hostnames appear >> to be correct, at least as far as the algorithm determined. Some >> suffixes have errors due to either stale hostnames or incorrect >> training data, and those hostnames are colored red or orange. >> >> If anyone is interested in sets of hostnames the algorithm may have >> inferred as 'stale' for their network, because for some operators it >> was an oversight and they were grateful to learn about it, I can >> provide that information. >> >> Thanks, >> >> Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Tue Apr 30 15:36:56 2019 From: bryan at shout.net (Bryan Holloway) Date: Tue, 30 Apr 2019 10:36:56 -0500 Subject: looking for hostname router identifier validation In-Reply-To: <32855B94-1A0E-4813-A251-171E57FE6673@puck.nether.net> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <32855B94-1A0E-4813-A251-171E57FE6673@puck.nether.net> Message-ID: On 4/30/19 7:12 AM, Jared Mauch wrote: > While at NTT and at Akamai we have managed to publish sane PTR records > and make the forward work as well. You need to automate it by pulling > from your router configuration database and publish to your DNS > database. If you are still doing either by hand then it’s time to make > the switch ASAP. > > Sent from my iCar What's the reverse of your iCar? ;) From bryan at shout.net Tue Apr 30 15:38:33 2019 From: bryan at shout.net (Bryan Holloway) Date: Tue, 30 Apr 2019 10:38:33 -0500 Subject: looking for hostname router identifier validation In-Reply-To: <31470.1556583674@turing-police> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <31470.1556583674@turing-police> Message-ID: <7af8c5ac-53e0-5191-7e14-4f516f63f4ac@shout.net> On 4/29/19 7:21 PM, Valdis Klētnieks wrote: > On Mon, 29 Apr 2019 16:16:06 -0500, Bryan Holloway said: > >> I still see references to UUNet in some reverse PTRs. >> >> So, uh, yeah. > > I wonder what year we'll get to a point where less than half of NANOG's > membership was around when UUNet was. We're probably there already. > And likely coming up on when less than half the people know what it > was, other than myth and legend.... > Bought my first T-1 from those guys ... don't even ask how much it cost. From patrick at ianai.net Tue Apr 30 16:01:10 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 30 Apr 2019 12:01:10 -0400 Subject: looking for hostname router identifier validation In-Reply-To: <32855B94-1A0E-4813-A251-171E57FE6673@puck.nether.net> References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> <32855B94-1A0E-4813-A251-171E57FE6673@puck.nether.net> Message-ID: Automation isn’t even that hard - just outsource (e.g. 6Connect). I get why some things stagnate & collect kruft. But it is actually EASIER, and probably cheaper (including people time), to have a 3rd party “just do it” when it comes to things like DNS & IPAM. Then again, if everyone ran everything perfectly … oh, then I could retire. :-) -- TTFN, patrick > On Apr 30, 2019, at 8:12 AM, Jared Mauch wrote: > > While at NTT and at Akamai we have managed to publish sane PTR records and make the forward work as well. You need to automate it by pulling from your router configuration database and publish to your DNS database. If you are still doing either by hand then it’s time to make the switch ASAP. > > Sent from my iCar > > On Apr 29, 2019, at 4:13 PM, Eric Kuhnke > wrote: > >> I would caution against putting much faith in the validity of geolocation or site ID by reverse DNS PTR records. There are a vast number of unmaintained, ancient, stale, erroneous or wildly wrong PTR records out there. I can name at least a half dozen ISPs that have absorbed other ASes, some of those which also acquired other ASes earlier in their history, forming a turducken of obsolete PTR records that has things with ISP domain names last in use in the year 2002. >> >> >> >> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie > wrote: >> Hi NANOG, >> >> To support Internet topology analysis efforts, I have been working on >> an algorithm to automatically detect router names inside hostnames >> (PTR records) for router interfaces, and build regular expressions >> (regexes) to extract them. By "router name" inside the hostname, I >> mean a substring, or set of non-contiguous substrings, that is common >> among interfaces on a router. For example, suppose we had the >> following three routers in the savvis.net domain suffix, each with two >> interfaces: >> >> das1-v3005.nj2.savvis.net >> das1-v3006.nj2.savvis.net >> >> das1-v3005.oc2.savvis.net >> das1-v3007.oc2.savvis.net >> >> das2-v3009.nj2.savvis.net >> das2-v3012.nj2.savvis.net >> >> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, >> respectively, and captured by the regex: >> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ >> >> After much refinement based on smaller sets of ground truth, I'm >> asking for broader feedback from operators. I've placed a webpage at >> https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm >> made for 2523 domains. If you operate one of the domains in that >> list, I would appreciate it if you could comment (private is probably >> better but public is fine with me) on whether the regex my algorithm >> inferred represents your naming intent. In the first instance, I am >> most interested in feedback for the suffix / date combinations for >> suffixes that are colored green, i.e. appear to be reasonable. >> >> Each suffix / date combination links to a page that contains the >> naming convention and corresponding inferences. The colored part of >> each hostname is the inferred router name. The green hostnames appear >> to be correct, at least as far as the algorithm determined. Some >> suffixes have errors due to either stale hostnames or incorrect >> training data, and those hostnames are colored red or orange. >> >> If anyone is interested in sets of hostnames the algorithm may have >> inferred as 'stale' for their network, because for some operators it >> was an oversight and they were grateful to learn about it, I can >> provide that information. >> >> Thanks, >> >> Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjl at luckie.org.nz Mon Apr 29 21:59:36 2019 From: mjl at luckie.org.nz (Matthew Luckie) Date: Tue, 30 Apr 2019 09:59:36 +1200 Subject: looking for hostname router identifier validation In-Reply-To: References: <20190429025801.GA41159@sorcerer.cms.waikato.ac.nz> Message-ID: <20190429215936.GA46624@sorcerer.cms.waikato.ac.nz> Hi, I am aware that some PTR records are wrong. Can you please name the half dozen ISPs / suffixes so I can take a look at those in the data. In theory the code should score suffixes which have out of date records poorly. For suffixes that don't score poorly but have errors, there are other techniques that could reject incorrect clustering of router interfaces. Regarding uu.net (Bryan's email), it looks like those are colored red on the website after 201207, i.e. I would not use them for anything. But the transition to alter.net (Paul's email) looks good to me: https://www.caida.org/~mjl/rnc/201901/alter.net.html and I would claim the regex for alter.net is very good. If someone from alter.net is watching, can you comment on the gw1.iad8 inferences, where six interfaces are colored red as if they are named wrong (back in Jan 2019). My hunch is that the training data is wrong, and those interfaces belong on the same router. I can see similar behavior for gw4.lax15. Matthew On Mon, Apr 29, 2019 at 01:13:38PM -0700, Eric Kuhnke wrote: > I would caution against putting much faith in the validity of geolocation > or site ID by reverse DNS PTR records. There are a vast number of > unmaintained, ancient, stale, erroneous or wildly wrong PTR records out > there. I can name at least a half dozen ISPs that have absorbed other ASes, > some of those which also acquired other ASes earlier in their history, > forming a turducken of obsolete PTR records that has things with ISP domain > names last in use in the year 2002. > > > > On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie wrote: > > > Hi NANOG, > > > > To support Internet topology analysis efforts, I have been working on > > an algorithm to automatically detect router names inside hostnames > > (PTR records) for router interfaces, and build regular expressions > > (regexes) to extract them. By "router name" inside the hostname, I > > mean a substring, or set of non-contiguous substrings, that is common > > among interfaces on a router. For example, suppose we had the > > following three routers in the savvis.net domain suffix, each with two > > interfaces: > > > > das1-v3005.nj2.savvis.net > > das1-v3006.nj2.savvis.net > > > > das1-v3005.oc2.savvis.net > > das1-v3007.oc2.savvis.net > > > > das2-v3009.nj2.savvis.net > > das2-v3012.nj2.savvis.net > > > > We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, > > respectively, and captured by the regex: > > ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ > > > > After much refinement based on smaller sets of ground truth, I'm > > asking for broader feedback from operators. I've placed a webpage at > > https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm > > made for 2523 domains. If you operate one of the domains in that > > list, I would appreciate it if you could comment (private is probably > > better but public is fine with me) on whether the regex my algorithm > > inferred represents your naming intent. In the first instance, I am > > most interested in feedback for the suffix / date combinations for > > suffixes that are colored green, i.e. appear to be reasonable. > > > > Each suffix / date combination links to a page that contains the > > naming convention and corresponding inferences. The colored part of > > each hostname is the inferred router name. The green hostnames appear > > to be correct, at least as far as the algorithm determined. Some > > suffixes have errors due to either stale hostnames or incorrect > > training data, and those hostnames are colored red or orange. > > > > If anyone is interested in sets of hostnames the algorithm may have > > inferred as 'stale' for their network, because for some operators it > > was an oversight and they were grateful to learn about it, I can > > provide that information. > > > > Thanks, > > > > Matthew > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From byeganeh at cs.uoregon.edu Tue Apr 30 17:11:48 2019 From: byeganeh at cs.uoregon.edu (Bahador Yeganeh) Date: Tue, 30 Apr 2019 10:11:48 -0700 Subject: Help needed to validate results of topology discovery research Message-ID: Hi Nanog members, I am senior PhD student with the Oregon Network Research Group ( https://onrg.gitlab.io) at the University of Oregon, and sending this email to seek your help for validating the research results for one of our network measurement projects. We have conducted a large scale measurement study to infer the private (both physical and virtual) and public interconnections between Amazon/AWS network and all other ASes across the Internet along with their metro area where they are located. More information about this project can be found at https://ix.cs.uoregon.edu/~byeganeh/cloudx/. We are interested in validating at least part of our results against ground truth. If you are managing an AS that has one or more direct peerings with any of Amazon's networks (AS7224, AS16509, AS19047, AS14618, AS38895, AS39111, AS8987, and AS9059) and aware of their IPs and locations, it would be extremely valuable if you could validate our inferred peering between your AS and Amazon at the *aggregate level *(i.e. just indicating what fraction of our inferred interconnections for your network is correct). We will report this aggregate result in our study without revealing the identity of your network. If you have any questions or need more information about this project, please feel free to contact me. I appreciate your prompt response as we are trying to submit this study to a conference in a few weeks. Regards, Bahador Yeganeh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Tue Apr 30 20:18:05 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 30 Apr 2019 16:18:05 -0400 Subject: AT&T contact Message-ID: Peering email is broken, looking for an AT&T contact. Please contact me off list. The original message was received at Tue, 30 Apr 2019 16:11:17 -0400 from m0053301.ppops.net [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) ----- Transcript of session follows ----- ... while talking to [144.160.112.16]: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCP -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Tue Apr 30 20:27:56 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 30 Apr 2019 13:27:56 -0700 Subject: AT&T contact In-Reply-To: References: Message-ID: <6d5be9b4-6899-d369-8ba6-18358d798dc4@rollernet.us> On 4/30/19 13:18, Mehmet Akcin wrote: > Peering email is broken, looking for an AT&T contact. Please contact me > off list. > There's other contacts listed in peeringdb From christoffer at netravnen.de Tue Apr 30 21:50:34 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Tue, 30 Apr 2019 23:50:34 +0200 Subject: AT&T contact In-Reply-To: References: Message-ID: <20b07bf4-bff3-07bb-8f0c-ddc72d538ea6@netravnen.de> Mehmet Akcin, You write AT&T ... I look in PDB ... Networks (6): AT&T AP - AS2687 (2687) AT&T Canada - AS2685 (2685) AT&T EMEA - AS2686 (2686) AT&T LA - AS2688 (2688) AT&T US - 7018 (7018) AT&T US - AS7132 (7132) Which one are you mayhaps referring to, when you write AT&T? -Christoffer On 30/04/2019 22:18, Mehmet Akcin wrote: > Peering email is broken, looking for an AT&T contact. Please contact me off > list. From mehmet at akcin.net Tue Apr 30 21:50:59 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 30 Apr 2019 17:50:59 -0400 Subject: AT&T contact In-Reply-To: <20b07bf4-bff3-07bb-8f0c-ddc72d538ea6@netravnen.de> References: <20b07bf4-bff3-07bb-8f0c-ddc72d538ea6@netravnen.de> Message-ID: 7018 On Tue, Apr 30, 2019 at 17:50 Hansen, Christoffer wrote: > Mehmet Akcin, > > You write AT&T ... > > I look in PDB ... > > Networks (6): > AT&T AP - AS2687 (2687) > AT&T Canada - AS2685 (2685) > AT&T EMEA - AS2686 (2686) > AT&T LA - AS2688 (2688) > AT&T US - 7018 (7018) > AT&T US - AS7132 (7132) > > Which one are you mayhaps referring to, when you write AT&T? > > -Christoffer > > On 30/04/2019 22:18, Mehmet Akcin wrote: > > Peering email is broken, looking for an AT&T contact. Please contact me > off > > list. > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: